Гарантирует ли стандарт атомарное чтение и запись данных, размер которого не более чем машинное слово?

Насколько я знаю атомарность для чтения и записи данных которые не более чем одно машинное слово, гарантируется на уровне процессора. А со стороны стандарта с++ есть подобные гарантии? Тут речь не про std::atomic, а именно про обычные переменные.

0

Сообщение от Undisputed Разберемся что из себя представляет acquire. По сути это LoadLoad LoadStore барьер памяти.

Ты опять лезешь в детали реализации...
Можно без блокирующихся ядер?

Сообщение от Undisputed LoadLoad применяются к invalidate queue процессора (заставляет процессор выполнить синхронизацию типа "чтение" с кэшами других процессоров. в эту очередь помещаются сообщения об изменении данных другими ядрами).

Насколько я помню, в общем случае барьеры просто не дают переставлять определённые операции через барьер.
Откуда дополнительные свойства барьеров?

Сообщение от Undisputed Стандарт в свою очередь насколько я понимаю просто требует

Нет, не требует. Это то редкое место, где стандарт не требует. Такие места, наверное, можно по пальцам одной руки пересчитать.
Требует это "shall", а тут "should". Т.е. он рекомендует. Очень размытыми формулировками, про некое "reasonable amount of time".

Сообщение от Undisputed [29.3/12] Implementations should make atomic stores visible to atomic loads within a reasonable amount of time.

В [intro.multithreaded] есть похожая цитата, но более подробная (как раз про last value):

Сообщение от http://eel.is/c++draft/intro.multithread#intro.progress-18 An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time.

Т.е. стандарт рекомендует, чтобы последнее значение стало видимым всем потокам за конечное время (10 млн. лет — это вполне конечное время).
Эта цитата как бы тоже не на стороне твоего утверждения про гарантию чтения последнего значения, т.к. видно, что существование последнего значения и его видимость другим потокам стандарт разделяет. Т.е. оно может существовать, но потоку, выполняющему load acquire, оно может быть не видимо в течение произвольного, но конечного (следующие 10 млн. лет после появления, например) периода времени.

Ну и самое главное: я переформулировал перевод так, что он звучит ближе к оригиналу.
Почему стандарт не говорит нам, что load acquire берёт значение из последнего store release или из последнего side effect-а в modification order, а от любого side effect-a из release sequence (начинающейся с определённого store release)?

Сообщение от Undisputed Вот именно по этой причине я и говорил что будет прочитано последнее значение.

То есть, в предположении неких блокирующихся ядер и прочих invalidation queue, и в предположении определённого отображения конструкций языка (и стандартной библиотеки) на аппаратные особенности, будет читаться последнее значение?
Вроде вопрос был про гарантию со стороны стандарта...

0

Сообщение от SeqInconsistent Требует это "shall", а тут "should". Т.е. он рекомендует.

Да, should это рекомендует. Как то забыл про техническую терминологию.

Сообщение от SeqInconsistent Насколько я помню, в общем случае барьеры просто не дают переставлять определённые операции через барьер. Откуда дополнительные свойства барьеров?

Ты сейчас про барьеры процессорного уровня или про барьеры компилятора?
Если на уровне процессора, тогда это самое "не дают переставлять" как раз таки достигается принудительным освобождением очередей ядра (store и load очереди).
Вот например отсюда:
https://mechanical-sympathy.bl... ences.html

A load barrier, “lfence” instruction on x86, ensures all load instructions after the barrier to happen after the barrier and then wait on the load buffer to drain for the issuing CPU. This makes program state exposed from other CPUs visible to this CPU before making further progress.

Сообщение от SeqInconsistent Т.е. стандарт рекомендует, чтобы последнее значение стало видимым всем потокам за конечное время (10 млн. лет — это вполне конечное время).

Да, видел это в стандарте. Но спецом процитировал пункт [29.3/12] что бы показать тот факт что сам стандарт сторонник того что "этот процесс должен происходить как можно скорее без лишних задержек, если они не оправданы".
На мой взгляд это означает то, что если компилятор должен где то поставить барьер, то не нужно совать еще какие то инструкции до барьера, которые напрямую не связаны с контекстом выполнения. Наверное так обычно и делается. Думаю это просто напоминание разработчикам компиляторов.

Сообщение от SeqInconsistent Вроде вопрос был про гарантию со стороны стандарта...

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

0