60

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?

Palec
  • 10,298
  • 7
  • 52
  • 116
Batrickparry
  • 1,329
  • 2
  • 13
  • 14
  • 1
    Have a look here : http://stackoverflow.com/questions/1946520/why-are-there-no-concurrent-collections-in-c – StuartLC Jan 11 '11 at 07:26

1 Answers1

71

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

Cody Gray
  • 222,280
  • 47
  • 466
  • 543
  • So, I can prefer System.Collections.Concurrent over SynchrinozedCollecction as I am using version 4.0!! – Batrickparry Jan 11 '11 at 07:42
  • 2
    If these new Concurrent collections do not use locks for thread safety, how is the concurrency achieved? – Matt Jun 21 '11 at 21:49
  • 4
    @Matt: Various ways. The answer is probably complicated enough so as to merit its own question. But for inspiration, look here: http://stackoverflow.com/questions/1688870/how-might-a-class-like-nets-concurrentbagt-be-implemented and here: http://stackoverflow.com/questions/4785622/why-is-concurrentbagt-so-slow-in-net-4-0-am-i-doing-it-wrong (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.) – Cody Gray Jun 21 '11 at 23:13
  • 1
    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) – Matt Jun 22 '11 at 16:27
  • 6
    @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. – Lee Grissom Feb 15 '12 at 21:16