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.