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

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

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

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

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

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

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

Обратная ошибка — использовать volatile-переменную как флаг готовности между потоками. Запись одного потока и чтение другого в таком случае не образуют отношения happens-before; если доступы конфликтуют, возникает гонка данных, а поведение программы становится неопределённым. Даже если отдельная запись физически выполняется одной инструкцией, этого недостаточно для корректной многопоточности.

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

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

Это не означает, что volatile гарантирует атомарность. Операция может состоять из нескольких аппаратных действий, а другой поток или обработчик может наблюдать промежуточное состояние. volatile также не предоставляет memory order, не устанавливает межпоточную видимость и не заменяет аппаратные memory barrier.

Ключевое различие таково:

volatile описывает особые внешне наблюдаемые обращения к памяти;
std::atomic обеспечивает атомарные операции и формализованную межпоточную синхронизацию;
mutex дополнительно защищает составные инварианты и последовательности операций.

Минимальный пример обращения к объекту, для которого чтение и запись должны сохраняться как отдельные действия:

volatile int device_register = 0;

int main() {
    int sample = device_register;
    device_register = 1;
    return sample;
}

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

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

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

Первый вариант — оставить volatile. Его плюс в том, что обращения не будут устранены как бесполезные; это уместно для memory-mapped I/O. Минус — отсутствие атомарности и синхронизации между потоками.

Второй вариант — заменить флаг на std::atomic<bool>. Это корректное решение для взаимодействия потоков: можно выбрать нужный порядок памяти, а при необходимости использовать ожидание и уведомление. Но atomic не заменяет volatile для аппаратного регистра, поскольку его семантика предназначена для C++-потоков, а не для описания внешнего устройства.

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

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

Означает ли volatile, что значение всегда читается непосредственно из физической памяти?

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

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

Нет, одной инструкции недостаточно. Корректность требует не только неделимости операции, но и межпоточной видимости и порядка действий. Для этого применяют std::atomic с подходящим порядком памяти либо mutex; volatile этих свойств не предоставляет.

Нужно ли одновременно объявлять объект volatile и std::atomic?

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