Подведем итоги тем гуру .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 более общий набор потоковобезопасных библиотек коллекций. Или утилит параллелизма в целом - эквивалент библиотек java.util.concurrentДуг Ли.
Георгий - вы правы - это вопрос .net, а не Java. Тег удален.
В моем проекте concurrent.codeplex.com есть разделенный словарь, который позволяет нескольким читателям и писателям и разрешает транзакции с определенными значениями. Хотя он находится в стадии разработки ...





Обновлено: это было написано до выпуска .NET 4, когда, очевидно, есть ConcurrentDictionary. Я оставляю его здесь как справочник для тех, кому нужен .NET 3.5.
Я не знаю эквивалента ConcurrentHashMap.
Что касается общих утилит параллелизма - .NET всегда предоставляла немного больше, чем базовые возможности, которые использовала Java, в терминах Mutex, ManualResetEvent, AutoResetEvent и ReaderWriterLock; затем совсем недавно (.NET 2.0) Semaphore и (.NET 3.5) ReaderWriterLockSlim - а также, конечно, пул потоков всего процесса.
С появлением параллельных расширений в .NET 4.0 произойдет большая встряска - это должно упростить параллелизм много. Точно так же Координация и параллелизм во время выполнения, наконец, вырывается из оков Microsoft Robotics Studio, хотя я не совсем понимаю, куда он направляется (будет ли он частью самой .NET или отдельной библиотеки).
У меня сложилось впечатление (из общедоступных блогов MSDN), что ему суждено было стать основной частью самой .NET 4.0.
Спасибо за ответ, Джон. Параллельные расширения выглядят очень интересно. Для ясности - я не троллинг - это не тирада «Java имеет лучшие библиотеки, чем .net». Я новичок в .net и очень хочу увидеть, что доступно из коробки.
Марк: CCR как часть .NET 4.0? Ссылки приветствуются! Serg: Не волнуйтесь, я так не понял :)
@Jon: За то, что он устарел, но теперь, когда вы его обновили, я удалил голос против. :-)
@Jon Harrop: Спасибо. В будущем будет полезно, если вы комментируете, когда вы проголосовали против, чтобы респонденту было понятнее, что следует улучшить.
Не то, что я знаю о. Наиболее близким к тому, что вы ищете, вероятно, будет метод Synchronized для Hashtable, который возвращает (своего рода) потокобезопасную оболочку вокруг хеш-таблицы. Однако это только потокобезопасность для нескольких писателей или нескольких читателей. Если я правильно помню, смесь писателей и читателей не будет потокобезопасной.
Лично я считаю, что синхронизация отдельных методов обычно не так полезна, как кажется.
Обычно вы можете захотеть выполнить связанные «get» и «put» в тесной последовательности, и если другой поток смотрит на те же значения, у вас есть немедленная гонка потоков. Точно так же (в зависимости от сценария) вы не хочу никому, кто читает значения, над которыми вы работаете.
Для широкого подхода просто используйте внешний Monitor (lock(...) может хорошо работать во многих ситуациях. Он простой, легкий и, если вы не находитесь под нагрузкой потока тяжелый, более чем достаточен.
Для более сложных сценариев такие вещи, как ReaderWriterLockSlim и т. д., Более гибкие. Но я бы начал с простого и изменил ситуацию только в том случае, если профилирование показывает, что существует реальная проблема разногласий.
Как отмечает Джон, с Parallel Extension входит целый ряд новых высокопроизводительных устройств синхронизации; из того, что я вижу (например, здесь, здесь и здесь), это часть .NET 4.0
В Java ConcurrentHashMap отдельные методы get, replace, putIfAbsent и т. д. Не синхронизируются. Они используют неблокирующие алгоритмы для работы без блокировки в большинстве ситуаций нагрузки. Взгляну на ReaderWriterLockSlim - спасибо за подсказку.
У входящего .Net 4.0 есть класс ConcurrentDictionary, у него есть удобный метод GetOrAdd.
public TValue GetOrAdd(
TKey key,
Func<TKey, TValue> valueFactory
)
Очень полезно для глобальных серверных кешей.
для глобальных серверных кешей может быть лучше использовать объект MemoryCache, иначе может произойти утечка памяти, если вручную не удалить указанные объекты из ConcurrentDictionary.
вам действительно нужен тег java здесь?