Why invoke ThreadStart with empty Delegate?

Question

While doing some forensics archeological survey in an old apps I have to maintain I came across this :

It is a WPF application that was recently converted to .NET 4.0 and this code runs inside a background worker

           if(bgWorker1.IsBusy || bgWorker2.IsBusy)
           {
                Thread.Sleep(100); 
                Application.Current.Dispatcher.Invoke(
                    System.Windows.Threading.DispatcherPriority.Background, 
                    new System.Threading.ThreadStart(delegate { })
                );
           }

1 - What possible side-effect would be acheived by invoking a thread (main gui) with a no-op delegate. The other two threads also perform invokes on the main gui thread but only this one sets the priority to something else than Normal (they use Action rather than TreadStart though).

2 - I have cases that strangely resembles deadlock with this application and something tells me that this could be the cause. (mucking around the priority and main gui thread for no appearant reason).

Thanks

That calls probably blocks until the mainthread handled the message. — CodesInChaos, Oct 15 '12 at 20:36

score 5 · Accepted Answer · answered Oct 15 '12 at 20:40

5

This thread will cause the calling function to block until the Dispatcher's thread can "process" the (no-op) delegate.

This is likely not a good practice, and should probably be removed. I suspect the goal here was to allow this (third) BackgroundWorker's completion event to be a signal for when the first two BackgroundWorkers completed.

In general, spinning for completion like this is typically a sign of a bad design. A much better design would be to use a CountdownEvent, which could be signaled by both BackgroundWorker instances on their completion.

You could then just wait on the countdown event instead of looping with Thread.Sleep and the dispatcher invocation.

answered Oct 15 '12 at 20:40

Reed Copsey

554,122
78
1,158
1,373

So if I understand correctly it basically sets a bookmark of sorts in the dispatcher's stack and halt the thread until the bookmark is reached and processed. I guess this comes close to what Side Effect Oriented Programming would look like :-). – Newtopian Oct 15 '12 at 22:54
@Newtopian Yeah - kind of. It blocks until the Dispatcher runs the delegate (which does nothing), so yes, this is really programming-by-side-effect. – Reed Copsey Oct 15 '12 at 23:39

score 2 · Answer 2 · answered Oct 15 '12 at 20:41

"What possible side-effect would be acheived by [...]" Because it uses Invoke and not BeginInvoke it will be a blocking call. This means that your background thread won't continue to execute until your noop delegate runs. The effect is that the code won't continue until everything that was queued into the message loop before this noop has been executed.
"I have cases that strangely resembles deadlock with this application and something tells me that this could be the cause." Sounds plausible to me. This block of code screams both bad practice, and possible deadlock location. Since the code is referencing other background workers, it might be that others are doing something similar.

Now, it seems clear that something is wrong, but without knowing more about what's going on it's rather hard to comment about how it could be fixed. My guess is there is a fundamental design flaw the the approach that is being taken though.

thanks, I was not looking for a solution per-say but that code really bugged me as to what it's purpose could be. Thanks. helps a lot. — Newtopian, Oct 15 '12 at 22:56

Why invoke ThreadStart with empty Delegate?

2 Answers2