Thread safe collections in .NET

Question

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?

Solution 1

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");
}

Solution 2

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

Solution 3

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

Solution 4

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.

View more solutions

Comments

[Femaref]

The object you are locking on should be an instance variable, otherwise it doesn't make sense because you are always locking on a new reference.

[kemiller2002]

That is true. This is just an example that was on the MSDN page on how the Lock code is used.

[SandRock]

You may prefer using a ReaderWriterLockSlim when creating a thread-safe collection.

[Scott Chamberlain]

Microsoft provides a set of copy-on-write collections via NuGet via Microsoft.Bcl.Immutable, you can find more info here

[Evgeniy Berezovsky]

@ScottChamberlain Theirs are way more sophisticated than my simple, but generic, "copy all on write" approach, in that they copy only part of the data. So they are usable even changing huge data structures, which will be inefficient with copy-all-on-write, both in terms of the CPU cost of copying, and the memory consumption for holding multiple full copies in memory.