.net - dispatcher vs thread

Dispatcher

  Multiple tasks inone thread.

 

you can't update any UI controls from a thread that doesn'town the control. very Visual (Button, Textbox, Combobox, etc.) inherits from DispacterObject. Thisobject is what allows you to get a hold of the UI thread's Dispatcher.

the Dispatcher gives us the ability to Invoke onto itsthread.

http://www.switchonthecode.com/tutorials/working-with-the-wpf-dispatcher

 

SynchronizationContext

  To find  a UI thread

 

SynchronizationContext. MSDN says:

 

“Provides the basicfunctionality for propagating a synchronization context in varioussynchronization models.  The purpose of the synchronization modelimplemented by this class is to allow the internal asynchronous/synchronizationoperations of the common language runtime (CLR) to behave properly withdifferent synchronization models. This model also simplifies some of therequirements that managed applications have had to follow in order to workcorrectly under different synchronization environments”

 

 

The main difference between the Dispatcher and otherthreading methods is that the Dispatcher is not actually multi-threaded.

 

BackgroundWorker on the other hand actually executes thecode at the same time it is invoked, in a separate thread. It also is easier touse than true threads because it automatically synchronizes (at least I think Iremember this correctly) with the main thread of an application, the oneresponsible for the controls and message queue (the Dispatcher thread in thecase of WPF and Silverlight), so there's no need to use Dispatcher.Invoke (orControl.Invoke in WinForms) when updating controls from the background thread,although that may not be always recommended.

 

 

Not every thread has a SynchronizationContext attached to it. Onethread that always has a SynchronizationContextis the UI thread.

The UI thread, for example, uses a message pump, and withinits SynchronizationContext,it leverages the message pump to sync into the UI thread.

Sendmethod is doing a little magic; it is executing our code in a blocking fashion,and it reports back any exception during its execution.

Postwill "Fire and Forget" about the execution code within the delegate.It also means that you cannot catch exceptions as we did with the Send method. Suppose anexception is thrown, it will be the UI thread that will get it; unhanding theexception will terminate the UI thread.

http://www.codeproject.com/Articles/31971/Understanding-SynchronizationContext-Part-I

 

 

WPF and Silverlight applications use aDispatcherSynchronizationContext, which queues delegates to the UI thread’sDispatcher with “Normal” priority.

One aspect of SynchronizationContext is that it provides away to queue a unit of work to a context. Note that this unit of work is queuedto a contextrather than a specific thread. This distinction is important, because manyimplementations of SynchronizationContext aren’t based on a single, specificthread.

Another aspect of SynchronizationContext is that everythread has a “current” context. A thread’s context isn’t necessarily unique;its context instance may be shared with other threads. It’s possible for athread to change its current context, but this is quite rare.

A third aspect of SynchronizationContext is that it keeps acount of outstanding asynchronous operations. This enables the use of ASP.NETasynchronous pages and any other host needing this kind of count. In mostcases, the count is incremented when the current SynchronizationContext iscaptured, and the count is decremented when the captured SynchronizationContextis used to queue a completion notification to the context.

There are other aspects of SynchronizationContext, butthey’re less important to most programmers.

http://msdn.microsoft.com/en-us/magazine/gg598924.aspx(It's All About the SynchronizationContext)

 

BackgroundWorker

Executes an operation on a separate thread.

 

http://stackoverflow.com/questions/3762576/wpf-backgroundworker-vs-dispatcher

 

 

The very interesting aspect about the BackgroundWorker is the factthat RunWorkerCompleted and ProgressChanged event handlers would execute on thethread that created the BackgroundWorker object – most typically on a Windowsform main thread (the thread on which the UI controls are created). Therefore,you now do not fall into a trap that you used to fall into earlier – updating awinform control on the wrong thread and facing unpredictable results. (Notethat the DoWork method runs on a separate threadpool thread – do not update UIcontrols on that method)

http://msmvps.com/blogs/manoj/archive/2005/11/03/74120.aspx

 

Each BackgroundWorker captures and uses theSynchronizationContext of the thread that calls RunWorkerAsync and laterexecutes its RunWorkerCompleted event in that context.

http://msdn.microsoft.com/en-us/magazine/gg598924.aspx(It's All About the SynchronizationContext)

 

don’t use background workers before Application.Run()

http://www.codeproject.com/Articles/228869/BackgroundWorker-and-UI-threads