Здравствуйте, 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!

Здравствуйте, 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!