Здравствуйте, pilgrim_, Вы писали:
_>Здравствуйте, m2user, Вы писали:
M>>HashTable не является thread safe, что проявит себя тем или иным образом (для Dictionary обычно exception) при конкурентном вызове метода Process в разных потоках.
_>В коде у ТС запись в hashtable защищена локом, а hashtable, в отличии от Dictionary, гарантирует N одновременных читателей при 1-м писателе, так что тут всё норм.
Все ли действительно норм — зависит не от того, помечен ли класс относительно потокобезопасным, а от того, совпадает ли ожидание пользователя кэша от того, как ведет себя коллекция.
А вести она себя будет так, что конкурирующие читатель и писатель не сломаются. Но что именно прочитает читатель, проскочив одновременно с писателем — точно не ясно. Либо старое значение, либо новое. Что из этого является норм, или сама неопределенность считается норм — вот тут уже надо спрашивать разработчика этого конкретного кэша. Судя, по тому, что написано в коде, ожидается, что читатели могут довольствоваться старыми значениями уже в тот момент, когда из базы прилетело новое и даже в тот момент, когда в хэштаблицу его уже "начали класть". Осью, вокруг которой крутится логика, является запись в volatile поле version. Но даже после его изменения читатель может все еще достать старое значение.
Здравствуйте, samius, Вы писали:
_>>В коде у ТС запись в hashtable защищена локом, а hashtable, в отличии от Dictionary, гарантирует N одновременных читателей при 1-м писателе, так что тут всё норм.
S>Все ли действительно норм — зависит не от того, помечен ли класс относительно потокобезопасным, а от того, совпадает ли ожидание пользователя кэша от того, как ведет себя коллекция.
"норм" относится к техническим деталям поведения hashtable.
S>А вести она себя будет так, что конкурирующие читатель и писатель не сломаются. Но что именно прочитает читатель, проскочив одновременно с писателем — точно не ясно. Либо старое значение, либо новое. Что из этого является норм, или сама неопределенность считается норм — вот тут уже надо спрашивать разработчика этого конкретного кэша. Судя, по тому, что написано в коде, ожидается, что читатели могут довольствоваться старыми значениями уже в тот момент, когда из базы прилетело новое и даже в тот момент, когда в хэштаблицу его уже "начали класть". Осью, вокруг которой крутится логика, является запись в volatile поле version. Но даже после его изменения читатель может все еще достать старое значение.
Всё верно, тот кто юзает hashtable во многопотоке должен понимать и принимать решение, как её возможности с пользой заюзать. К вопросу ТС это не относится, там что-то странное.
сверху вниз — Таймер службы, потом Parallel.ForEach — то есть перекрывающие вызовы более чем возможны, если предидущий в середине своего Parallel.ForEach а новый уже перезапросил — Bob's your uncle.
