What is the difference between SynchronizedCollection<T> and the other concurrent collections?

Question

How does SynchronizedCollection<T> and the concurrent collections in the System.Collections.Concurrent namespace differ from each other, apart from Concurrent Collections being a namespace and SynchronizedCollection<T> being a class?

SynchronizedCollection<T> and all of the classes in Concurrent Collections provide thread-safe collections. How do I decide when to use one over the other, and why?

Solution

The SynchronizedCollection<T> class was introduced first in .NET 2.0 to provide a thread-safe collection class. It does this via locking so that you essentially have a List<T> where every access is wrapped in a lock statement.

The System.Collections.Concurrent namespace is much newer. It wasn't introduced until .NET 4.0 and it includes a substantially improved and more diverse set of choices. These classes no longer use locks to provide thread safety, which means they should scale better in a situation where multiple threads are accessing their data simultaneously. However, a class implementing the IList<T> interface is notably absent among these options.

So, if you're targeting version 4.0 of the .NET Framework, you should use one of the collections provided by the System.Collections.Concurrent namespace whenever possible. Just as with choosing between the various types of collections provided in the System.Collections.Generic namespace, you'll need to choose the one whose features and characteristics best fit your specific needs.

If you're targeting an older version of the .NET Framework or need a collection class that implements the IList<T> interface, you'll have to opt for the SynchronizedCollection<T> class.

This article on MSDN is also worth a read: When to Use a Thread-Safe Collection

Comments

[Batrickparry]

So, I can prefer System.Collections.Concurrent over SynchrinozedCollecction<T> as I am using version 4.0!!

[Matt]

If these new Concurrent collections do not use locks for thread safety, how is the concurrency achieved?

[Cody Gray]

@Matt: Various ways. The answer is probably complicated enough so as to merit its own question. But for inspiration, look here: stackoverflow.com/questions/1688870/… and here: stackoverflow.com/questions/4785622/… (Also, did you read the MSDN article that I linked to? It gives a very brief summary of the tricks they use instead of locking, albeit probably not enough to write your own implementation.)

[Matt]

thanks for the info. That was a good hour or so of reading about things I had no idea even existed in .NET (and still don't fully comprehend)

[Lee Grissom]

@Matt, the .NET4 concurrent classes use SpinWait objects to address thread-safety instead of Monitor.Enter/Exit (aka Critical section). The difference is that SpinWait structures try to keep the thread running and waiting for a signal to continue, whereas a Critical section does a yield (aka thread-context switch) and then periodically returns back to the thread and checks to see if it can continue. CS's are fast, but in some situations, a SpinWait results in better performance if the guarded code executes fast.

[Marco]

As far as I can see, there still is no concurrent IList<T> alternative to this day. In a ConcurrentBag you can't really remove items. Some articles suggest (ab-)using a ConcurrentDictionary, which I find irritating due to its unnecessary overhead. So I myself keep using SynchronizedCollection.