надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно
Re: лочить доступ к Dictionary,если кол-во эл-тов не меняетс
Здравствуйте, mihhon, Вы писали:
M>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно
В общем случае все равно нужно. Например, если у вас значениями являются кастомные структуры, для них операция записи значения в bucket будет натомарной и есть шанс получить неконсистентное значение.
Re[2]: лочить доступ к Dictionary,если кол-во эл-тов не меня
L>В общем случае все равно нужно. Например, если у вас значениями являются кастомные структуры, для них операция записи значения в bucket будет натомарной и есть шанс получить неконсистентное значение.
ок, спасибо
в моём случае значения — объекты, т.е. не нужно лочить ?
Re[3]: лочить доступ к Dictionary,если кол-во эл-тов не меня
Здравствуйте, mihhon, Вы писали:
M>ок, спасибо
M>в моём случае значения — объекты, т.е. не нужно лочить ?
Например, при перезаписи значения обновляется версия. Код обновления — прост, как палка: version++. Эта операция тоже неатомарна и может где-нить боком вылезти.
Re[4]: лочить доступ к Dictionary,если кол-во эл-тов не меня
L>Например, при перезаписи значения обновляется версия. Код обновления — прост, как палка: version++. Эта операция тоже неатомарна и может где-нить боком вылезти.
да, интересно
в таком случае надо вместо значения полжить контейнер значения
плохо, что ошибка не вываливается в случае с dictionary в случае проблемы ...
Re: лочить доступ к Dictionary,если кол-во эл-тов не меняетс
Здравствуйте, mihhon, Вы писали:
M>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно
Можно ответить вопросом на вопрос? Как думаешь, можно ли читать из двусвязного списка без лока, а лочить только при записи в него? Мне чего-то кажется, что делать этого не стоит, даже при учете, что там нет таких перераспределений памяти, как в обыкновенном списке, никто не будет гаранитировать, что в каждый момент времени выполнения операции записи двусвязный список будет находиться в согласованном (с точки зрения пользователя) состоянии. А поскольку все хэш-таблицы внутри релизованы как набор bucket-ов, каждый из которых представляет собой какой-то вид списка, то и читать Dictionaly без лока также кажется небезопасным. Так что тут даже дело не в том, является ли значение, расположенное в словаре изменяемым или нет.
Кроме того, для этих целей придуман ReaderWriterLockSlim, который позволяет одновременное чтение множеством потоков, пока на сцену не вылезет читающий поток.
Re[2]: лочить доступ к Dictionary,если кол-во эл-тов не меня
M>>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно
ST>Можно ответить вопросом на вопрос? Как думаешь, можно ли читать из двусвязного списка без лока, а лочить только при записи в него? Мне чего-то кажется, что делать этого не стоит, даже при учете, что там нет таких перераспределений памяти, как в обыкновенном списке, никто не будет гаранитировать, что в каждый момент времени выполнения операции записи двусвязный список будет находиться в согласованном (с точки зрения пользователя) состоянии. А поскольку все хэш-таблицы внутри релизованы как набор bucket-ов, каждый из которых представляет собой какой-то вид списка, то и читать Dictionaly без лока также кажется небезопасным. Так что тут даже дело не в том, является ли значение, расположенное в словаре изменяемым или нет.
если набор ключей не меняется, букеты и их списки будут теми же самыми
ST>Кроме того, для этих целей придуман ReaderWriterLockSlim, который позволяет одновременное чтение множеством потоков, пока на сцену не вылезет читающий поток.
я, похоже, профессинал в использовании ReaderWriterLockSlim http://rsdn.ru/forum/dotnet/4128197.aspx
Здравствуйте, mihhon, Вы писали:
M>>>надо ли лочить доступ к Dictionary, если количество элементов не меняется? Доступ при чтении через индексер и итератор, при записи через индексер. То, что элементы могут измениться в момент пробежки итератора — не важно
M>если набор ключей не меняется, букеты и их списки будут теми же самыми
Т.е. сам Dictionary не меняться, а может меняться только содержимое значений? Тогда, если типы-значения thread-safe, то работа с Dictionary тоже будет thread-safe. Просто меня смутило выделенное; мне под словом "запись" понимается запись в словарь (т.е. именно его изменение), а не изменение значений уже лежащих в словаре
Если же типы значения не thread-safe, то возможно будет нужна синхронизация и на чтение и на запись, поскольку при чтении ты можешь получить некорректные значения, причем это будет выражаться не в гонках (когда ты получишь предыдущее значение, когда мог бы получить уже новое); вполне вероятно, что объект будет находиться в процессе изменения, т.е. он уже не будет в предыдущем состоянии, но еще не перейдет в новое (будет такой себе dirty read).
Re[4]: лочить доступ к Dictionary,если кол-во эл-тов не меня
ST>Если же типы значения не thread-safe, то возможно будет нужна синхронизация и на чтение и на запись, поскольку при чтении ты можешь получить некорректные значения, причем это будет выражаться не в гонках (когда ты получишь предыдущее значение, когда мог бы получить уже новое); вполне вероятно, что объект будет находиться в процессе изменения, т.е. он уже не будет в предыдущем состоянии, но еще не перейдет в новое (будет такой себе dirty read).
это да