ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 22:12
Оценка:
ConcurrentDictionary гарантирует безопасность объектов (если исходить из предположения, что они read-only), или нужны какие-то дополнительные движения с бубном?
Документация чего-то не рассматривает этот вопрос
Ад пуст, все бесы здесь.
Отредактировано 18.02.2022 22:20 Codealot . Предыдущая версия .
Re: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 22:22
Оценка: +6
Здравствуйте, Codealot, Вы писали:

C>ConcurrentDictionary гарантирует безопасность reference types, или нужны какие-то дополнительные движения с бубном? Документация чего-то не рассматривает этот вопрос

Все, что гарантирует ConcurrentDictionary, написано в его документации и его гарантии никак не распространяются на все остальное. Если в его значениях ссылки, то словарь гарантирует что ссылка будет приписана к значению. А каким образом там пользователь словаря работает с тем, на что ссылка ссылается — не словаря дело.
Re[2]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 22:28
Оценка:
Здравствуйте, samius, Вы писали:

S>Все, что гарантирует ConcurrentDictionary, написано в его документации и его гарантии никак не распространяются на все остальное. Если в его значениях ссылки, то словарь гарантирует что ссылка будет приписана к значению. А каким образом там пользователь словаря работает с тем, на что ссылка ссылается — не словаря дело.


Да ничего там толком не написано. Например, есть ли там какой-то барьер памяти при добавлении?
Ад пуст, все бесы здесь.
Re[3]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 22:40
Оценка:
Здравствуйте, Codealot, Вы писали:

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


C>Да ничего там толком не написано. Например, есть ли там какой-то барьер памяти при добавлении?

Это детали реализации, а не документации. Т.е. если нам ничего не сказано про барьеры памяти, значит, мы не должны рассчитывать на то, что они есть, или что их нет. Потому, как завтра это может измениться.

Но да, использует, если поглядеть в код.
Re[4]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 22:54
Оценка: :)))
Здравствуйте, samius, Вы писали:

S>Это детали реализации, а не документации.


Это очень важная деталь реализации, которая легко может поставить крест на возможности использовать эту коллекцию.

S> Т.е. если нам ничего не сказано про барьеры памяти, значит, мы не должны рассчитывать на то, что они есть, или что их нет. Потому, как завтра это может измениться.


У Parallel.ForEach тоже про это ничего не написано. Что наводит на мысль, что документацию просто писали кретины. Если с ними нельзя использовать объекты — то про это надо бы написать большими красными буквами, не?
Ад пуст, все бесы здесь.
Re[5]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 23:14
Оценка: +2
Здравствуйте, Codealot, Вы писали:

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


C>Это очень важная деталь реализации, которая легко может поставить крест на возможности использовать эту коллекцию.

Очень многие нашли возможным использовать эту коллекцию. Сам ей пользуюсь. Про то, что ее реализация (одна из) использует барьеры памяти узнал только что. До этого не был уверен и это ничего не меняло в возможности мной использовать эту коллекцию. Может быть я что-то делаю не так?

S>> Т.е. если нам ничего не сказано про барьеры памяти, значит, мы не должны рассчитывать на то, что они есть, или что их нет. Потому, как завтра это может измениться.


C>У Parallel.ForEach тоже про это ничего не написано. Что наводит на мысль, что документацию просто писали кретины. Если с ними нельзя использовать объекты — то про это надо бы написать большими красными буквами, не?

В каком смысле нельзя использовать объекты? Почему нельзя? Кто это сказал?
Re[2]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 23:22
Оценка:
Здравствуйте, samius, Вы писали:

S>Все, что гарантирует ConcurrentDictionary, написано в его документации и его гарантии никак не распространяются на все остальное.


PS если объект нельзя вообще использовать даже если ты просто его поместил и потом извлек, то что толку от такой коллекции? Наверно, какие-то гарантии всё же есть. Но документация про это умалчивает.
Ад пуст, все бесы здесь.
Re[3]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 23:27
Оценка: +1
Здравствуйте, Codealot, Вы писали:

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


S>>Все, что гарантирует ConcurrentDictionary, написано в его документации и его гарантии никак не распространяются на все остальное.


