你跑偏了，文档的if语句不是用于表明“条件约束”，是表明“时刻”。

所以，应读为：
当thread2看到thread1给x的最新值后，对y采取行动。
当thread3看到thread2给y的最新值*之时刻*，thread3 未必看到thread1的对x的所做所为。此即，不同步。

好比上游项目组1发了新版本，项目组2采用后也发了新版本。你看到项目组2的新版本，也pull一把，一编译，砰！挂了。因为没跟新项目1的代码。

relax只保证你获取了项目2的“最新版本”之时刻后，你们项目组任何人再问他们要最新代码，他不会告诉你一个旧的版本号。
【 在 libgcc 的大作中提到: 】
: 但是thread2的y.store在x.load条件约束之内，这难道也能乱序？
--
FROM 117.39.204.*

还没用过这么精确/巧的控制，日常业务性偏多。
看这个版面，纯粹读读文档，没有实操。

你以上这些讨论，都是以CPU0,1,2为例，即硬件多线程。
这些讨论，对软线程适用吗？
【 在 ziqin 的大作中提到: 】
: 在我这个行当里 主要是近2-3年 lock free的数据结构开始普遍使用 所以今年年初花了点时间把相关的来龙去脉理了一下 发现lock free的核心在于设一个状态flag， 这个flag必须在写完以后或者读取以前原子设置。除了原子以外，这个先后顺序在编译器优化模式下，在以前是没有办法在语言层面控制的
:
--
FROM 1.85.206.*

反着问，2核起3个线程，是否需要指定memory order，使得例子里的assert都为true?
【 在 ilovecpp 的大作中提到: 】
: 1核非超线程起3个线程，也适用。代码里没有限制的话，编译器就会重排，和CPU无关。编译器默认的memory ordering比任何CPU都松。
--
FROM 1.86.17.*

谢谢。那我抓住了重点。

第二段汇编和超线程的知识，我以后有机会再了解。
【 在 ilovecpp 的大作中提到: 】
: 是的。讨论C/C++代码的话，是的。编译器在指令重排上的限制比任何CPU都更少。乱序CPU/多CPU会引发的问题，编译器在单CPU上（至少理论上）也会引发。
: 讨论汇编代码的话，不是。超线程/多核/多CPU上的一些现象在单核上不会出现。
--
FROM 1.86.17.*