Multithreading and WPF 4.5

by Jonathan Allen on Jan 23, 2012 |

WPF 4.5 has improved its support for multi-threaded data binding, but the technique is still risky. This report attempts to explain how it works and what’s involved in using it safely.

WPF data binding has always had haphazard support for multi-threading. When an object raises a property changed event on a non-UI thread the data binding infrastructure is kicked into gear. And generally this works, though it isn’t really safe because of potential race conditions. From a computer science perspective it would be more correct to simply disallow cross-thread access, which is actually the case for the collection changed event.

Unfortunately developers don’t always care about correctness, they just want to get something done. So end up with various attempts at a “thread-safe” or “dispatcher-safe” observable collection. In all these attempts the fundamental design is to marshal the collection-changed event to the correct thread before invoking it. In this case the correct thread is whichever one that the dispatcher is running on. Unfortunately this doesn’t eliminate the possibility of a race condition.

With WPF 4.5, Microsoft is offering developers a much safer alternative. By calling BindingOperations.EnableCollectionSynchronization, the WPF data binding engine participates in locking. The default behavior is to acquire a lock on the object specified in the aforementioned call, but you also have the option to use more complex locking schemes. Unfortunately this is an error prone technique; it is easy to forget to acquire the collection’s lock while on the background thread. You can also forget to disable the collection synchronization when the collection is no longer needed, which could create a memory leak.

Another problem with this technique is that it doesn’t protect individual objects. So while the collection is being read under a lock, properties on each item in the collection are not necessarily being safely read. This is mostly a problem for complex getters and properties that cannot be set atomically (e.g. large value types).

We highly recommend that anyone using a background thread to update a collection only use immutable objects in that collection. Or if the objects cannot be made immutable, extreme care should be taken to at least make their property getters thread-safe. And when push comes to shove, you are probably better off forgetting that this feature exists and just marshal your collection updates to the UI thread.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Not supported on silverlight by Roopesh Shenoy

Note that this is not supported yet on silverlight. A somewhat related post about cross-thread exceptions in Silverlight when change notifications are raised in non-UI thread by Pete Brown is worth reading.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.