Краткий ответ

Acquire-release устанавливает отношение публикации: записи, выполненные до операции с семантикой release, становятся видимыми потоку после операции acquire, если acquire наблюдает соответствующее значение. Это не создаёт единого глобального порядка всех атомарных операций. Sequentially consistent дополнительно требует единого порядка последовательных атомарных операций, согласованного с отношением happens-before.

Исторический контекст

До появления стандартизированной модели памяти в C++11 переносимость многопоточного кода между реализациями была ограниченной: стандарт не описывал единый набор гарантий для атомарности, видимости записей и переупорядочивания операций. C++11 ввёл модель памяти и разные порядки атомарных операций, чтобы отделить необходимую синхронизацию от более дорогих гарантий глобального порядка.

Порядок по умолчанию — sequentially consistent, поэтому он проще для рассуждений, но иногда задаёт более сильные ограничения, чем требуется алгоритму. Acquire-release позволяет выразить однонаправленную публикацию данных без требования глобально упорядочить независимые атомарные операции.

Постановка проблемы

Рассмотрим публикацию готового объекта через атомарный флаг. Один поток сначала изменяет обычные данные, затем устанавливает флаг с release. Другой поток ждёт флаг с acquire и после успешного чтения обращается к этим данным.

Если заменить acquire на relaxed, атомарность самого флага сохранится, но связь между записью данных и последующим чтением не возникнет. Тогда обычные данные могут читаться без необходимого отношения happens-before, что при конкурентном доступе приводит к гонке данных и неопределённому поведению.

Обратная ошибка тоже распространена: использовать sequential consistency там, где требуется только публикация. Это упрощает доказательство корректности, но может ограничить производительность и скрыть реальную структуру алгоритма.

Подробное решение

Операция release не позволяет предшествующим ей обычным записям «перейти» за точку публикации с точки зрения модели памяти. Операция acquire, которая читает значение, опубликованное release-операцией, устанавливает отношение synchronizes-with. Через него все действия до release становятся видимыми как предшествующие действиям после acquire.

#include <atomic>
#include <thread>

int data = 0;
std::atomic<bool> ready{false};

void producer() {
    data = 42;
    ready.store(true, std::memory_order_release);
}

void consumer() {
    while (!ready.load(std::memory_order_acquire)) {}
    int value = data;
}

После acquire-чтения значения true поток consumer может безопасно читать data: запись data = 42 happens-before этим чтением. Сам data не обязан быть атомарным, потому что синхронизация устраняет конфликтующие несогласованные обращения в данном сценарии.

Acquire-release не означает, что все атомарные операции в программе получают общий порядок. Например, два потока могут по-разному наблюдать независимые атомарные переменные, если алгоритм не добавляет соответствующую синхронизацию. Кроме того, acquire не публикует последующие записи, а release не делает последующие чтения ожидающими или блокирующими.

Для операции чтения обычно выбирают memory_order_acquire, для записи-флага — memory_order_release. Для атомарной операции, которая одновременно читает и публикует состояние, может потребоваться acq_rel. memory_order_seq_cst добавляет единый общий порядок всех seq_cst-операций; это сильнее, чем обычная пара release/acquire.

Важна именно связь через наблюдаемое значение. Acquire-загрузка, прочитавшая старое значение до публикации, ещё не синхронизируется с будущей release-записью. Поэтому типичный цикл ожидания должен продолжаться до чтения состояния, которое действительно опубликовано производителем.

Ситуация из практики

В lock-free очереди производитель заполняет слот, а затем публикует индекс готового элемента. Рассматривались три варианта. Мьютекс был проще для проверки, но добавлял блокировку и мог ограничить пропускную способность. Полный seq_cst упрощал рассуждение о нескольких атомарных индексах, но навязывал глобальный порядок, не требуемый односторонней публикацией. Расслабленный порядок был дешевле концептуально, но не гарантировал видимость заполненного слота.

Выбран был release при публикации индекса и acquire при его чтении, а для счётчиков, не участвующих в публикации содержимого, — более слабый порядок, если это было доказано безопасным. В результате алгоритм получил необходимую гарантию видимости данных без необоснованного усиления порядка. Ключевым условием осталось отдельное доказательство отсутствия конфликтов при повторном использовании слота.

Что кандидаты часто упускают

Достаточно ли acquire-загрузки, если она прочитала значение, записанное до release-публикации?

Нет. Acquire синхронизируется не с любой операцией над той же атомарной переменной, а с release-операцией, значение которой оно наблюдает напрямую или через предусмотренную моделью памяти цепочку публикации. Если загрузка увидела старое значение, гарантии видимости данных, подготовленных последующей публикацией, ещё нет.

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

Почему acq_rel на одной операции не равен seq_cst для всей программы?

acq_rel объединяет acquire-свойства чтения и release-свойства записи одной атомарной операции. Он может корректно передать владение или состояние через конкретную переменную, но не устанавливает единого глобального порядка этой операции и всех других атомарных операций.

seq_cst добавляет такую глобальную последовательность для всех последовательных атомарных операций. Поэтому замена seq_cst на acq_rel допустима только после проверки алгоритма: нужно доказать, что ему требуется локальная передача happens-before, а не согласованное наблюдение единого порядка нескольких переменных.

Можно ли заменить acquire на relaxed, если атомарный флаг всё равно читается корректно?

Нет, корректное чтение самого флага не гарантирует корректное чтение данных, которые он должен публиковать. relaxed обеспечивает атомарность и согласованность модификаций конкретной атомарной переменной, но не создаёт synchronizes-with и не делает предшествующие обычные записи видимыми в требуемом порядке.

Такая замена иногда случайно работает на конкретной архитектуре или при текущей реализации компилятора, но это не является гарантией C++. Если публикация защищает обычные данные, нужен как минимум release на стороне публикации и acquire на стороне потребления либо другой механизм синхронизации, например мьютекс.