Hat .NET eine Dictionary-Implementierung, die auf Java ConcurrentHashMap entspricht?

Question

für die .NET Gurus rekapitulieren, die nicht die Java API wissen könnten:

ConcurrentHashMap in Java Atom Methoden hat (dh benötigt keine externe Verriegelung) zur gemeinsamen Kartenänderungsoperationen wie:

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

Es Iteration über das Keyset auch ohne Verriegelung erlaubt (es zu Beginn der Iteration eine Kopie dauert) und get() Operationen können in der Regel mit Anrufen, ohne zu blockieren (es verwendet feinkörniges Schloss Striping IIRC ).

Wie auch immer, meine Frage ist: .NET eine äquivalente Wörterbuch Implementierung hat

ich generell denke, würde ich daran interessiert zu wissen, ob .NET einen allgemeineren Satz von Threadsicherheit Sammlung Bibliotheken hat. Oder Concurrency Utilities im Allgemeinen -. Entspricht Doug Lea 's java.util.concurrent Bibliotheken

Answer 1

Nicht, dass ich wüsste. Die nächste Sache, was Sie suchen würde wahrscheinlich die synchronisierte Methode der Hashtable sein, die um die Hash-Tabelle einen (Art) thread-safe-Wrapper zurück. Es ist nur Thread-sicher für mehrere Autoren oder mehrere Leser, though. Wenn ich mich richtig erinnere, nicht eine Mischung von Autoren und Lesern Thread-sicher.

Answer 2

Der eingehende .Net 4.0 hat eine ConcurrentDictionary Klasse, hat es eine bequeme GetOrAdd Methode.

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

Sehr nützlich für die globalen Server-Caches.

Answer 3

EDIT: Dies wurde geschrieben, bevor .NET 4, freigegeben wird, wenn offensichtlich ConcurrentDictionary gibt. Ich verlasse es hier als Referenz für die brauchen, um .NET 3.5.

Ich weiß nicht, irgend entspricht ConcurrentHashMap.

Im Hinblick auf die allgemeine Concurrency Utilities - .NET hat immer ein bisschen mehr als die Grundlagen zur Verfügung gestellt, die Java zu bieten verwendet werden, um im Hinblick auf die Mutex , ManualResetEvent , AutoResetEvent und ReaderWriterLock ; dann in jüngerer Zeit (.NET 2.0) Semaphore und (.NET 3.5) ReaderWriterLockSlim - sowie der Prozess weite Thread-Pool, natürlich.

Ein größeres shake-up kommt in .NET 4.0, wenn Parallel Extensions ankommen - das Gleichzeitigkeit machen sollte viel einfacher. Ebenso ist die Koordination und Concurrency Runtime bricht endlich frei von den Fesseln der Microsoft Robotics Studio, obwohl ich nicht ganz klar bin, wo es geleitet wird.

(ob es wird Teil von .NET selbst oder eine separate Bibliothek sein)

Answer 4

Ich persönlich finde, dass allgemein als synchronisierte einzelne Methoden, die ist nicht so nützlich, wie es klingt.

Allgemein, mögen Sie vielleicht ein Zusammenhang mit „get“ und „put“ in enger Folge zu tun, und wenn ein anderer Thread auf den gleichen Werten der Suche haben Sie ein sofortiges Thread-Rennen. Ebenso (je nach Szenario) Sie nicht wollen jemand liest Werte, die Sie gerade arbeiten.

Für einen breiten Ansatz, einfach eine externe Monitor mit (lock(...) kann auch für viele Situationen. Es ist einfach, leicht, und es sei denn, Sie sind unter schwer Fadenbelastung, mehr als ausreichend.

Für komplexere Szenarien, Dinge wie ReaderWriterLockSlim etc sind flexibler. Aber ich würde beginnen einfach, und nur die Dinge ändern, wenn Profilierung zeigt, dass es eine echte Konkurrenz Problem.

Wie Jon stellt fest, mit Parallel-Erweiterung eines eine ganz neue Reihe von Hochleistungs-Synchronisationseinrichtungen kommt; von dem, was ich (zum Beispiel hier , hier und hier ), ist dieser Teil von .NET 4.0