acquire-release必须成对作用于同一原子变量的load-store操作才能建立synchronizes-with关系：release写入前的所有内存操作对后续acquire读到该值的线程可见，但不保证全局立即可见，仅靠禁止重排和依赖传递实现确定性同步。
std::memory_order_acquire 和 std::memory_order_release 怎么配对使用？
它们必须成对出现在同一原子变量的读-写操作上，才能建立线程间的同步关系。单个 acquire 或 release 没有意义；只有当一个线程用 store(std::memory_order_release) 写入，另一个线程用 load(std::memory_order_acquire) 读取同一个原子变量时，才构成“synchronizes-with”关系。
常见错误是误以为任意两个线程中分别执行 acquire 和 release 就能同步——实际必须指向同一个原子对象，且顺序不能颠倒（不能用 acquire 去读一个从未被 release 写过的值）。
- 释放操作（
store+memory_order_release）会阻止其前面的所有内存访问被重排到它之后 - 获取操作（
load+memory_order_acquire）会阻止其后面的所有内存访问被重排到它之前 - 编译器和 CPU 都遵守该约束，但不保证其他线程立即看到该原子变量的新值（仍依赖 cache coherency 协议，如 MESI）
为什么 acquire-release 不保证全局可见性，却能实现同步？
可见性 ≠ 同步。acquire-release 不强制刷新整个 cache line，也不触发跨核广播（像 memory_order_seq_cst 那样），但它通过“禁止重排 + 依赖传递”让某些写操作在逻辑上对另一线程“可观察”。关键在于：一旦 acquire 成功读到 release 写入的值，那么 release 之前所有对非原子变量的修改，对该 acquire 后的代码来说就是可见的。
这依赖于处理器的 memory model（如 x86 的 TSO）和编译器的 barrier 行为。x86 上 acquire/release 几乎不生成额外指令（仅插入编译器 barrier），而 ARM/AArch64 则需 ldar/stlr 等带语义的指令。
立即学习“C++免费学习笔记（深入）”；
- 不是所有写都会立刻被其他核看到，但 acquire-release 保证“你读到了我的信号，就一定能看到我发信号前准备好的数据”
- 没有 store-load 重排 → release 前的写不会跑到 store 后面；没有 load-load 重排 → acquire 后的读不会跑到 load 前面
- 若中间有 relaxed 操作穿插，无法形成传递链，同步即断裂
典型错误：把 acquire-release 用在不同变量上
下面这段代码无法保证 data 的可见性：
std::atomic<bool> flag{false};
std::atomic<int> data{0};
<p>// Thread A
data.store(42, std::memory_order_relaxed);
flag.store(true, std::memory_order_release); // ❌ 错：data 是 relaxed，与 flag 无同步链</p><p>// Thread B
while (!flag.load(std::memory_order_acquire)) { /<em> spin </em>/ } // ✅ 读 flag
std::cout << data.load(std::memory_order_relaxed); // ❌ 输出可能是 0正确做法是让 data 的写也参与同步链，或确保它在 flag.store 之前完成且不被重排：
// Thread A（修正） data.store(42, std::memory_order_relaxed); atomic_thread_fence(std::memory_order_release); // 或直接用 release-store 控制 data flag.store(true, std::memory_order_relaxed); // 但此时 flag 不再是同步点
更推荐统一用同一原子变量承载信号和数据（如 std::atomic<int></int>，用特殊值表示 ready），或改用 memory_order_seq_cst 简化推理（代价是性能）。
acquire-release 在 lock-free 队列中的真实作用
在 Michael-Scott 队列等实现中，head 和 tail 指针常以 acquire/release 访问，目的是防止节点字段（如 next）的读写被错误重排。例如出队时：
auto old_head = head.load(std::memory_order_acquire); // ① auto next = old_head->next.load(std::memory_order_acquire); // ② // 若没 acquire，② 可能被重排到 ① 前，读到脏指针
这里 acquire 不是为了让其他线程立刻看到 head 更新，而是确保本线程在读到新 head 后，一定能安全读取它所指向节点的 next 字段——因为入队端必然用 release 存储该字段。
- acquire-release 的价值不在“快”，而在“确定性”：只要同步成立，行为就可预测
- 调试困难点在于：错误往往只在高负载、特定调度、弱序架构（ARM）下暴露
- 用 TSAN（ThreadSanitizer）可以捕获部分 acquire-release 配对缺失，但无法验证语义完整性
acquire-release 的本质是构造一个单向的 happens-before 边；它不解决 cache 一致性延迟，也不替代正确的数据结构设计。最容易被忽略的是：同步只对“已建立的配对”有效，而配对是否成立，完全取决于程序员对控制流和内存访问顺序的精确建模。
