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

X>Ты ниже кода, котрый ты скопипастил из статьи не прочитал что-ли?

1) Прочитал. А ты в курсе, что текущая версия — уже давно 6, и в ней в отличии от 4.5 поддерживается к примеру ARM, в котором гарантии которые дает железо совсем другие?
2) "Код нарушает спецификацию, но все равно работает, так что пофиг" — за такое надо вообще гнать из профессии, улицы мести. Или как минимум наказывать каторжными работами в техсаппорте.

X>А в CLR 4 (2010 год) в отношении гарантий по памяти ничего не поменялось. CLR 3 не было, CLR 5+ еще не было. Или ты не знал?

См выше.

X>Для .net, который компилируется в CIL и только потом CLR-ом в нейтив — нет. Т.к. CLR добавляет барьеры для платформ там где требуется.

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

X>Тогда уточни вопрос из первого сообщения темы: что за опасность подстерегает объекты, когда они хранятся в ConcurrentDictionary?
X>А прям идеально было бы кусок кода, который ведет себя некорректно при использовании ConcurrentDictionary.

Повторю еще раз, для самых-самых чукчеписателей.
Если там есть гарантированные барьеры памяти (в том числе и при извлечении), то никаких проблем быть не должно.
Если же никаких гарантий нет, как утверждает samius

Автор: samius
Дата: 19.02.22

, то использовать CD таким образом — некорректно.
Доходит?

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

X>>Для .net, который компилируется в CIL и только потом CLR-ом в нейтив — нет. Т.к. CLR добавляет барьеры для платформ там где требуется.

C>Например, когда говнокодеры пишут некорректный код и разработчикам CLR приходится стелить соломку, как я уже приводил пример.

Пример подкладывания соломки? Похоже я пропустил. Я вообще не видел от тебя примеров кода, кроме попыток попказать какой бывает reordering.

X>>Тогда уточни вопрос из первого сообщения темы: что за опасность подстерегает объекты, когда они хранятся в ConcurrentDictionary?
X>>А прям идеально было бы кусок кода, который ведет себя некорректно при использовании ConcurrentDictionary.
C>Повторю еще раз, для самых-самых чукчеписателей.
Т.е. кода не будет. Можешь дальше не продолжать.

Выглядит все так, будто откопал древний-предревний баян, про который все давно знают, а то и успели забыть, а тебе явилось откровение.
Я понимаю когда люди спрашивают у коллеги и/или на форуме вместо того что бы погуглить ответ, что бы сэкономить свое время за счет чужого.
Но тебе же даже ответы не нужны.

C>Если там есть гарантированные барьеры памяти (в том числе и при извлечении), то никаких проблем быть не должно.
О! Прогрес. Фаза отрицания сменилась на фазу сомнения.

C>... использовать CD таким образом — некорректно.
Каким "таким" образом? Ты же не привел не единой строчки кода с использованием CD

з.ы. итог для тех кому интересен итог:
краткий список правил clr memory model:

Rule 1: Data dependence among loads and stores is never violated.

Rule 2: All stores have release semantics, i.e. no load or store may move after one.

Rule 3: All volatile loads are acquire, i.e. no load or store may move before one.

Rule 4: No loads and stores may ever cross a full-barrier (e.g. Thread.MemoryBarrier, lock acquire, Interlocked.Exchange, Interlocked.CompareExchange, etc.).

Rule 5: Loads and stores to the heap may never be introduced.

Rule 6: Loads and stores may only be deleted when coalescing adjacent loads and stores from/to the same location.

в зависимости от аппаратной платформы CLR генерирует соотвествуюущие инструкции процессора для соблюдения вышеуказанных правил.

для типового использования:

globalAccessibleVar = new SomeClass(...); // thread 1
var f = globalAccessibleVar.someField; // any other thread

Rule 2 не позволяет записать поле объекта после ссылки на объект и Rule 1 не позволяет прочитать поле объекта до чтения сслки на объект.

потенциально можно отдать ссылку на недокоструированный объект из конструктора, и тогда появится возможность прочитать нули из неинициализированных полей.
Но тут я процитирую коментарий от Eric Lippert-а: https://stackoverflow.com/questions/51180784/can-memory-reordering-cause-c-sharp-to-access-unallocated-memory

EL> the CLR guarantees you that its own invariants will be preserved.
EL> But the CLR is not in the business of preserving your invariants!

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

X>Пример подкладывания соломки? Похоже я пропустил. Я вообще не видел от тебя примеров кода, кроме попыток попказать какой бывает reordering.

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

This is the relevant part of LazyExample (recall that none of the fields are volatile):
XML

b = new BoxedInt();
b._value = 42; // Write 1
// DMB will be emitted here
_boxedInt = b; // Write 2

Because the CLR JIT emits the DMB instructions prior to the publication of the object into the _boxedInt field, Write 1 and Write 2 will not be reordered. And because ARM respects data dependence, the reads in the lazy initialization pattern will not be reordered either, and the code will work correctly on ARM.

So, the CLR JIT makes an extra effort (beyond what’s mandated in the ECMA C# spec) to keep the most common variant of incorrect lazy initialization working on ARM.

Также повторю про пример из сообщения выше, который совершенно точно некорректен согласно стандарту — как английским по белому написано в статье, но ты оправдывался тем что "но в версии 4.5 же всё равно работает, значит никаких проблем нигде быть не должно!!!111"