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

Нет. Сам по себе notify_one только побуждает ожидающий поток снова проверить значение атомарной переменной; он не является операцией публикации данных и не создаёт необходимое отношение happens-before. Чтобы обычные данные стали видимыми, запись должна быть упорядочена перед уведомляющей операцией, а другой поток должен выполнить согласованное acquire-чтение изменённого значения.

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

Механизмы ожидания появились, чтобы поток не тратил процессорное время на постоянный опрос состояния. Условные переменные отделяют изменение предиката от пробуждения, а атомарные ожидания объединяют проверку атомика с эффективным блокированием.

При этом уведомление по смыслу является сигналом о необходимости повторной проверки, а не универсальным барьером памяти. Такое разделение позволяет реализациям эффективно будить потоки, не приписывая каждому уведомлению дополнительные гарантии синхронизации.

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

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

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

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

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

Нужна цепочка из трёх частей: запись обычных данных должна быть sequenced-before release-операции над атомиком; acquire-загрузка в другом потоке должна увидеть значение, записанное этой release-операцией или её release-последовательностью; после этого acquire создаёт synchronizes-with, а значит, и happens-before для опубликованных данных.

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

Минимальная схема выглядит так:

#include <atomic>
#include <thread>

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

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

void consumer() {
    ready.wait(false, std::memory_order_acquire);
    int result = value;
}

Здесь release публикует запись в value, а успешное acquire-наблюдение значения true делает её видимой потребителю. wait может внутренне просыпаться несколько раз, но возвращается для дальнейшей работы только после обнаружения отличающегося значения; уведомление не отменяет необходимость проверять состояние.

Если заменить release на relaxed, а acquire-операцию оставить relaxed или не обеспечить другим способом, видимость value не гарантируется. Альтернативой могут быть мьютекс, канал с собственной гарантией синхронизации или другой корректный протокол публикации.

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

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

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

Выбранный вариант — запись структуры перед release-store, ожидание через acquire и отдельное уведомление. Он сохраняет неблокирующую публикацию данных, а notify_one уменьшает задержку и не расходует CPU на активное ожидание. Важно, чтобы после публикации объект не изменялся конкурентно без отдельной синхронизации.

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

1. Создаёт ли notify_all более сильную гарантию, чем notify_one?

Нет. Разница в количестве потенциально разбуженных ожидающих потоков, а не в модели памяти. Ни notify_one, ни notify_all сами по себе не публикуют обычные данные; порядок памяти задаётся операциями над атомиком или другим механизмом синхронизации.

2. Можно ли вызвать уведомление до изменения атомарного значения?

Можно, но такое уведомление не обязано привести к полезному пробуждению: ожидающий поток проверит старое значение и продолжит ожидание. Корректный протокол сначала изменяет состояние, затем уведомляет; при этом ожидающий поток обязан ориентироваться на значение предиката, а не на сам факт уведомления.

3. Достаточно ли acquire-загрузки, если она прочитала значение, установленное другим relaxed-store?

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