关键是你有没有另外一个地方在顺序读取这这三个变量中的两个。

如果有的话，就用 store_release store_relax 来调整。

这种一般都是 lock-free 编程用到。简单点，上锁就没这些事了。

【 在 freyoneby (freyoneby) 的大作中提到: 】
: 比如一段代码
:    head++;
:    rear++;
: ...................
--
FROM 110.85.22.*

一种乱序是编译器调度指令会乱序，这种在C语言里的volatile关键字应该可以防止这种情况。另一种乱序是处理器执行指令会乱序，只要保证语义正确，执行顺序有可能和指令序列不一样。
在多核的场景下，我们重点关注的是cache coherence和memory consistency的问题。
cache coherence是说每个核都有自己的cache，那么当一个核向主存中某个地址写数据的时候，另一个核的cache里面存放的是旧值，cache coherence关心的是怎样才能让每个核读到这个这个地址都是读出最新的值。
memory consistency说的是单个核在保证正确性的时候，可能乱序执行load/store操作，这样对于在其他核执行的程序的视角看，就不能假定这个核是按照程序指令的序列来执行这些load/store操作的，否则就可能出错逻辑上的问题。所以处理器要规定一个memory consistency model，让程序员知道处理器执行load/store的规则，从而写多核代码的时候不会出问题。
对于你的代码，主要是考虑memory consistency的问题，在x86的TSO模型里面，load->load,store->store,load->store是保序的，所以所有核看到的store都是按照指令的序列做的，但是对于其他的体系结构就不一定是这样的，这时就需要插入某些内存屏障指令保序。

【 在 freyoneby (freyoneby) 的大作中提到: 】
: 比如一段代码
:    head++;
:    rear++;
: ...................
--
修改:ArchLinux FROM 103.90.178.*
FROM 103.90.178.*

因为在当前上下文环境下编译器判断了没有相互影响的副作用

多线程必然会有这种问题，单线程环境或非直接操作硬件寄存器 不用纠结是不是乱序，编译器必然保证了没有副作用的情况下才会乱序，CPU乱序执行也一样 必然是上下文中没有依赖关系的语句才会被乱序执行或者保留乱序执行的结果，跨线程共享变量或者直接操作硬件寄存器的时候在有先后顺序的语句之间加好锁或屏障就行了

【 在 freyoneby 的大作中提到: 】
: 这也是我疑惑的地方，已经不能相信编译器
--
FROM 111.198.57.*

拜
【 在 ArchLinux 的大作中提到: 】
: 一种乱序是编译器调度指令会乱序，这种在C语言里的volatile关键字应该可以防止这种情况。另一种乱序是处理器执行指令会乱序，只要保证语义正确，执行顺序有可能和指令序列不一样。  
: 在多核的场景下，我们重点关注的是cache coherence和memory consistency的问题。  

: ..................

发自「今日水木 on 电饭煲控制器」
--
FROM 124.78.220.*

内存屏障多数情况下是针对多线程的情况吧


【 在 freyoneby (freyoneby) 的大作中提到: 】
: 比如一段代码
:    head++;
:    rear++;
: ...................
--
FROM 98.165.80.171