Ivan Krivyakov's Blog

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.

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:

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).
CodeProject

I did more investigation on the bindings (duh, only two months later). It turns out the bindings are replaced when the value of the target dependency property is replaced. This has some logic to it, as in XAML we write

<MyObject MyProperty="{Binding SomePath}">

and thus the binding becomes a “value” of the property, at least visually. Thus, if we now have MyProperty=”42″, the bindings should go. However, this seems to be catching even some Microsoft developers by surprise (Google “radio button binding bug”).

I could not reproduce binding disappearance after converter failure (converter throws exception), either one way or two way. This was probably a quirk of our specific program, or some other, unrelated problem.

CodeProject