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

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

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

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

Для согласованного составного состояния требуется дополнительный протокол: общий мьютекс, один атомик с упакованным состоянием или специальный алгоритм версионирования.

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

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

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

Даже самый строгий порядок памяти seq_cst не превращает несколько операций над разными атомиками в одну транзакцию. Он задаёт общий порядок отдельных операций, но не гарантирует согласованный снимок нескольких объектов.

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

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

#include <atomic>

std::atomic<int> limit{0};
std::atomic<bool> enabled{false};

void publish() {
    limit.store(100, std::memory_order_relaxed);
    enabled.store(true, std::memory_order_relaxed);
}

bool can_use() {
    return enabled.load(std::memory_order_relaxed) &&
           limit.load(std::memory_order_relaxed) > 0;
}

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

Основные варианты решения:

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

Если состояние можно представить одной величиной, предпочтителен один атомик. Если важнее простота и состояние сложное, обычно выбирают мьютекс.

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

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

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

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

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

Достаточно ли применить порядок seq_cst к загрузкам двух атомиков, чтобы получить снимок?

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

Может ли acquire-загрузка одного поля сделать согласованным чтение другого поля?

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

Безопасна ли схема с атомарным счётчиком версии и обычными полями состояния?

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