Does .NET have a Dictionary implementation that is equivalent to Java's ConcurrentHashMap?

Question

To recap for those .NET gurus who might not know the Java API:

ConcurrentHashMap in Java has atomic methods (i.e. require no external locking) for common Map modification operations such as:

putIfAbsent(K key, V value)
remove(Object key, Object value)
replace(K key, V value)

It also allows iteration over the keyset without locking (it takes a copy at the start of iteration) and get() operations can generally be interleaved with calls to put() without blocking (it uses fine grained lock striping IIRC).

Anyway, my question is: does .NET have an equivalent Dictionary implementation?

I guess more generally, I'd be keen to know if .NET has a more general set of thread safe collection libraries. Or concurrency utilities in general - equivalent to Doug Lea's java.util.concurrent libraries.

Answer 1

Not that I know of. The closest thing to what you're looking for would probably be the Synchronized method of the Hashtable, which returns a (sort of) thread-safe wrapper around the hashtable. It's only thread-safe for multiple writers or multiple readers, though. If I recall correctly, a mixture of writers and readers will not be thread-safe.

Answer 2

The incoming .Net 4.0 has a ConcurrentDictionary class, it has a convenient GetOrAdd method.

public TValue GetOrAdd(
    TKey key,
    Func<TKey, TValue> valueFactory
)

Very useful for global server caches.

Answer 3

EDIT: This was written prior to .NET 4 being released, when obviously there's ConcurrentDictionary. I'm leaving it here as a reference for those needing .NET 3.5.

I don't know of any equivalent to ConcurrentHashMap.

In terms of general concurrency utilities - .NET has always provided a bit more than the basics which Java used to provide, in terms of Mutex, ManualResetEvent, AutoResetEvent and ReaderWriterLock; then more recently (.NET 2.0) Semaphore and (.NET 3.5) ReaderWriterLockSlim - as well as the process-wide thread pool, of course.

A bigger shake-up will come in .NET 4.0 when Parallel Extensions arrives - that should make concurrency much simpler. Likewise the Coordination and Concurrency Runtime is finally breaking free of the shackles of the Microsoft Robotics Studio, although I'm not clear on exactly where it's headed (whether it'll be part of .NET itself, or a separate library).

Answer 4

Personally, I find that having individual methods as synchronized generally isn't as useful as it sounds.

Commonly, you might want to do a related "get" and "put" in close succession, and if another thread is looking at the same values you have an immediate thread race. Likewise (depending on the scenario) you don't want somebody reading values that you are working on.

For a broad approach, simply using an external Monitor (lock(...) can work well for many situations. It is simple, light-weight, and unless you are under heavy thread load, more than adequate.

For more complex scenarios, things like ReaderWriterLockSlim etc are more flexible. But I'd start simple, and only change things if profiling shows there is a genuine contention issue.

As Jon notes, with Parallel Extension comes a a whole new slew of high performance synchronization devices; from what I can see (for example here, here and here), this is part of .NET 4.0