C++主线程与工作线程非并发读写变量是否需要同步

只要存在跨线程的共享变量访问，就不能靠上层业务逻辑的"时间不重叠"来省略同步，必须通过C++标准认可的同步机制建立明确的happens-before关系，否则就是未定义行为。 你的场景是否需要额外加同步，完全取决于你启动、等待工作线程的方式是否自带标准规定的同步语义。

两种场景的具体判定 #

1. 用标准同步语义的线程启动/等待方式：无需额外同步 #

如果你是直接用std::thread构造启动工作线程，并且最终对每个工作线程调用join()等待其执行完毕，这种场景不需要给共享变量额外加锁或设为原子类型：

• C++标准明确规定：std::thread构造函数的完成，同步于工作线程函数的开始执行；工作线程的所有执行操作，同步于对应join()调用的返回。
• 这两个节点自带全量内存屏障，会自动保证：主线程在启动线程前对共享变量的修改对工作线程可见，工作线程对共享变量的修改在join()返回后对主线程可见，且不会出现指令重排导致的顺序错乱，不存在数据竞争。

2. 自定义线程通知/等待逻辑：必须加同步 #

这是绝大多数人踩坑的场景：比如用提前初始化的线程池，通过普通全局变量做任务标记唤醒工作线程，再通过普通布尔标记轮询等待工作线程完成，这种场景哪怕你100%确定主线程和工作线程不会同时读写共享变量，也必须做同步，否则必然是未定义行为。
举个典型的错误实现：

// 错误示例：无任何同步，逻辑上时序正确但实际是未定义行为
int shared_val = 0;
bool task_ready = false;
bool worker_done = false;

void worker() {
    while (!task_ready); // 等任务通知
    shared_val = 42;     // 写共享变量
    worker_done = true;  // 标记完成
}

// 主循环逻辑
void main_loop() {
    // 提前启动工作线程（线程池场景常见）
    std::thread t(worker);
    t.detach();

    while (true) {
        shared_val = 0;
        task_ready = true; // 通知工作线程干活
        while (!worker_done); // 等工作线程结束
        // 逻辑上这里应该读到42，实际可能读到0、直接死循环甚至随机崩溃
        std::cout << shared_val << std::endl;
        // 重置标记进入下一轮
        task_ready = false;
        worker_done = false;
    }
}

这段代码的问题和你业务逻辑的时序保证没有任何关系，问题出在编译器和CPU根本感知不到跨线程的依赖关系：

• 编译器优化：编译器会按照单线程逻辑分析代码，可能把轮询的task_ready、worker_done缓存到寄存器，永远看不到另一个线程对它的修改，直接死循环；也可能发现主循环里轮询期间没有代码修改shared_val，直接把输出优化成固定打印0，根本不去内存读工作线程写入的值。
• 指令重排：无论是编译器重排还是CPU（尤其是ARM、RISC-V这类弱内存序架构）的硬件重排，都可能把"写共享变量"和"写完成标记"的顺序调换，导致主线程看到完成标记为true时，共享变量的写入还没生效，读到旧值。

这种场景下你有两种可选的同步方案：

• 稳妥无错方案：用std::mutex把所有对共享变量、任务标记、完成标记的访问全部包起来，不需要手动管理内存序，适配所有场景。
• 轻量方案：把跨线程访问的标记变量、共享变量声明为std::atomic类型，通知线程用memory_order_release内存序写标记，等待线程用memory_order_acquire内存序读标记，靠acquire-release语义建立happens-before链。

常见避坑提醒 #

• 不要用volatile做线程同步：它只能禁止编译器把对应变量的访问优化掉，不提供任何内存屏障保证，挡不住CPU的硬件重排，在弱内存序架构下完全不生效。
• 不要拿x86架构的测试结果当正确结论：x86是强内存模型，硬件自动屏蔽了大部分重排行为，很多错误代码在x86上能跑通，但换到ARM平台（苹果M系列、Windows on ARM、移动端ARM设备）、开O2/O3高优化等级时，会出现概率极低、极难调试的bug。
• 未定义行为没有"表现正常"的说法：只要违反C++内存模型的规则，不管你跑起来看起来多么正常，本质上都是不可靠的，随时可能因为编译器版本更新、代码改动、运行环境变化出问题。

内容的提问来源于stack exchange，提问作者Dess