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.