Thread safe collections in .NET

What is the standard nowadays when one needs a thread safe collection (e开发者_如何转开发.g. Set). Do I synchronize it myself, or is there an inherently thread safe collection?

The .NET 4.0 Framework introduces several thread-safe collections in the System.Collections.Concurrent Namespace:

ConcurrentBag<T>
      Represents a thread-safe, unordered collection of objects.

ConcurrentDictionary<TKey, TValue>
    Represents a thread-safe collection of key-value pairs that can be accessed by multiple threads concurrently.

ConcurrentQueue<T>
    Represents a thread-safe first in-first out (FIFO) collection.

ConcurrentStack<T>
    Represents a thread-safe last in-first out (LIFO) collection.

Other collections in the .NET Framework are not thread-safe by default and need to be locked for each operation:

lock (mySet)
{
    mySet.Add("Hello World");
}

Pre .net 4.0 most collections in .Net are not thread safe. You'll have to do some work yourself to handle the synchronization: http://msdn.microsoft.com/en-us/library/573ths2x.aspx

Quote from article:

Collections classes can be made thread safe using any of the following methods:

Create a thread-safe wrapper using the Synchronized method, and access the collection exclusively through that wrapper.

If the class does not have a Synchronized method, derive from the class and implement a Synchronized method using the SyncRoot property.

Use a locking mechanism, such as the lock statement in C# (SyncLock in Visual Basic), on the SyncRoot property when accessing the collection.

Sync Root Property
Lock Statement

Object thisLock = new Object();
......
lock (thisLock)
{
    // Critical code section
}

In .net 4.0 the introduced the System.Collections.Concurrent namespace

Blocking Collection
Concurrent Bag
Concurrent Queue
Concurrent Dictionary
Ordable Partitioner
Partitioner
Partitioner T

.NET 4 provides a set of thread-safe collections under System.Collections.Concurrent

In a addition to the very useful classes in System.Collections.Concurrent, one standard technique in mostly-read-rarely-change scenarios (or if there are however frequent, but non-concurrent writes) that is also applicable to .Net is called Copy-on-write.

It has a couple of properties that are desirable in highly-concurrent programs:

• collection object instances themselves are immutable (i.e. thread-safe, can be safely enumerated without locking)
• modification can take as much time as it wants, performance and concurrency of reads are not affected
• can be implemented generically to turn any data structure that is not thread-safe into one that is

Limitation: If there are concurrent writes, modifications may have to be retried, so the more concurrent writes get, the less efficient it becomes. (That's optimistic concurrency at work)

Edit Scott Chamberlain's comment reminded me that there's another limitation: If your data structures are huge, and modifications occur often, a copy-all-on-write might be prohibitive both in terms of memory consumption and the CPU cost of copying involved.