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

Ответ 1

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

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

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

Теперь рассмотрим это. В магазине с одним клерком, что, если вы доберетесь до передней части линии и спросите клерка "У вас есть туалетная бумага", и он говорит "Да", а затем вы идете "Хорошо, я", я вернусь к вам, когда я знаю, сколько мне нужно ", то к тому времени, когда вы вернетесь на фронт линии, магазин, конечно же, может быть распродан. Этот сценарий не предотвращается сборкой потоковых сетей.

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

Есть хороший курс о параллельных коллекциях в С#: Совлокальные коллекции Pluralsight