: 不过，就算是relaxed，在thread2里y.store也肯定是在x.load之后吧
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

不是的，y.sotre可能发生在x.load之前

从c++代码到cpu实际执行结果有两层乱序
1. 从C++代码到汇编码被编译器乱序
2. 相同的汇编码在上传到cpu中执行时，cpu的乱序

但是这两层乱序必须保证一个底线：同一段代码的运行完的运行结果对于同一块cpu来说，是一致的。

在你这个例子里

y.store可以发生在x.load之前，如果x.load = true，那结果和y.store在x.load之后是一样的，如果x.load = false，这段代码后面本身没有使用y，所以运行结果还是还是一样的。也就是说因为这段代码里没有任何使用y的值的地方，在编译器优化以后，这段代码运行完以后，y是否被改变，是一个undefined情况。这就造成了多核情况下其他cpu的问题。

在有memory order之前，C++没有在语言层面限制运行顺序的语法，所以lock free的结构只有在memory order语法出现只有才得以普遍使用

【 在 libgcc 的大作中提到: 】
: 我明白了，之前陷入了一个坑里一直觉得thread2看到什么thread3也会看到什么
: 不过，就算是relaxed，在thread2里y.store也肯定是在x.load之后吧
--
FROM 112.65.30.*