水木社区手机版
- 主题:大家来看看这个relaxed memory order
- wiki上说的是两个assert都可能fail
因为x、y这两个变量的load/store操作，在relaxed memory order下，没有任何before、after的保障。
所以store x、store y、load x、load y这些操作，任何cpu(thread)看到的都可能是任意的顺序。
--
修改:z16166 FROM 221.220.175.*
FROM 221.220.175.* - 那只是cpu 2(thread 2)的视图，cpu 3(thread 3)的视图可能是完全不一样的。
store操作可能只是操作了cache，而cache的改变并未同步给别的cpu，所以别的cpu看到的可能是另一个视图。
t2看到t1执行了x=10的side effect，但是t3并未看到这个t1这个操作的side effect，
t3只是看到t2执行了y=10的side effect。
补个时序图，绿色的表示side effect跨cpu生效，红色表示side effect还没跨cpu生效，白色表示在这个具体的例子中不关心。
【 在 libgcc 的大作中提到: 】
: 但是thread2的y.store在x.load条件约束之内，这难道也能乱序？
--
修改:z16166 FROM 221.220.175.*
FROM 221.220.175.* - if的条件语句是一个sequence point，什么编译器会重排这个？
楼主的这个问题用硬件cache举例最好理解。用编译器指令重排来解释，最好是能把对应的具体某个编译器生成的汇编代码列出来
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
: : 不过，就算是relaxed，在thread2里y.store也肯定是在x.load之后吧
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:
: 不是的，y.sotre可能发生在x.load之前
--
FROM 125.35.121.* - 你说得对，编译器优化最终以observable behavior而不是sequence point为依据。
不知道什么编译器会对这个搞天马行空的优化
if(x.load()==10)
{
y.store(10)
}
【 在 ilovecpp 的大作中提到: 】
: sequence point / sequencing限定的是单线程代码理论上（“在C++虚拟机上”）的运行过程，它从来不限制实际生成代码的运行过程。编译器生成的代码只需要和标准在单线程的“可观测行为”（i.e.库函数调用）上一致。极端的例子，编译器理论上可以把你算pi的前100位的程序生成为直接打印答案。
--
FROM 125.35.121.*