Ну вот multi-copy atomicity (MCA) -- это такая попытка. MCA говорит, что запись видна либо сразу всем процам, либо ни одному. Когда MCA нет, IRIW разваливается тривиальным способом.

До одного проца долетело сначала одно, а до другого - сначала другое.

Даже размышлений о хардваре не надо, простая физика: два сокета, на каждом проце бежит пара "читающий" и "пишущий". Внутри сокета значение от ближайшего "пищущего" прилетит быстрее, чем из другого сокета от другого "пишущего".

(Другими словами, это для *обеспечения* MCA надо попотеть, а нахаляву IRIW и так развалится)

Начинаю понимать, но нужно времч :D

По опыту скажу, что пытаться понимать абстрактную модель памяти через хардварную модель -- это только себя запутывать. Вот рассуждение про MCА -- оно про то, как просто получить фейл в хардваре.

Выныривая из хардварного, вы "просто поймите", что если вы делаете release, то это ещё не гарантия, что он "случится" в каком-то там глобальном порядке с другими acquire-ами и release-ами. (Другими словами, нет последовательной памяти, которая их сериализует). Для глобального порядка нужен более сильный seqcst.

(если это не понятно, то пропустите, это потом придёт) Можно было думать, что если один поток увидел запись, то и второй должен. А нет! Тут есть метафизический гвоздь про "если А, то Б (на разных процах)", который вообще-то про время. А под интуитивным пониманием времени таится глобальный порядок, которого без seqcst нет :D

Спасибо, буду вкуривать еще и еще - тут главное понять, что порядок не определен просто ПО ОПРЕДЕЛЕНИЮ. А я еще и вкурить пытаюсь как оно там в железе....

Про железо можно повкуривать, но вот слабость в определении развязывает руки не только хардвару, см. ниже. На хардваре проще убедиться, что такое в принципе может реализоваться, а дальше курить высокоуровневую модель ;)

Но про multi-copy atomic -- это деталь хардварной реализации. Так-то более слабый acq/rel (по отношению к seqcst) могут и компиляторы эксплуатировать, двигая независимые acq/rel-ы друг через друга. Емнип, у Саттера были такие примеры.

Могу ещё дальше мозг форматнуть. Смотрите опять на пример:
Thread 2: y = 1
Thread 3: r2 = y; // r2 <- 0
Thread 4: r3 = y; // r3 <- 1

Вы сказали, что такое возможно, потому что "Поток 3 перед потоком 2, а 4-ый после второго". И это правильный ответ. Но есть *ещё один правильный ответ*, который не очевиден без гвоздодёра:

Thread 2: y = 1   // выполнился первым
Thread 3: r2 = y; // выполнился вторым, и НЕ УВИДЕЛ 1
Thread 4: r3 = y;

Другими словами, выполнение "первый-второй-третий" НЕ говорит, что эффекты видны в таком порядке. (То есть, у нас нет некоторого строго-консенсусного последовательного хранилища) (То есть, у нас нет глобального порядка) (То есть, это самое "время" нам вообще ничем не помогает). В этом состоит гвоздь иллюзии про сериализованную память.

Хардварная аналогия, если так хочется: исполнение реально доехало до инструкций в каждом потоке в порядке "первый-второй-третий", каждый поговорил с подсистемой памяти, но получил *разные* ответы! (ввиду простых физических ограничений во время полёта обеих записей).

Лучше забудьте про аналогии с хардваром, кешами, буферами и прочим и рассуждайте в терминах happens-before итп

Если есть две операции над разными локациями и между ними не гарантируется наличие happens before, то порядок их исполнения "не определён"

какой бы язык не взять, половины фич нет, 30% сделано не так как хочется, а в итоге все равно рантайм не лезет в железо

и околонулевой interop между существующими

или гениально-великолепен, но экспоненциально сложен в процессе использования

Был уже такой. PL/1 назывался

Ичпользуйте MPI и не морочьте людям голову

И ставьте барьеры где надо в группах