Исходный код вики ConcurrentDictionary
Версия 11.1 от Alexandr Fokin на 2022/01/03 15:31
Последние авторы
| author | version | line-number | content |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | **Описание работы метода AddOrUpdate**: | ||
| 4 | В dictionary есть одно значение по ключу key1 - val1. | ||
| 5 | |||
| 6 | 1) Поток th1 запускает Update делегат по ключу key1. (Фиксирует текущее значение th1_v) | ||
| 7 | 2) Поток th2 запускает Update делегат по ключу key1. (Фиксирует текущее значение th2_v) | ||
| 8 | 3) Поток th2 заканчивает выполнение делегата Update. th1 сравнивает val1 = th2_v (Через equils). | ||
| 9 | Значение равны и th2 сохраняет результат. | ||
| 10 | 4) Поток th1 заканчивает выполнение делегата Update. th2 сравнивает val1 = th1_v (Через equils). | ||
| 11 | Значение НЕ равны и th2 повторно вызывает Update делегат. | ||
| 12 | (Если элемент был удален, то запустить делегат Add) | ||
| 13 | !Повторного вызова делегата не произойдет, в случает если результат работы th2 эквивалентен исходному начальному значению val1. | ||
| 14 | |||
| 15 | Получается, что ни вызов AddOrUpdate, ни вызов конкретного делегата (Add/Update) сам по себе не блокирует значение в коллекции и не препятствует в изменении другими потокам. | ||
| 16 | |||
| 17 | По сути мы получаем **оптимистичную блокировку**. В случае неудачи которой, повторно вызывается действие обработки (add/update) для измененного значения по указанному ключу. | ||
| 18 | Критерием сравнения блокировки является Equils. В таком случае возможно имеет смысл перегрузка Equils и наличии в сущности некоторого ключевого поля. Нечто вроде Change Version TimeStamp. |