C++多线程跨CPU安全读写布尔值的潜在问题与解决方案咨询

问题1：多线程同时轮询和修改普通_connected变量的潜在问题 #

• 触发C++标准定义的未定义行为：只要多个线程同时访问同一变量，存在至少一个写操作且无同步机制，即构成数据竞争，属于明确的未定义行为。编译器可能做出完全不符合预期的优化，比如直接省略_connected的写入操作、将轮询场景下的读操作提升到循环外部，导致状态永远不更新。
• 可见性失效：现代CPU每个核心都有独立缓存，写线程修改的_connected值可能暂存在当前核心的私有缓存中，未及时同步到主存和其他核心的缓存，导致读线程永远读取到过期的旧值。
• 内存重排导致逻辑错误：编译器和CPU都会为了性能重排指令顺序，比如连接建立流程中，可能先执行了_connected = true的赋值，再完成连接相关的初始化操作，此时其他线程读到true时连接实际并未就绪；两个写线程的操作顺序也可能在不同核心的视角下不一致，导致最终状态和实际连接情况完全不符。

问题2：规避方案对比及最优选择 #

首先明确：volatile bool完全不能解决多线程同步问题，它仅能禁止编译器优化该变量的读写，既不保证CPU缓存可见性，也不禁止指令重排，仅适用于内存映射IO等单线程访问硬件寄存器的场景，不要在多线程同步中使用。

可选方案的对比和推荐如下：

最优方案：使用std::atomic<bool>（C++11及以上支持） #

这是最推荐的方案，兼顾可移植性、性能和易用性：

• 改造成本极低：仅需将类定义中的bool _connected修改为std::atomic<bool> _connected = false;，原有赋值、读取逻辑无需任何修改，std::atomic已经重载了对应的运算符，原有代码可以直接编译运行。
• 性能开销极低：对于单个布尔变量的同步场景，原子操作的开销几乎和普通变量读写一致，远低于锁的开销。默认的顺序一致性内存序可以完全保证所有线程看到的操作顺序一致，如果你对性能有极致要求，还可以手动指定写操作用std::memory_order_release、读操作用std::memory_order_acquire，在保证逻辑正确的前提下进一步降低开销。
• 完全符合C++标准，跨平台可用，无需依赖任何平台相关的特性，不会出现内存屏障漏加、错加的问题。

备选方案1：加互斥锁 #

可以在类中增加std::mutex成员，所有读写_connected的接口都加锁保护，逻辑上完全线程安全。但对于仅同步单个布尔变量的场景，锁的上下文切换、争抢开销远高于原子操作，属于性能浪费，仅适合后续需要扩展同步多个关联变量的场景。

备选方案2：手动加内存屏障 #

不推荐使用。不同CPU架构的内存屏障指令（比如x86的mfence、ARM的dmb）完全不同，可移植性极差，且手动控制内存序很容易出现漏加屏障、内存序选择错误的问题，std::atomic已经在底层封装了对应平台的屏障逻辑，完全没必要自己手动实现。

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