надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно

Здравствуйте, mihhon, Вы писали:

M>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно

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

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

ок, спасибо

в моём случае значения — объекты, т.е. не нужно лочить ?

Здравствуйте, mihhon, Вы писали:

M>ок, спасибо

M>в моём случае значения — объекты, т.е. не нужно лочить ?

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

Здравствуйте, mihhon, Вы писали:

M>ок, спасибо

M>в моём случае значения — объекты, т.е. не нужно лочить ?

Например, при перезаписи значения обновляется версия. Код обновления — прост, как палка: version++. Эта операция тоже неатомарна и может где-нить боком вылезти.

L>Например, при перезаписи значения обновляется версия. Код обновления — прост, как палка: version++. Эта операция тоже неатомарна и может где-нить боком вылезти.
да, интересно

в таком случае надо вместо значения полжить контейнер значения

плохо, что ошибка не вываливается в случае с dictionary в случае проблемы ...

Здравствуйте, mihhon, Вы писали:

M>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно

Можно ответить вопросом на вопрос? Как думаешь, можно ли читать из двусвязного списка без лока, а лочить только при записи в него? Мне чего-то кажется, что делать этого не стоит, даже при учете, что там нет таких перераспределений памяти, как в обыкновенном списке, никто не будет гаранитировать, что в каждый момент времени выполнения операции записи двусвязный список будет находиться в согласованном (с точки зрения пользователя) состоянии. А поскольку все хэш-таблицы внутри релизованы как набор bucket-ов, каждый из которых представляет собой какой-то вид списка, то и читать Dictionaly без лока также кажется небезопасным. Так что тут даже дело не в том, является ли значение, расположенное в словаре изменяемым или нет.

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

M>>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно

ST>Можно ответить вопросом на вопрос? Как думаешь, можно ли читать из двусвязного списка без лока, а лочить только при записи в него? Мне чего-то кажется, что делать этого не стоит, даже при учете, что там нет таких перераспределений памяти, как в обыкновенном списке, никто не будет гаранитировать, что в каждый момент времени выполнения операции записи двусвязный список будет находиться в согласованном (с точки зрения пользователя) состоянии. А поскольку все хэш-таблицы внутри релизованы как набор bucket-ов, каждый из которых представляет собой какой-то вид списка, то и читать Dictionaly без лока также кажется небезопасным. Так что тут даже дело не в том, является ли значение, расположенное в словаре изменяемым или нет.
если набор ключей не меняется, букеты и их списки будут теми же самыми

ST>Кроме того, для этих целей придуман ReaderWriterLockSlim, который позволяет одновременное чтение множеством потоков, пока на сцену не вылезет читающий поток.
я, похоже, профессинал в использовании ReaderWriterLockSlim http://rsdn.ru/forum/dotnet/4128197.aspx

Автор: mihhon
Дата: 24.01.11

Здравствуйте, mihhon, Вы писали:

M>>>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно

M>если набор ключей не меняется, букеты и их списки будут теми же самыми

Т.е. сам Dictionary не меняться, а может меняться только содержимое значений? Тогда, если типы-значения thread-safe, то работа с Dictionary тоже будет thread-safe. Просто меня смутило выделенное; мне под словом "запись" понимается запись в словарь (т.е. именно его изменение), а не изменение значений уже лежащих в словаре

Если же типы значения не thread-safe, то возможно будет нужна синхронизация и на чтение и на запись, поскольку при чтении ты можешь получить некорректные значения, причем это будет выражаться не в гонках (когда ты получишь предыдущее значение, когда мог бы получить уже новое); вполне вероятно, что объект будет находиться в процессе изменения, т.е. он уже не будет в предыдущем состоянии, но еще не перейдет в новое (будет такой себе dirty read).

ST>Если же типы значения не thread-safe, то возможно будет нужна синхронизация и на чтение и на запись, поскольку при чтении ты можешь получить некорректные значения, причем это будет выражаться не в гонках (когда ты получишь предыдущее значение, когда мог бы получить уже новое); вполне вероятно, что объект будет находиться в процессе изменения, т.е. он уже не будет в предыдущем состоянии, но еще не перейдет в новое (будет такой себе dirty read).
это да