memory_order_acquire和memory_order_release必须成对作用于同一原子变量的不同线程，仅当acquire读到release写入的值时才建立synchronizes-with关系，从而保证release前的写对acquire后的读可见；单独使用或跨变量、错序、非release写入的值均无效。
memory_order_acquire 和 memory_order_release 必须成对出现在不同线程的同一原子变量上
单独用 memory_order_acquire 或 memory_order_release 没有意义——它们不保证单线程内的顺序，只在跨线程同步时通过“synchronizes-with”关系起作用。关键在于：一个线程对某原子变量执行 store（带 memory_order_release），另一个线程对该**同一变量**执行 load（带 memory_order_acquire），才能建立同步关系。
常见错误是混用变量或方向反了：比如线程 A 对 flag 用 acquire load，线程 B 对 data 用 release store——这无法同步；或者线程 A 对 flag release store，线程 B 却对 flag 用 relaxed load——也断开同步链。
- 必须操作同一个
std::atomic<T>对象 -
release只能用于store、exchange、fetch_add等写操作（且不能是load） -
acquire只能用于load、exchange、fetch_add等读操作（且不能是store） - 典型配对模式：
flag.store(true, std::memory_order_release)+flag.load(std::memory_order_acquire)
为什么不能用 memory_order_acquire 去 load 一个从未被 release 写过的值
如果某个原子变量从未被任何线程以 memory_order_release（或更强）写入过，那么对其做 memory_order_acquire load 不会触发任何同步效果，编译器和 CPU 仍可能重排它前后的内存访问——因为没有 “synchronizes-with” 的源头。
这常发生在初始化阶段：比如全局 std::atomic<bool> ready{false}</bool>，线程 A 直接 ready.load(std::memory_order_acquire)，而线程 B 后来才 ready.store(true, std::memory_order_release)。第一次 load 时，ready 是初始值 false，这个值不是由任何 release store 产生的，所以该 load 不构成 acquire 操作，也不阻止重排。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- acquire-load 的同步语义只对“由 release-store 写入的值”生效
- 初始值、relaxed-store 写入的值、或 non-atomic 写入的值，都不能触发 acquire 语义
- 若需确保首次检查也安全，可让线程 B 先写再通知，或用
memory_order_seq_cst（但开销大）
exchange 既能 release 又能 acquire，怎么配对
std::atomic::exchange() 支持 memory_order_acq_rel，它同时具备 acquire 和 release 语义——既防止后续操作重排到 exchange 之前（acquire），也防止之前操作重排到 exchange 之后（release）。但它不能“自己跟自己配对”，仍需跨线程协作。
例如线程 A 调用 flag.exchange(true, std::memory_order_acq_rel)，线程 B 调用 flag.load(std::memory_order_acquire)，只要 B 读到了 A 写入的 true，就构成 synchronizes-with；同理，B 用 exchange(false, std::memory_order_acq_rel)，A 用 load(std::memory_order_acquire) 读到该 false，也能同步。
-
acq_rel是双向屏障，但同步仍依赖“谁先写、谁后读”的实际执行顺序 - 不能指望两个
acq_relexchange 自动构成锁；仍需逻辑上区分“发布者”和“消费者”角色 - 若用
exchange实现自旋锁，通常用acq_rel获取锁，用release解锁（store false）更清晰
容易被忽略的坑：编译器不保证 non-atomic 访问的可见性，即使有 acquire/release
memory_order_acquire 和 memory_order_release 只约束原子操作与 nearby non-atomic 访问之间的重排，并不保证 non-atomic 写本身会被其他线程看到。如果线程 A 写了 non-atomic 变量 data，再 flag.store(true, std::memory_order_release)；线程 B flag.load(std::memory_order_acquire) 成功后，仍可能读到未更新的 data——除非 data 的访问也受正确同步保护（如加锁、或用 atomic<T>）。
根本原因：acquire/release 不是“缓存刷新指令”，也不触发 cache coherency protocol 的显式传播；它只是告诉编译器和 CPU：“别把这条指令前后的访存乱序”，但不解决 store buffer 延迟、store forwarding 失败等硬件级问题。
- acquire/load 后读 non-atomic 变量，只能保证“不会读到该变量在 acquire 之前的旧值”，但无法保证读到“release 之后写入的最新值”——除非写端也用了对应同步
- 典型修复方式：把
data也声明为std::atomic，或用 mutex 包裹整个临界区 - 在弱一致性架构（如 ARM/POWER）上，漏掉 barrier 或用错 order 会导致极难复现的 bug
