You can need them more often when it seems.  For example, when you are doing server-side web development, you are in the multithread context because every request runs in a separate thread, and if you have a singleton service in your app, you should be sure that all code in the service is thread-safe. In UI development (WPF, Xamarin, whatever), we always have main thread and background tasks, and if a collection can be modified from UI by a user and background service, you have to be sure that your code is thread-safe. Why are standard collections not thread-safe? Let's start with a simple example. if(!dictionary.KeyExists(key)) 
{
	dictionary.Add(key, value);
} And let have a look at what may happen in two threads scenario: When running this code in multiple threads, there may be a chance when in both threads case will pass but only one thread will be able to modify the dictionary, and you'll get (An element with the same key already exists in the dictionary). if ArgumentException To work with collections in a multi-thread environment in , we have a namespace. Let's take a very brief overview of it. .NET System.Collections.Concurrent What do we have in Namespace? System.Collections.Concurrent - a general use thread-safe dictionary that can be accessed by multiple threads concurrently ConcurrentDictionary - a thread-safe last in-first out (LIFO) collection ConcurrentStack - a thread-safe first in-first out (FIFO) collection ConcurrentQueue - a thread-safe, unordered collection of objects. This type maintains a separate collection for each thread for adding and getting elements to be more performant when producer and consumer reside in the same thread. ConcurrentBag - provides concurrent addition and removal of items from multiple threads with the and methods (with cancellable overloads and ). It also has bounding and blocking capabilities which means that you can set the maximum capacity of the collection, and producers will be blocked when a maximum amount of items is reached to avoid excessive memory consumption. BlockingCollection Add Take TryAdd TryTake is a wrapper for , , . By default, it uses under the hood, but you can provide a more suitable collection for your use case during initialization. BlockingCollection ConcurrentStack ConcurrentQueue ConcurrentBag ConcurrentStack All these collections ( , , , ) implement the interface, so always try to use it, and you will be able to switch between different types of collections easily. BlockingCollection ConcurrentStack ConcurrentQueue ConcurrentBag IProducerConsumerCollection There are also , , , which are used by for collection segmentation. Partitioner OrderablePartitioner EnumerablePartitionerOptions Parallel.ForEach Now let's dive a little deeper and look into the main benefit that concurrent collections offer. Inner state integrity Let's have a look at another example: method of the standard generic queue implementation in Enqueue .NET // Adds item to the tail of the queue.
public void Enqueue(T item)
{
    if (_size == _array.Length)
    {
        Grow(_size + 1);
    }

    _array[_tail] = item;
    MoveNext(ref _tail);
    _size++;
    _version++;
} <T> uses an array to store elements and resizes this array when necessary. Also, it uses and properties for indexes from which to dequeue or enqueue elements, respectively. From the code, we see that consists of multiple steps. We check the array's length and resize it if necessary, then we store the item in the array and update and properties. So to speak, it's not an . Queue _head _tail Enqueue _tail _size atomic operation For example, Thread 1 assigns a value to , and while it is modifying property, Thread 2 assigns another value to the same index, and we end up with an inconsistent state of our collection. _array[_tail] _tail _tail Unlike standard, concurrent collections guarantee the integrity of a collection in a multithread environment. But this comes with a price. Concurrent collections will be less performant than standard collections in a single-thread environment. And the worst performance you'll get then accessing an of a concurrent collection. The aggregate state is a value that requires exclusive access to all collection elements (for example, or properties). Concurrent collections use different technics to optimize locking (granular locks, managing separate collections for different threads), but to query aggregate state, you have to lock the whole collection, potentially blocking multiple threads. So avoid querying aggregate state too often. aggregate state .Count .IsEmpty Race conditions In both examples, we've already seen the result of an operation depends on the order in which threads do their work. Such kind of issues is called . And concurrent collections have specific API to minimize race conditions. Let's have a look at this single-thread example: race conditions if (dictionary.ContainsKey(key))
{
    dictionary[key] += 1;
}
else
{
    dictionary.Add(key, 1);
} You should understand already that this code can fail in different places if running in a multi-thread environment. To deal with such cases, the concurrent dictionary has the method, which can be used like this: AddOrUpdate var newValue = dictionary
    .AddOrUpdate(key, 1, (itemKey, itemValue) => itemValue + 1) Here we have a delegate as the third parameter of method. One could expect that is an atomic operation, and we won't have any issues here. Even though this operation is really atomic, it uses under the hood, and if the latter can't update the current value (for example, then the value has been already updated from another thread), then the delegate will be executed again with a new . So we should remember that the delegate can be executed multiple times and that it shouldn't contain any side effects or a logic that depends on a number of executions. AddOrUpdate AddOrUpdate TryOrUpdate itemValue Wrapping up, we should say that your best choice is steering away from concurrency as much as possible, but when it is not possible, concurrent collections can be handy, even though by no means are they a magic wand.

Different

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Understanding Concurrent Collections in C#

Too Long; Didn't Read

Company Mentioned

Anatoly Pashmorga

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

Understanding Concurrent Collections in C#

Too Long; Didn't Read

Company Mentioned

Anatoly Pashmorga

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES