为何要对std::atomic<bool>执行load与exchange组合操作？

这个问题问得特别好——我当初第一次啃P2300里这段代码的时候，也纠结过为啥不直接用exchange就完事。咱们掰开揉碎了说：

先快速理清楚场景：有两个线程，线程A调用一个C API并注册回调，之后要初始化stopCallback这个optional；线程B是C API的回调执行线程，回调触发意味着API操作完成。我们用std::atomic<bool> ready来标记“stopCallback是否已经准备好”，核心是要让线程B能判断自己是不是该执行后续的完成逻辑，同时线程A要避免重复初始化。

首先得承认：你提到的只调用exchange的方案，逻辑上是完全正确的。if (ready.exchange(true, std::memory_order_acq_rel))这个写法，不管哪个线程先调用exchange，第一个调用的线程会得到false（不会进入if块），第二个线程调用会得到true（进入if块），完全能满足需求。

那为啥要多此一举加个前置的load？核心原因是减少昂贵的原子写操作的次数。

你得知道，原子操作的开销不是平级的：load（单纯的读操作）的开销通常比exchange（读-改-写的RMW操作）小很多——尤其是在多核心CPU上，RMW操作需要触发总线锁定或者缓存一致性协议的复杂交互，开销比单纯的读要高不少，甚至可能差一个数量级。

回到这个场景的典型执行路径：

• 线程A的常规流程：先load(std::memory_order_acquire)得到false，然后调用exchange把ready设为true，得到返回值false，不进入if块。这里线程A做了一次原子读+一次RMW。
• 线程B的常规流程：先load(std::memory_order_acquire)得到true，直接进入if块，完全不需要调用exchange。这里线程B只做了一次轻量的原子读，省掉了一次昂贵的RMW操作。

而如果只用exchange的话，不管是线程A还是线程B，都要执行一次RMW操作——哪怕线程B只是想确认ready已经是true，也得强行把它再写一遍true（虽然逻辑上没变化，但总线层面还是要处理这个写操作）。在高并发或者这个回调触发很频繁的场景下，这种额外的RMW开销会被放大，影响性能。

那正确性上有没有区别？完全没有——两种方案的内存语义是等价的：load(acquire) + exchange(acq_rel)的组合，和单独的exchange(acq_rel)，在内存可见性上是一致的，都能保证线程A的stopCallback初始化操作对线程B可见。

当然，也存在极端情况：比如线程A刚load到false，还没执行exchange，线程B就进来load到false，然后也执行exchange。这种情况下线程B还是做了一次RMW，但这是小概率事件，大部分常规路径下还是能省掉一次RMW的，整体收益远大于极端情况的开销。

总结一下：

• 只调用exchange是功能正确的，但开销更大；
• load+exchange的组合，在典型路径下能把线程B的原子操作从RMW降级为普通读，大幅降低原子操作的开销，同时完全不影响逻辑正确性。

内容来源于stack exchange