关于释放-获取同步传递性的技术疑问及求证

先看GCC Wiki「Overall Summary」中的示例代码：

-Thread 1-       -Thread 2-                   -Thread 3-
 y.store (20);    if (x.load() == 10) {        if (y.load() == 10)
 x.store (10);      assert (y.load() == 20)      assert (x.load() == 10)
                    y.store (10)
                  }

原文说明：

release-acquire模式仅要求参与的两个线程完成同步，这意味着同步的值对其他线程不具备交换性。线程2中的断言必然成立，因为线程1和线程2通过x.load()完成同步；线程3未参与该同步，因此当线程2和3通过y.load()同步时，线程3的断言可能失败，因为线程1和3之间无同步关系，无法假设x的取值。

你的推理逻辑问题点 #

你的推理存在关键误区：同步关系不具备传递性。第4步假设“线程2观察到x10，与线程2同步的线程3也能观察到x10”是错误的——release-acquire只建立两个线程间的直接同步，不会自动把这个同步关系传递给第三方线程。

具体拆解：

1. 线程1的x.store(10)（release）和线程2的x.load() ==10（acquire）建立了线程1 → 线程2的happens-before关系，所以线程2能看到线程1对y的写入。
2. 线程2的y.store(10)（release）和线程3的y.load() ==10（acquire）建立了线程2 → 线程3的happens-before关系，但这个关系只覆盖线程2自身的操作，不会自动将线程1的操作同步给线程3。
3. 线程1和线程3之间没有直接或间接的同步链，所以线程3看到y=10时，完全可能看不到线程1写入的x=10（比如CPU缓存未同步、指令重排导致的可见性问题）。

疑问解答 #

1. Release-Acquire仅支持双方同步的依据，以及你的理解误区

Release-Acquire的核心规则是：一个release操作和后续对同一变量的acquire操作，仅在这两个操作的执行线程之间建立happens-before关系。这是C++标准及多数内存模型明确规定的——同步关系是成对的、线程间的直接绑定，并非全局广播。

你的错误在于假设“release操作的写入会被所有观察到它的线程通过传递性同步看到”，实际情况是：

• 线程2看到x=10，是因为它和线程1有直接的release-acquire同步；
• 线程3和线程1无任何同步关系，哪怕它通过线程2的y操作同步，也只能看到线程2的操作，无法继承线程2和线程1之间的同步效果。

2. 原文中「commutative」是否应为「transitive」？

是的，这里明显是用词错误。原文想表达的是“同步关系不具备传递性”，而非“交换性”。Commutative指操作顺序不影响结果（如a+b=b+a），但此处核心问题是同步关系不能从线程1→线程2→线程3传递为线程1→线程3，所以应该用transitive（传递性）才准确。

3. 哪些同步操作能保证线程3的断言不会失败？

要让线程3的断言成立，需要建立线程1 → 线程3的happens-before关系，或让同步关系具备传递性，常见方案有两种：

• 使用Seq-Cst（顺序一致）内存模型：把所有原子操作的内存模型改为memory_order_seq_cst。Seq-Cst会保证所有线程看到的操作顺序全局一致，相当于给所有原子操作加上全局同步屏障，这样线程3看到y=10时，必然能看到线程1写入的x=10。
• 显式构建传递同步链：比如线程2在写入y前对x执行acquire操作，或是用内存栅栏（fence）衔接同步关系，但最可靠且简单的方式还是直接使用Seq-Cst，除非有明确的性能优化需求。

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