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

Answer 1

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.

Answer 2

1. "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.
2. "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.