Что лучший способ реализовать ориентированный на многопотоковое исполнение Словарь?

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

public void Add(TKey key, TValue value)
{
    lock (this.syncRoot)
    {
        this.innerDictionary.Add(key, value);
    }
}

public bool ContainsKey(TKey key)
{
    lock (this.syncRoot)
    {
        return this.innerDictionary.ContainsKey(key);
    }
}

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

if (!mySafeDictionary.ContainsKey(someKey))
{
    mySafeDictionary.Add(someKey, someValue);
}

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

, Что означает писать этот тип сценария правильно, Вам нужна блокировка внешний словарь, например,

lock (mySafeDictionary)
{
    if (!mySafeDictionary.ContainsKey(someKey))
    {
        mySafeDictionary.Add(someKey, someValue);
    }
}

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

1. Использование нормальное Dictionary<TKey, TValue> и синхронизируется внешне, включая составные операции на нем, или

2. Запись новая ориентированная на многопотоковое исполнение обертка с различным интерфейсом (т.е. не IDictionary<T>), который комбинирует операции такой как AddIfNotContained метод, таким образом, Вы никогда не должны комбинировать операции от него.

(я склонен идти с № 1 сам)

Вы не должны публиковать свой частный объект блокирования через свойство. Объект блокирования должен существовать конфиденциально для единственной цели действовать как точка рандеву.

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

Существует несколько проблем с методом внедрения, который Вы описываете.

1. Вы никогда не должны представлять свой объект синхронизации. Выполнение так откроется потребителю, захватывающему объект и берущему блокировку на нем, и затем Вы - тост.
2. Вы реализуете неориентированный на многопотоковое исполнение интерфейс с ориентированным на многопотоковое исполнение классом. По моему скромному мнению, это будет стоить Вам в будущем

Лично, я нашел, что лучший способ реализовать ориентированный на многопотоковое исполнение класс через неизменность. Это действительно сокращает количество проблем, с которыми можно столкнуться с потокобезопасностью. Выезд Блог Eric Lippert для получения дополнительной информации.

Вы не должны блокировать свойство SyncRoot в своих потребительских объектах. Блокировка, которую Вы имеете в рамках методов словаря, достаточна.

Для Разработки: , Что заканчивает тем, что произошло, то, что Ваш словарь заблокирован в течение более длительного промежутка времени, чем необходимо.

то, Что происходит в Вашем случае, следующее:

Говорят, что поток A получает блокировку на SyncRoot прежде вызов к m_mySharedDictionary. Добавить. Распараллельте B, тогда пытается получить блокировку, но заблокирован. На самом деле все другие потоки заблокированы. Потоку A позволяют звонить в Добавить метод. В операторе блокировки в рамках Добавить метода A потока позволяют получить блокировку снова, потому что это уже владеет им. После выхода из контекста блокировки в рамках метода и затем вне метода, A потока выпустил все блокировки, позволяющие другие потоки продолжаться.

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

наборы и синхронизация