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

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

Само наличие порядков release и acquire недостаточно: acquire может прочитать значение от другой операции или вообще не ту публикацию. В таком случае синхронизация не устанавливается.

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

Модель памяти C++ появилась, чтобы формально описать взаимодействие потоков с учётом оптимизаций компилятора, переупорядочивания операций процессором и кэширования. Одной атомарности переменной недостаточно, когда поток публикует через неё состояние других объектов.

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

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

Один поток подготавливает обычные данные, а затем сообщает другому потоку, что они готовы, используя атомарный флаг. Если второй поток увидит флаг, но не установится связь между операциями потоков, чтение обычных данных может не иметь требуемой гарантии видимости и привести к гонке данных.

Неверно считать, что любой atomic load автоматически «подтягивает» все записи другого потока. Важны и порядок памяти операции, и то, какое значение атомарной переменной фактически прочитано.

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

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

Ключевое условие — acquire должен прочитать значение, записанное release, или значение из её release-последовательности. После этого все действия до release happens-before действий после acquire. Поэтому обычный объект можно безопасно прочитать после acquire, если его запись была выполнена до release и объект больше не изменяется конкурентно.

Минимальный пример публикации:

#include <atomic>
#include <thread>
#include <cassert>

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

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

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

Запись value = 42 находится до release-store, а чтение value — после acquire-load, который видит true. Поэтому между ними есть happens-before, и чтение value не является гонкой с этой записью.

Если заменить acquire на relaxed, атомарность флага сохранится, но межпоточная связь для value не появится. Если acquire прочитает false, синхронизация также не возникнет; обычно это исправляют повторным чтением в цикле или другим протоколом ожидания.

Release/acquire обычно слабее и потенциально дешевле, чем memory_order_seq_cst, поскольку не требует единого глобального порядка всех последовательно согласованных атомарных операций. Однако такой порядок сложнее правильно спроектировать: он синхронизирует только связанные операции и не делает произвольные обращения к памяти автоматически безопасными.

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

Сервис создаёт неизменяемую таблицу конфигурации в одном потоке и после завершения инициализации публикует флаг готовности. Другой поток сначала проверяет флаг, а затем обращается к таблице.

Вариант с relaxed прост и быстр, но не создаёт необходимого happens-before и потому непригоден для публикации обычной памяти. Вариант с mutex корректен и проще для сложного протокола, однако добавляет блокировки и не нужен для одноразовой публикации.

Выбран вариант release-store флага и acquire-load в потребителе. Он обеспечивает публикацию всех данных, подготовленных до флага, без блокировки; таблица после публикации не изменяется, поэтому последующие чтения не конфликтуют с записями. Для многократных обновлений потребовался бы отдельный протокол владения временем жизни и изменения данных.

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

Достаточно ли acquire-load, если он прочитал значение, записанное relaxed-store?

Нет. Acquire задаёт ограничения порядка для текущего потока, но синхронизация с другим потоком возникает только при чтении значения от release-операции или её release-последовательности. Если значение пришло от relaxed-store, отношения synchronizes-with нет, поэтому acquire не публикует предшествующие обычные записи.

Защищает ли release/acquire данные, которые изменяются после release?

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

Эквивалентны ли release/acquire последовательной согласованности?

Нет. Release/acquire обеспечивает связь между конкретными операциями публикации и получения, но не формирует единый глобальный порядок всех операций seq_cst. Поэтому разные потоки могут наблюдать независимые атомарные операции в разных порядках, если между ними нет дополнительной синхронизации. seq_cst проще для рассуждений в некоторых алгоритмах, но может ограничивать производительность и всё равно не исправляет обращения к данным, содержащим гонку.