C>PS если объект нельзя вообще использовать даже если ты просто его поместил и потом извлек, то что толку от такой коллекции? Наверно, какие-то гарантии всё же есть. Но документация про это умалчивает.


Я не понимаю, почему нельзя использовать объект от того, что я его куда-то поместил и потом извлек? С объектом ничего не происходит в момент добавления. В чем проблема его использовать?
Re[6]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 23:27
Оценка: -6
Здравствуйте, samius, Вы писали:

S>Очень многие нашли возможным использовать эту коллекцию. Сам ей пользуюсь. Про то, что ее реализация (одна из) использует барьеры памяти узнал только что. До этого не был уверен и это ничего не меняло в возможности мной использовать эту коллекцию. Может быть я что-то делаю не так?


Да, ты всё делаешь совершенно не так. Ты пишешь многопоточный код и не понимаешь, как он работает и корректен ли вообще. Сегодня он работает, а потом звезды встанут неправильно и всё взорвется к черту.

S>В каком смысле нельзя использовать объекты? Почему нельзя? Кто это сказал?


Ну ты сам сказал что если ничего не написано про барьер памяти, то полагаться на это нельзя. А если полагаться на него нельзя, то использовать там объекты тоже нельзя. Потому что read/write reordering и прочие хтонические ужасы.
Ад пуст, все бесы здесь.
Re[4]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 23:28
Оценка:
Здравствуйте, samius, Вы писали:

S>Я не понимаю, почему нельзя использовать объект от того, что я его куда-то поместил и потом извлек? С объектом ничего не происходит в момент добавления. В чем проблема его использовать?


Поместил на одном ядре, извлек на другом. Что там и в каком порядке и когда пишется/читается — это такая загадка, от которой свихнулся бы даже сам Хокинг.
Ад пуст, все бесы здесь.
Re[7]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 23:32
Оценка: +2 -1
Здравствуйте, Codealot, Вы писали:

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


S>>Очень многие нашли возможным использовать эту коллекцию. Сам ей пользуюсь. Про то, что ее реализация (одна из) использует барьеры памяти узнал только что. До этого не был уверен и это ничего не меняло в возможности мной использовать эту коллекцию. Может быть я что-то делаю не так?


C>Да, ты всё делаешь совершенно не так. Ты пишешь многопоточный код и не понимаешь, как он работает и корректен ли вообще. Сегодня он работает, а потом звезды встанут неправильно и всё взорвется к черту.

Я пишу код, исходя из того, что словарь работает, пока никто не доказал обратное.

S>>В каком смысле нельзя использовать объекты? Почему нельзя? Кто это сказал?


C>Ну ты сам сказал что если ничего не написано про барьер памяти, то полагаться на это нельзя. А если полагаться на него нельзя, то использовать там объекты тоже нельзя. Потому что read/write reordering и прочие хтонические ужасы.


Какое отношение имеет реордеринг в реализации словаря к объектам, которые я в него добавляю по ссылке?
Re[5]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 18.02.22 23:35
Оценка: +5
Здравствуйте, Codealot, Вы писали:

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


S>>Я не понимаю, почему нельзя использовать объект от того, что я его куда-то поместил и потом извлек? С объектом ничего не происходит в момент добавления. В чем проблема его использовать?


C>Поместил на одном ядре, извлек на другом. Что там и в каком порядке и когда пишется/читается — это такая загадка, от которой свихнулся бы даже сам Хокинг.


Никакой загадки нет, словарь гарантирует корректный доступ к своему содержимому. Учитывая то, что содержимое — это ассоциации ключ-значение и только лишь. В отношении объектов, которые лежат по ссылкам в значениях — никаких гарантий нет.
Re[8]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 23:58
Оценка: :)
Здравствуйте, samius, Вы писали:

S>Я пишу код, исходя из того, что словарь работает, пока никто не доказал обратное.


Ты не знаешь, кто конкретно там работает и какие гарантии даются.

S>Какое отношение имеет реордеринг в реализации словаря к объектам, которые я в него добавляю по ссылке?


Я говорю о реордеринге памяти. Ты вообще понял, о чем идет речь?
Ад пуст, все бесы здесь.
Re[6]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 18.02.22 23:58
Оценка: :)))
Здравствуйте, samius, Вы писали:

S>В отношении объектов, которые лежат по ссылкам в значениях — никаких гарантий нет.


