.NET - блокировка словаря против ConcurrentDictionary

На поточно-безопасную коллекцию и не-поточно-безопасную коллекцию можно взглянуть по-другому.

Рассмотрим магазин без клерка, кроме как на кассе. Если люди не действуют ответственно, у вас будет масса проблем. Например, предположим, что покупатель берет банку из банки-пирамиды, в то время как клерк строит пирамиду, ад вырвется наружу. Или, что, если два покупателя потянутся за одним и тем же товаром одновременно, кто выиграет? Будет ли драка? Это не потокобезопасная коллекция. Есть много способов избежать проблем, но все они требуют какой-то блокировки или, скорее, явного доступа тем или иным образом.

С другой стороны, представьте себе магазин с клерком за столом, и вы можете делать покупки только через него. Вы встаете в очередь и просите у него предмет, он возвращает его вам, и вы выходите из очереди. Если вам нужно несколько предметов, вы можете забрать столько предметов на каждом пути туда и обратно, сколько вы можете вспомнить, но вы должны быть осторожны, чтобы не перегружать продавца, это разозлит других клиентов, стоящих в очереди за вами.

А теперь подумайте об этом. Что, если в магазине с одним продавцом вы дойдете до конца очереди и спросите продавца: «У вас есть туалетная бумага?», И он скажет «Да», а затем вы скажете: «Хорошо, я» Я свяжусь с вами, когда узнаю, сколько мне нужно », тогда, когда вы снова окажетесь в очереди, магазин, конечно, можно будет распродать. Этот сценарий не предотвращается потокобезопасной коллекцией.

Потокобезопасная коллекция гарантирует, что ее внутренние структуры данных действительны в любое время, даже если к ней обращаются из нескольких потоков.

Необезопасная коллекция не дает таких гарантий. Например, если вы добавляете что-то в двоичное дерево в одном потоке, в то время как другой поток занят перебалансировкой дерева, нет никакой гарантии, что элемент будет добавлен, или даже если дерево все еще будет действительным после этого, оно может быть повреждено безнадежно.

Тем не менее, потокобезопасная коллекция не гарантирует, что все последовательные операции в потоке работают с одним и тем же «снимком» его внутренней структуры данных, что означает, что если у вас есть такой код:

if (tree.Count > 0)
    Debug.WriteLine(tree.First().ToString());

вы можете получить исключение NullReferenceException, потому что между tree.Count и tree.First() другой поток очистил оставшиеся узлы в дереве, что означает, что First() вернет null.

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

Вам по-прежнему нужно быть очень осторожным при использовании поточно-ориентированных коллекций, потому что поточно-ориентированные коллекции не означают, что вы можете игнорировать все проблемы с потоками. Когда коллекция объявляет себя поточно-ориентированной, это обычно означает, что она остается в согласованном состоянии, даже когда несколько потоков одновременно читают и записывают. Но это не означает, что один поток увидит «логическую» последовательность результатов, если вызовет несколько методов.

Например, если вы сначала проверяете, существует ли ключ, а затем получаете значение, соответствующее этому ключу, этот ключ может больше не существовать даже с версией ConcurrentDictionary (потому что другой поток мог удалить ключ). В этом случае вам все равно нужно использовать блокировку (или лучше: объедините два вызова, используя TryGetValue).

Так что используйте их, но не думайте, что это дает вам возможность игнорировать все проблемы параллелизма. Тебе по-прежнему нужно быть осторожным.

Внутри ConcurrentDictionary использует отдельную блокировку для каждого хеш-ведра. Пока вы используете только Add / TryGetValue и подобные методы, которые работают с отдельными записями, словарь будет работать как почти свободная от блокировки структура данных с соответствующим приятным преимуществом в производительности. OTOH методы перечисления (включая свойство Count) блокируют сразу все сегменты и поэтому хуже, чем синхронизированный словарь, с точки зрения производительности.

Я бы сказал, просто используйте ConcurrentDictionary.

Я думаю, что метод ConcurrentDictionary.GetOrAdd - это именно то, что нужно большинству многопоточных сценариев.

Вы видели реактивные расширения для .Net 3.5sp1? По словам Джона Скита, они сделали резервную копию пакета параллельных расширений и параллельных структур данных для .Net3.5 sp1.

Существует набор примеров для .Net 4 Beta 2, в котором довольно подробно описано, как использовать их параллельные расширения.

Я только что провел последнюю неделю, тестируя ConcurrentDictionary, используя 32 потока для выполнения ввода-вывода. Кажется, что он работает так, как рекламируется, что указывает на то, что в него было вложено огромное количество испытаний.

Изменить: .NET 4 ConcurrentDictionary и шаблоны.

Microsoft выпустила PDF-файл под названием «Шаблоны параллельного программирования». Его действительно стоит загрузить, поскольку в нем очень подробно описаны правильные шаблоны для использования параллельных расширений .Net 4 и анти-шаблоны, которых следует избегать. Вот он.

По сути, вы хотите использовать новый ConcurrentDictionary. Сразу после установки вам нужно писать меньше кода, чтобы сделать программы потокобезопасными.

Мы использовали ConcurrentDictionary для кэшированной коллекции, которая повторно заполняется каждые 1 час, а затем читается несколькими клиентскими потоками, аналогично решению для вопроса Является ли этот пример потокобезопасным?.

Мы обнаружили, что изменение его на ReadOnlyDictionary улучшило общую производительность.