How is the dispatcher different from the background thread?

Question

How is the concept of Dispatcher in .NET 3.5 and WPF different from the background thread in .NET 2.0?

For example, what is the difference between the instructions below:

delegate.Invoke/BeginInvoke 

AND

 this.dispatcher.Invoke/BeginInvoke 

Answer 1

A dispatcher can be considered as a queue to which events are sent; the dispatcher will run in the user interface thread and execute events for the user interface. In windows, user interface controls can only be changed by the thread that created them, so any changes to the user interface must be made from the user interface thread - so this is one of the most important reasons why operations that change window elements must be sent to the user interface dispatcher.

The background thread, in turn, is a different thread than the user interface. Thus, everything that runs on one of these threads will not affect or block the user interface.

Answer 2

The concepts of BeginInvoke and Invoke can be represented as follows.

• BeginInvoke means: "Do this and return before it completes. I either do not care about the return value, or you can call me back at this address at some point in the future."
• Invoke means: "Do it, and I'll sit here and wait for it to complete."

Now, as it relates to dispatchers and background threads, this is a completely different matter. According to Justin, the dispatcher processes the queue of things every time the UI thread becomes inactive. The background thread that calls BeginInvoke in the dispatcher will immediately return, even if the dispatcher may not have accessed the processing. If Invoke was used instead, the background thread blocked until the user interface processing was complete. Note that there is no Invoke in Silverlight in Dispatcher, and in most cases you probably don't want to block the background thread while the user interface thread is processing the work.

Conversely, Delegate.BeginInvoke uses worker threads in a thread pool. When you are in a user interface thread (or in any thread), you can invoke BeginInvoke and Invoke on the delegate. BeginInvoke will use the workflow to invoke the delegate using the same semantics as I described above. The call, however, will not use another thread. It simply called the delegate synchronously in the context of the calling thread and returned after completion.

Be careful when using synchronous execution on threads, although this often leads to deadlocks if you are not very careful.

Answer 3

Using the dispatcher to perform a long-term operation still forces it to execute in the user interface thread with only a different priority than the current operation. The problem here is that usually you want your continuous work to have the same throughput as possible. Running under the dispatcher, you are limited by the user interface.

The dispatcher point should bind the background thread back to the user interface so that you can, for example, provide an update to the user interface to complete your operation.

If you want to start the operation in the background and postpone the execution in the user interface, use a background worker or a new task library. Use the dispatcher to redirect updates back to the user interface.

Answer 4

Operations called by both methods will be placed in the event queue, which will be launched in the user interface thread. Invoke will happen synchronously and will be blocked until the operation is completed, BeginInvoke will happen using asynchronous permission to continue the execution of the calling method.