Тогда такой словарь попросту нельзя использовать с объектами и их использование нужно запретить. Чего не наблюдается.
Ад пуст, все бесы здесь.
Re[7]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 19.02.22 00:01
Оценка: +4
Здравствуйте, Codealot, Вы писали:

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


S>>В отношении объектов, которые лежат по ссылкам в значениях — никаких гарантий нет.


C>Тогда такой словарь попросту нельзя использовать с объектами и их использование нужно запретить. Чего не наблюдается.

Мыло-мочало, начинай сначала
Re[9]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 19.02.22 00:02
Оценка: +1 :)
Здравствуйте, Codealot, Вы писали:

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


C>Я говорю о реордеринге памяти. Ты вообще понял, о чем идет речь?

Про реордеринг инструкций — слышал. Про барьеры памяти — тоже. Реордерниг памяти — о чем ты?
Re[7]: ConcurrentDictionary vs reference type
От: karbofos42 Россия  
Дата: 19.02.22 07:54
Оценка: 3 (1) +2 -1 :))
Здравствуйте, Codealot, Вы писали:

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


S>>Очень многие нашли возможным использовать эту коллекцию. Сам ей пользуюсь. Про то, что ее реализация (одна из) использует барьеры памяти узнал только что. До этого не был уверен и это ничего не меняло в возможности мной использовать эту коллекцию. Может быть я что-то делаю не так?


C>Да, ты всё делаешь совершенно не так. Ты пишешь многопоточный код и не понимаешь, как он работает и корректен ли вообще. Сегодня он работает, а потом звезды встанут неправильно и всё взорвется к черту.


S>>В каком смысле нельзя использовать объекты? Почему нельзя? Кто это сказал?


C>Ну ты сам сказал что если ничего не написано про барьер памяти, то полагаться на это нельзя. А если полагаться на него нельзя, то использовать там объекты тоже нельзя. Потому что read/write reordering и прочие хтонические ужасы.


На msdn к этому классу есть документация и поведение всех методов расписано достаточно подробно.
Например, метод AddOrUpdate гарантирует, что в результате будет в словаре уникальный ключ, но не гарантирует, что переданный делегат на добавление или изменение значения вызовется один раз.
Допустим, 10 потоков вызвали этот метод одновременно для одного и того же ключа. Все 10 потоков увидят, что такого элемента в словаре ещё нет и каждый создаст свой объект для добавления в словарь.
В словарь же добавится только один из этих объектов и все 10 потоков получат в качестве результата один и тот же объект (который попал в словарь, а не который в этом потоке был создан).
9 потоков выполнят ненужную работу и создадут ненужные объекты. Это поведение расписано и именно его нужно учитывать, зачем тут в реализации разбираться, если словарь ведёт себя так, как описано в документации?
Я думал, что документацию для того и делают, чтобы людям не приходилось копаться в реализации и выяснять как что работает.
Если документацию не читать, а использовать классы по наитию, то тут уже конечно нельзя ни на что полагаться
Re[7]: ConcurrentDictionary vs reference type
От: Teolog  
Дата: 19.02.22 11:27
Оценка: +1 :)
C>Тогда такой словарь попросту нельзя использовать с объектами и их использование нужно запретить. Чего не наблюдается.

Словарь хранит ссылки и позволяет их добавлять и удалять из разных потоков без самопальной внешней синхронизации. Это все для чего он предназначен, и все что делает.
Синхронизация доступа в содержимому объекта по ссылке-отдельный веселый вопрос, который к словарю никакого отношения не имеет, и должен решаться вне зависимости от существования, не-существования, реализации и наличия документации на словарь, тем кто делал класс объекта.
Re[10]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 19.02.22 15:15
Оценка:
Здравствуйте, samius, Вы писали:

S>Про реордеринг инструкций — слышал. Про барьеры памяти — тоже. Реордерниг памяти — о чем ты?


Есть такие штуки — кэш-линии. Хотя бы про них ты слышал?
Ад пуст, все бесы здесь.
Re[8]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 19.02.22 15:15
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Я думал, что документацию для того и делают, чтобы людям не приходилось копаться в реализации и выяснять как что работает.


Там не ответов на вопросы, которые я задал.
Ад пуст, все бесы здесь.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.