Question

Time and time again I find myself having to write thread-safe versions of BindingList and ObservableCollection because, when bound to UI, these controls cannot be changed from multiple threads. What I’m trying to understand is why this is the case – is it a design fault or is this behavior intentional?

Answer 1

The problem is designing a thread safe collection is not simple. Sure it’s simple enough to design a collection which can be modified/read from multiple threads without corrupting state. But it’s much more difficult to design a collection that is usable given that it’s updated from multiple threads. Take the following code as an example.

if ( myCollection.Count > 0 ) {   var x = myCollection[0]; } 

Assume that myCollection is a thread safe collection where adds and updates are guaranteed not to corrupt state. This code is not thread safe and is a race condition.

Why? Even though myCollection is safe, there is no guarantee that a change does not occur between the two method calls to myCollection: namedly Count and the indexer. Another thread can come in and remove all elements between these calls.

This type of problem makes using a collection of this type quite frankly a nightmare. You can’t ever let the return value of one call influence a subsequent call on the collection.

EDIT

I expanded this discussion on a recent blog post: http://blogs.msdn.com/jaredpar/archive/2009/02/11/why-are-thread-safe-collections-so-hard.aspx