- 主题:大家来看看这个relaxed memory order
y.store和assert会乱序
【 在 libgcc 的大作中提到: 】
: 但是thread2的y.store在x.load条件约束之内，这难道也能乱序？
--
FROM 115.193.185.*
而且，对的，y.store和x.load也会乱序
【 在 libgcc 的大作中提到: 】
: 但是thread2的y.store在x.load条件约束之内，这难道也能乱序？
--
FROM 115.193.185.*
: 不过，就算是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.*
在我这个行当里 主要是近2-3年 lock free的数据结构开始普遍使用 所以今年年初花了点时间把相关的来龙去脉理了一下 发现lock free的核心在于设一个状态flag， 这个flag必须在写完以后或者读取以前原子设置。除了原子以外，这个先后顺序在编译器优化模式下，在以前是没有办法在语言层面控制的
【 在 DoorWay 的大作中提到: 】
: 赞博学。
: 这个大规模使用是从啥时候，大概。是你或者身边的样本，还是看网上讨论多了？
--
FROM 112.65.30.*
从我读的资料和我的理解来看，memory fence本身就是对cpu cache同步的约定，所以应该是对硬多线程来说的。
【 在 DoorWay 的大作中提到: 】
: 还没用过这么精确/巧的控制，日常业务性偏多。
: 看这个版面，纯粹读读文档，没有实操。
: 你以上这些讨论，都是以CPU0,1,2为例，即硬件多线程。
: ...................
--
FROM 115.193.170.*
可能和inline的处理类似
【 在 libgcc 的大作中提到: 】
: 如果
: if x.load()
: {
: ...................
--
FROM 115.193.170.*