Имеет ли .NET реализацию словаря, эквивалентную Java ConcurrentHashMap?

Question

Напомним для тех .NET гуру, которые не могли бы знать о Java API:

ConcurrentHashMap в Java имеет атомное методы (т.е. не требуют внешнего запирания) для общего Карта операций модификации, такие как:

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

Это также позволяет итерацию по набору ключей без блокировки (она берет копию в начале итерации), а операции get() обычно могут чередоваться с вызовами put() без блокировки (используется мелкозернистая блокировка с чередованием IIRC).

В любом случае, мой вопрос: . У .NET есть эквивалентная реализация словаря?

Я предполагаю, что в целом я хотел бы знать, имеет ли .NET более общий набор библиотек сбора потоковых данных. Или общие утилиты для параллелизма - эквивалент Doug Lea - java.util.concurrent.

Answer 1

Не знаю, о чем я знаю. Самое близкое к тому, что вы ищете, вероятно, будет синхронным методом Hashtable, который возвращает (типа) потокобезопасную оболочку вокруг хеш-таблицы. Тем не менее, это только поточно-безопасный для нескольких авторов или нескольких читателей. Если я правильно помню, смесь писателей и читателей не будет потокобезопасной.

Answer 2

EDIT: Это было написано до выпуска .NET 4, когда, очевидно, есть ConcurrentDictionary. Я оставляю это здесь как ссылку для тех, кто нуждается в .NET 3.5.

Я не знаю ни одного эквивалента ConcurrentHashMap.

С точки зрения общих утилит для параллелизма - .NET всегда предоставляет немного больше, чем основы, которые Java, используемые для обеспечения, с точки зрения Mutex, ManualResetEvent, AutoResetEvent и ReaderWriterLock; то совсем недавно (.NET 2.0) Semaphore и (.NET 3.5) ReaderWriterLockSlim - конечно же, как и пул потоков процесса.

Большая встряска придет в .NET 4.0 при поступлении параллельных расширений - это должно сделать параллелизм намного проще. Аналогично, Coordination and Concurrency Runtime, наконец, освобождается от кандалов Microsoft Robotics Studio, хотя я не совсем понимаю, куда именно он идет (будь то часть самой .NET или отдельная библиотека).

Answer 3

Лично я считаю, что индивидуальные методы, синхронизированные, как правило, не так полезны, как кажется.

Как правило, вы можете захотеть связать «get» и «put» с тесной последовательностью, и если другой поток смотрит на те же самые значения, у вас есть немедленная гонка потоков. Аналогично (в зависимости от сценария) вы не хотите кто-то читает значения, над которыми вы работаете.

Для широкого подхода, просто используя внешнюю Monitor (lock(...) может хорошо работать во многих ситуациях. Это простой, легкий, и если вы не находитесь под тяжелой нагрузки нити, более чем достаточно.

Для более сложных сценариев такие вещи, как ReaderWriterLockSlim и т. Д., Более гибкие.Но я начал бы просто и только изменил бы ситуацию, если профилирование показывает, что существует серьезная проблема.

Как отмечает Джон, с параллельным расширением приходит совершенно новое множество высокопроизводительных устройств синхронизации; от того, что можно видеть (например here, here и here), это является частью .NET 4.0

Answer 4

Поступающий .Net 4.0 имеет ConcurrentDictionary класс, он имеет удобный GetOrAdd метод.

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

Очень полезно для глобальных серверных кешей.