Home Library Learn Downloads Support Community
Sign in | United States - English | |
7 out of 12 rated this helpful - Rate this topic

System.Collections.Concurrent Namespace

.NET Framework 4

The System.Collections.Concurrent namespace provides several thread-safe collection classes that should be used in place of the corresponding types in the System.Collections and System.Collections.Generic namespaces whenever multiple threads are accessing the collection concurrently.

  Class Description
Public class BlockingCollection<T> Provides blocking and bounding capabilities for thread-safe collections that implement IProducerConsumerCollection<T>.
Public class ConcurrentBag<T> Represents a thread-safe, unordered collection of objects.
Public class ConcurrentDictionary<TKey, TValue> Represents a thread-safe collection of key-value pairs that can be accessed by multiple threads concurrently.
Public class ConcurrentQueue<T> Represents a thread-safe first in-first out (FIFO) collection.
Public class ConcurrentStack<T> Represents a thread-safe last in-first out (LIFO) collection.
Public class OrderablePartitioner<TSource> Represents a particular manner of splitting an orderable data source into multiple partitions.
Public class Partitioner Provides common partitioning strategies for arrays, lists, and enumerables.
Public class Partitioner<TSource> Represents a particular manner of splitting a data source into multiple partitions.
  Interface Description
Public interface IProducerConsumerCollection<T> Defines methods to manipulate thread-safe collections intended for producer/consumer usage. This interface provides a unified representation for producer/consumer collections so that higher level abstractions such as System.Collections.Concurrent.BlockingCollection<T> can use the collection as the underlying storage mechanism.
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Additional Reading
$0Whitepaper$0 http://blogs.msdn.com/b/pfxteam/archive/2010/04/26/9997562.aspx $0$0 $0 $0More info on these types$0 $0http://geekswithblogs.net/BlackRabbitCoder/archive/2010/11/11/c.net-little-wonders---a-presentation.aspx $0 $0$0 $0 $0Redis$0 $0http://redis.io/ $0
History
Concurrent Collections have nothing to do with their non-concurrent counterparts

J Trana is correct.  These collections were rewritten from scratch as lock-free objects.
They are fundamentally different from, and much more complicated than, their non-thread-safe counterparts.
Microsoft did not choose to implement Synchronized() methods on all collections because that would be useless, and dangerously wrong.

For more detail, see my blog post: http://blog.slaks.net/2011/11/one-of-most-useful-additions-to.html

History
Why not make all collections thread safe?
Yes I know Locks add extra instructions to be executed, but anyone serious about performance will want to utilise multiple cores, as many more cores is the future of high performance machines unless the chip manufacturers pull something radically different out of their collective hats.

History
Rationale for Concurrent Collections
To those who may be wondering why these collections exist and why not do something more consistent with Synchronized, etc. - here's a thought. I believe that these classes are not at all just wrappers. They are actually fundamentally different data structures under the hood. It is my understanding that they are by and large lock free data structures, which are very powerful (and modern) collections that depend on higher level atomic operations than a simple mutex does, like compare and swap. I would like to see an MS MVP respond here to help give a bit more rationale if confusion continues, as I think that these collections are some of the best additions to the .Net platform in recent history.
History
I disagree with the first comment
MSDN says: "To guarantee the thread safety of the Queue/Hashtable/or whatever, all operations must be done through this wrapper only". I always thought that the Synchronized method was a poor patch. A wrapper is, well…, a wrapper. I think that a collection should be synchronized or not depending on it's use. "The more dog-bark-like the comment is, the more dog-brain-like the comment is" [Confussus – 470 BC]. Sorry for my poor English.
History
Adds complexity and lacks consistancy
Why, oh why, don't all collections implement the Synchronized method like Hashtable, and other 'standard' collection classes do ?

Because that would be consistent, and not lead to code bloat, two concepts anathema to the .NET development team.  Instead we have an entirely seperate subset of classes which have an interface subtly different to their non-synchronized equivalents - thereby forcing developers to write wrapper classes to be able to treat them the same.

Please, stop producing idiotic 'enhancements', and fix this mess !
History