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

volatile не обеспечивает ни атомарность, ни межпоточную синхронизацию, ни отношение happens-before. Если один поток записывает флаг, а другой одновременно читает его, доступы к обычному volatile-объекту образуют гонку данных и приводят к неопределённому поведению. Для флага остановки нужен как минимум std::atomic, обычно с подходящим порядком памяти.

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

Ключевое слово volatile предназначено для объектов, значение которых может изменяться вне обычного потока выполнения программы: например, для регистров устройств или других внешне наблюдаемых областей памяти. Оно сообщает компилятору, что обращения к объекту имеют наблюдаемый побочный эффект и не должны произвольно удаляться или объединяться.

Многопоточность решает другую задачу: согласование действий между потоками и предотвращение конфликтующих обращений. Поэтому добавление volatile к переменной не превращает её в средство синхронизации.

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

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

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

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

Для межпоточного флага следует использовать std::atomic<bool>. Атомарность не позволяет наблюдать частично выполненную операцию над самим флагом, а выбранный порядок памяти определяет, какие другие действия могут быть упорядочены относительно чтения или записи флага.

#include <atomic>

std::atomic<bool> stop{false};

void worker() {
    while (!stop.load(std::memory_order_acquire)) {
        do_work();
    }
}

void request_stop() {
    stop.store(true, std::memory_order_release);
}

Если флаг используется только как независимый сигнал остановки и через него не публикуются другие данные, часто достаточно memory_order_relaxed: требуется атомарное чтение и запись, но не передача видимости других объектов. В примере выбран acquire/release как более строгий вариант, который также может упорядочить действия до записи флага перед действиями после его чтения.

Однако атомик сам по себе не гарантирует, что рабочий поток немедленно проснётся или завершится: поток может долго находиться внутри операции, блокироваться на другом объекте или проверять флаг редко. Для ожидания изменения флага можно рассмотреть std::atomic::wait/notify, условную переменную или другой механизм уведомления.

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

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

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

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

Если поток должен немедленно реагировать на остановку, одного атомарного флага недостаточно: нужно также разбудить его из ожидания. Поэтому в блокирующемся коде применяют условную переменную или atomic wait/notify. Итоговое решение зависит от того, требуется ли только безопасная проверка состояния или ещё и эффективное уведомление.

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

Достаточно ли заменить volatile на std::atomic с memory_order_relaxed во всех случаях?

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

Запрещает ли volatile компилятору переставлять любые операции вокруг volatile-доступа?

Нет. Volatile требует сохранить сами наблюдаемые обращения к volatile-объекту, но не задаёт межпоточную модель памяти для других объектов. Он не создаёт happens-before, не заменяет memory fence и не является полноценным барьером компилятора или процессора для обычных данных.

Может ли volatile быть корректным для флага, если чтение и запись его типа аппаратно выполняются одной инструкцией?

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