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

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

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

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

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

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

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

Однако после join ситуация меняется: присоединяющий поток продолжает работу только после завершения присоединяемого. Если чтение происходит после возврата из join, одновременного доступа уже нет, а между записью и чтением устанавливается необходимое отношение happens-before.

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

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

#include <iostream>
#include <thread>

struct Result { int value = 0; };

int main() {
    Result result;
    std::thread worker([&] { result.value = 42; });
    worker.join();
    std::cout << result.value << '
';
}

В примере result.value не является атомарным, но чтение безопасно: запись выполняется в рабочем потоке до его завершения, а чтение — после возврата из join. Между ними нет конкурентного доступа.

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

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

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

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

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

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

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

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

Достаточно ли вызвать join после того, как другой поток уже завершился сам?

Да. Важно не то, блокировал ли join вызывающий поток, а то, что он успешно дождался завершения и вернулся. Даже если рабочий поток закончил работу до вызова join, правило синхронизации сохраняется.

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

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

Нужно ли делать результат атомарным, если один поток записал его, затем завершился, а другой прочитал после join?

Нет, для этого сценария атомарность результата не нужна. Синхронизация через завершение и join уже создаёт отношение happens-before. Атомарность потребуется, если значение читается или изменяется конкурентно до завершения потока либо если результат передаётся без ожидания join.