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

Это безопасно благодаря отношению happens-before, которое устанавливается между завершением создания std::thread и началом выполнения функции нового потока. Поэтому записи, выполненные до создания потока, становятся видимыми ему без атомиков и мьютекса, если после запуска нет конкурентных записей в те же данные.

#include <thread>
#include <iostream>

int value = 0;

int main() {
    value = 42; // запись до создания потока
    std::thread t([] { std::cout << value << '\
'; });
    t.join();
}

Здесь чтение value не образует гонку: запись завершена до запуска функции потока.

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

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

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

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

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

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

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

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

Вызов конструктора std::thread устанавливает синхронизацию так, что завершение создания потока происходит до начала выполнения переданной функции. Все действия, которые были выполнены в создающем потоке до этой точки, тем самым становятся предшествующими действиям нового потока по отношению happens-before.

Следовательно, обычные данные можно безопасно читать в новом потоке, если соблюдены три условия:

запись завершилась до создания потока;
после запуска нет несинхронизированных изменений тех же данных;
объект не уничтожается до завершения чтения.

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

Важно отличать передачу аргументов в конструктор std::thread от захвата ссылки на локальную переменную. Значение, переданное копированием, получает собственную копию, а ссылка требует гарантировать время жизни исходного объекта.

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

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

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

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

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

1. Достаточно ли создать поток после записи, если родитель потом изменит данные?

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

2. Безопасно ли передать новому потоку ссылку на локальную переменную родительской функции?

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

3. Устанавливает ли создание потока порядок между двумя уже запущенными потоками?

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