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

Уведомление не теряется, потому что std::atomic::wait ожидает не событие уведомления, а изменения значения атомика. Перед блокировкой он проверяет текущее значение: если ready уже не равно false, поток сразу продолжает выполнение.

wait(false) возвращается только после наблюдения значения, отличного от false; само notify_one не является условием завершения ожидания. В данном примере поток увидит true, поэтому блокировка не произойдёт.

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

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

std::atomic::wait объединил проверку значения атомика с эффективным блокированием потока. Это решает типичную проблему потерянного уведомления: состояние хранится в самом атомике, поэтому уведомление не обязано застать поток уже заблокированным.

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

Уведомление у примитивов ожидания не должно рассматриваться как самостоятельное событие, которое гарантированно будет сохранено до прихода потребителя. Если использовать условную переменную без защищённого предиката, уведомление, пришедшее раньше ожидания, действительно может быть потеряно.

У атомарного ожидания предикатом является значение атомика. Если производитель сначала изменил значение, а затем вызвал notify_one, поздно прибывший потребитель всё равно прочитает новое значение и не станет ждать. Неверный вывод о том, что notify_one само по себе «запоминается», приводит к ошибочному проектированию протокола.

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

Вызов ready.wait(false) концептуально работает так:

атомарно загружает значение ready;
если значение не равно false, возвращает управление;
если значение равно false, может заблокировать поток;
после пробуждения снова проверяет значение.

Поэтому notify_one лишь просит ожидающие потоки повторно проверить атомик. Оно не превращает false в true и не является заменой записи. В примере изменение выполняется операцией store(true, std::memory_order_release), а wait использует порядок seq_cst по умолчанию, который достаточно силён для чтения этой публикации.

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

#include <atomic>
#include <thread>

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

void consumer() {
    ready.wait(false);
    int value = payload; // безопасно после наблюдения release-записи
}

int main() {
    payload = 42;
    ready.store(true, std::memory_order_release);
    ready.notify_one();
    std::thread t(consumer);
    t.join();
}

Важное ограничение: wait сравнивает значения, а не отслеживает каждое изменение. Если атомик успел пройти последовательность A → B → A, ожидающий поток может увидеть снова A и продолжить ожидание. Это разновидность проблемы ABA, поэтому для некоторых протоколов одного значения атомика недостаточно.

Порядок памяти relaxed также не гарантирует публикацию связанных обычных данных. Он может быть достаточен для самого протокола ожидания, если синхронизация данных обеспечивается другим способом, но для схемы «записать данные, затем поднять флаг» обычно нужен release на записи и соответствующее чтение с acquire.

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

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

std::atomic::wait/notify_one позволяет хранить счётчик непосредственно в атомике. Производитель увеличивает счётчик и вызывает notify_one, а потребитель вызывает wait(0) и после пробуждения повторно пытается забрать задачу.

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

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

Вопрос: Гарантирует ли notify_one передачу управления конкретному ожидающему потоку?

Ответ: Нет. notify_one не гарантирует выбор конкретного потока и не является механизмом передачи владения ресурсом. Оно только инициирует повторную проверку значения у одного из ожидающих потоков. Если несколько потоков конкурируют за ресурс, каждый должен самостоятельно проверить состояние и корректно обработать ситуацию, когда ресурс уже забрал другой поток.
Вопрос: Можно ли заменить store(true, memory_order_release) на store(true, memory_order_relaxed), если wait всё равно увидит true?

Ответ: Для обнаружения изменения значения это может быть достаточно, но публикация обычных данных при этом не гарантируется. Если до записи флага были изменены неатомарные поля, потребителю нужен release-acquire или другой механизм happens-before. relaxed сохраняет атомарность и порядок модификаций самого атомика, но не создаёт синхронизацию с обычными объектами.
Вопрос: Может ли wait вернуться из-за ложного пробуждения, не увидев изменения значения?

Ответ: Реализация может внутренне разбудить поток без изменения значения, например из-за особенностей используемого системного примитива. Однако интерфейс atomic::wait повторяет проверку и не должен возвращать управление, пока наблюдаемое представление значения не отличается от переданного аргумента. Это не отменяет ABA-ограничение: значение могло измениться и вернуться обратно, а промежуточное изменение останется незамеченным.