std::atomic比mutex+bool更适合状态通知，因其无锁、单指令、低开销且不阻塞线程，适用于单写多读信号场景；但需正确使用memory_order（如release/acquire配对）并避免与volatile混用。
std::atomic 为什么比 mutex + bool 更适合状态通知
因为 std::atomic<bool></bool> 提供无锁（lock-free）的读写语义，在多数平台上编译为单条 CPU 指令（如 x86 的 XCHG 或 MOV + 内存屏障），开销远低于加锁/解锁一对操作。它不阻塞线程，也不引入调度延迟，特别适合「一个线程改、多个线程读」这类单向信号场景。
但要注意：std::atomic<bool></bool> 不提供等待能力（没有类似 wait() 的接口），所以不能替代 std::condition_variable 做主动唤醒；它只负责「状态已变」这一事实的可靠传播。
如何避免 memory_order 用错导致读不到最新值
默认构造的 std::atomic<bool></bool> 使用 memory_order_seq_cst，安全但略重；若只做状态通知（如「初始化完成」「退出请求」），可显式降级以提升性能，但必须配对使用：
- 写端用
store(true, std::memory_order_release)—— 确保该写入前的所有内存操作不会被重排到它之后 - 读端用
load(std::memory_order_acquire)—— 确保该读取后的所有内存操作不会被重排到它之前 - 若读端是轮询（如
while (!flag.load(std::memory_order_acquire)) {}），需注意 CPU 空转问题，必要时加std::this_thread::yield()或短延时
错误示例：flag.store(true, std::memory_order_relaxed) 后，其他线程可能永远读不到 true，因编译器/CPU 可能缓存旧值或重排指令。
立即学习“C++免费学习笔记（深入）”；
std::atomic 与 volatile bool 的关键区别
volatile bool 只禁用编译器优化（防止寄存器缓存），不提供任何跨线程同步语义，也不生成内存屏障。在多核 CPU 上，一个线程写 volatile bool，另一个线程很可能读到陈旧值——这不是 bug，是标准行为。
而 std::atomic<bool></bool> 同时解决两件事：禁止编译器乱序 + 强制硬件级内存顺序约束。两者完全不可互换。
常见误用：volatile std::atomic<bool></bool> —— 多余且错误，std::atomic 已自带 volatile 语义，再加 volatile 会导致编译失败（C++17 起）。
实际通知模式：用 test_and_set() 实现一次性触发
如果只需要「首次设置即生效，后续设置无效」（比如「启动一次」「报错仅上报一次」），可用 exchange() 或 compare_exchange_strong() 避免竞态：
std::atomic<bool> notified{false};
// 线程 A：尝试触发通知
if (notified.exchange(true, std::memory_order_acq_rel) == false) {
// 这里是唯一执行点：只有第一个调用者进入
trigger_action();
}
// 线程 B：检查是否已被通知（普通 load 即可）
if (notified.load(std::memory_order_acquire)) {
handle_notified();
}
注意：exchange() 是读-改-写原子操作，天然线程安全；但别用 if (!flag) flag = true;，那是非原子的竞态代码。
复杂点在于：一旦设为 true 就不可逆，若需双向/多次状态切换，应考虑 std::atomic<int></int> 或配合 std::condition_variable 使用——std::atomic<bool></bool> 本质只是个二值信号灯，别指望它扛起状态机的活。
