ConcurrentDictionary<TKey,TValue> vs Dictionary<TKey,TValue>

Question

As MSDN says

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

But as I know, System.Collections.Concurrent classes are designed for PLINQ.

I have Dictionary<Key,Value> which keeps on-line clients in the server, and I make it thread safe by locking object when I have access to it.

Can I safely replace Dictionary<TKey,TValue> by ConcurrentDictionary<TKey,TValue> in my case? will the performance increased after replacement?

Here in Part 5 Joseph Albahari mentioned that it designed for Parallel programming

• The concurrent collections are tuned for parallel programming. The conventional collections outperform them in all but highly concurrent scenarios.
• A thread-safe collection doesn’t guarantee that the code using it will be thread-safe.
• If you enumerate over a concurrent collection while another thread is modifying it, no exception is thrown. Instead, you get a mixture of old and new content.
• There’s no concurrent version of List.
• The concurrent stack, queue, and bag classes are implemented internally with linked lists. This makes them less memory-efficient than the nonconcurrent Stack and Queue classes, but better for concurrent access because linked lists are conducive to lock-free or low-lock implementations. (This is because inserting a node into a linked list requires updating just a couple of references, while inserting an element into a List-like structure may require moving thousands of existing elements.)

Sherrylsherurd

I'm not aware of the fact that System.Collections.Concurrent classes are "designed for PLINQ" - where do you get that idea from? – Meagan

@BrokenGlass: Maybe in the sense that lambda's and anonymous types are "designed for LINQ"; they came to be in the framework because of LINQ, but they definitely have applicability beyond it. – Rambo

@Meagan and @Adam Robinson, see edited post – Sherrylsherurd

This only states that it is tuned for parallel programming which includes PLINQ, but also any multi-threaded scenario in general, there are any number of approaches from TPL to manually spawned Threads. – Meagan

Ok @BrokenGlass, I thought there are the same... Thanks! – Sherrylsherurd

Also see net-dictionary-locking-vs-concurrentdictionary – Pedant

Answer 1

Without knowing more about what you're doing within the lock, then it's impossible to say.

For instance, if all of your dictionary access looks like this:

lock(lockObject)
{
    foo = dict[key];
}

... // elsewhere

lock(lockObject)
{
    dict[key] = foo;
}

Then you'll be fine switching it out (though you likely won't see any difference in performance, so if it ain't broke, don't fix it). However, if you're doing anything fancy within the lock block where you interact with the dictionary, then you'll have to make sure that the dictionary provides a single function that can accomplish what you're doing within the lock block, otherwise you'll end up with code that is functionally different from what you had before. The biggest thing to remember is that the dictionary only guarantees that concurrent calls to the dictionary are executed in a serial fashion; it can't handle cases where you have a single action in your code that interacts with the dictionary multiple times. Cases like that, when not accounted for by the ConcurrentDictionary, require your own concurrency control.

Thankfully, the ConcurrentDictionary provides some helper functions for more common multi-step operations like AddOrUpdate or GetOrAdd, but they can't cover every circumstance. If you find yourself having to work to shoehorn your logic into these functions, it may be better to handle your own concurrency.

Rambo

Answer 2

It's not as simple as replacing Dictionary with ConcurrentDictionary, you'll need to adapt your code, as these classes have new methods that behave differently, in order to guarantee thread-safety.

Eg., instead of calling Add or Remove, you have TryAdd and TryRemove. It's important you use these methods that behave atomically, as if you make two calls where the second is reliant on the outcome of the first, you'll still have race conditions and need a lock.

Polysaccharide

Answer 3

You can replace Dictionary<TKey, TValue> with ConcurrentDictionary<TKey, TValue>.

The effect on performance may not be what you want though (if there is a lot of locking/synchronization, performance may suffer...but at least your collection is thread-safe).

Exedra

Answer 4

While I'm unsure about replacement difficulties, but if you have anywhere where you need to access multiple elements in the dictionary in the same "lock session" then you'll need to modify your code.

It could give improved performance if Microsoft has given separate locks for read and write, since read operations shouldn't block other read operations.

Booher

Answer 5

Yes you can safely replace, however dictionary designed for plinq may have some extra code for added functionality that you may not use. But the performance overhead will be marginally very small.

Yonne