Click here to Skip to main content
13,096,858 members (79,355 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


10 bookmarked
Posted 21 Jul 2011

BackgroundWorker and UI Threads

, 27 Jul 2011
Rate this:
Please Sign up or sign in to vote.
BackgroundWorker and UI threads

Popular belief (reinforced indirectly by MSDN) is that BackgroundWorker class will marshal the “progress” and “completed” events back to the calling thread. This turned out to be most certainly not true. A more restricted (and closer to reality) form of this belief is that if BackgroundWorker is spawned by a WPF UI thread, the events will be marshaled back to the UI thread. This is almost true. Read on.

BackgroundWorker uses SynchronizationContext.Post() to marshal progress and completed events. It captures the synchronization context of the current thread when you invoke RunorkerAsync() method. If current thread has no synchronization context, a default one will be created.

For WPF UI threads, the synchronization context (of type DispatcherSynchronizationContext) will indeed post the events back to the UI thread.

UI threadRunWorkerAsync()
Thread pool threadDoWork()
UI threadRunWorkerCompleted and ProgressChanged events

In background thread, or in main thread of a console application, the synchronization context will schedule event calls on a thread pool. So, typically, you will end up with 3 or more threads:

Calling threadRunWorkerAsync()
Thread pool thread #1DoWork()
Thread pool thread #2…nRunWorkerCompleted and ProgressChanged events

An interesting twist occurs if you run BackgroundWorker on a soon-to-be-come-UI-thread thread. Typically, it’s a main thread of your application before you called Application.Run(). Windows is not psychic, and it does not know what you are about to do. So, until you actually started a WPF application, your main thread is considered a regular thread, and default synchronization context will be used instead of DispatcherSynchronizationContext. Thus, your background worker events will not be marshalled back to the UI thread. Instead, they will be executed on a thread pool. If you touch UI in those callbacks, bad things will happen.

The workarounds are:

  • Don’t use background workers before Application.Run()
  • Use Dispatcher.BeginInvoke() inside suspect callbacks (however, be prepared that proponents of the myth may remove them as redundant)
  • Manually install DispatcherSynchronizationContext (don’t do this it at home; I did not try it, but I think it should work).


This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0


About the Author

Ivan Krivyakov
Technical Lead Thomson Reuters
United States United States
Ivan is a hands-on software architect/technical lead working for Thomson Reuters in the New York City area. At present I am mostly building complex multi-threaded WPF application for the financial sector, but I am also interested in cloud computing, web development, mobile development, etc.

Please visit my web site:

You may also be interested in...

Comments and Discussions

GeneralMy vote of 5 Pin
vinod.sankuthodi13-Aug-12 1:25
membervinod.sankuthodi13-Aug-12 1:25 
QuestionRevise the keywords Pin
Charles Oppermann26-Jul-11 7:08
memberCharles Oppermann26-Jul-11 7:08 
AnswerRe: Revise the keywords Pin
Ivan Krivyakov27-Jul-11 5:19
memberIvan Krivyakov27-Jul-11 5:19 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170813.1 | Last Updated 27 Jul 2011
Article Copyright 2011 by Ivan Krivyakov
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid