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.)

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.

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 .

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).

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.

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.