Уже имеется много информации о программных и аппаратных моделях памяти, ограничениях памяти, переупорядочении хранения / загрузки и т. Д. Однако все, похоже, сосредоточено на обеспечении относительного упорядочения операций чтения и записи в общую память и из нее.
Будет ли законным поведением такой системы вообще задерживать запись потока на потенциально долгое время?
Например, рассмотрим поток, который выполняет некоторые обновления структуры данных в памяти, а затем поднимает флаг, который должен уведомить другие потоки об обновлении:
(dataWritten is initially false)
store value1
store value2
store value3
mfence
store dataWritten (true)
Согласно большинству моделей памяти, о которых я читал, барьер памяти гарантирует, что любой другой поток не может наблюдать dataWritten как истинный, при этом читая устаревшие значения 1, 2 или 3, т.е. он делает эти записи атомарными.
Но могу ли я быть уверен, что записи будут видны вообще? Будет ли законным в рамках модели памяти задерживать запись на неопределенный срок, если флаг не записывается раньше, чем значения?
С точки зрения базы данных, можно ли использовать модели памяти для рассуждений о долговечности (в дополнение к атомарности и согласованности, которые можно гарантировать с помощью ограждений и флагов памяти, как в приведенном выше примере)?
Обновление: Подробная семантика изменчивости относительно своевременности видимости обращается к той же теме в контексте модели памяти Java и упорядочивание и видимость модели памяти ? для C ++ 11. Применимо ли это обсуждение к моделям аппаратной памяти, т.е. дают ли ISA ЦП только жесткие гарантии правильной последовательности видимости, но «мягкие» гарантии отложенной видимости?
