- 主题:经常看到内存屏障，查了很多资料，感觉自己不会编程了
比如一段代码
head++;
rear++;
flag=0;
flag 肯定在前面两条之后执行，有的说是cpu执行会出现乱序，几条指令会被同时放到cpu中执行，这叫人咋编程，没一步都要防止乱序
又有的说乱序是cache引起，让cache失效就可以了
--
FROM 112.64.184.*
这也是我疑惑的地方，已经不能相信编译器
【 在 cwc 的大作中提到: 】
: 编译器优化可能会重拍为
: flag=0
: head++
: ...................
--
FROM 112.64.184.*
我是觉得像cpu之间的cache同步，不应该做业务的去关心，架构设计上应该保证，cpu切换读取相同内存的时候，能够自动让这部分cache先回写，大部分都是各自领域专业的软件开发，还要关心这种东西，说明目前架构设计，编译器设计都不完美
【 在 leving 的大作中提到: 】
: 这个问题可以简化版理解一下：比如x86平台下的2核处理器。对于head++，假如cpu核a执行了head++，那cpu核b此时的head怎么才能看到这个正确值？x86平台使用的是mesi做cpu间数据同步，但是mesi做cpu间同步是有缺陷的。cpu的核a需要等待cpu核b的明确返回消息才能执行下一步，如果这个时候核b执行死循环，此时的cpu核a也在忙等同步消息返回。为了解决这种缺陷，引入了invalid queue和store buffer。cpu核a通知核b的信息，自己更改的head++放入store buffer，核心b的head失效信息放在invalid queue中。此时核a缓存中的head和核b中的值都不是正确的值，写屏障的意思是：核a把store buffer的值刷新到缓存中，这个时候取值才是正确的；读屏障的意思是：核b取head的值，会检查invalid queue，如果发现缓存失效，去内存中取正确的值。他们的表现都是cpu指令乱序执行，本质是硬件层面引入mesi导致硬件层面不能保证指令信息同步，需要软件层面的内存屏障来保证。
: - 来自「最水木 for iPhone X」
--
FROM 112.64.184.*
能提示一下哪些thread-safe好的库，请教请教
【 在 MegaStone 的大作中提到: 】
: Consistency model确实不是做业务需要考虑的。有那么多debug好的thread-safe库，就不要重复造轮子了。更何况risc-v上的thread-safe concurrent data structure不是造轮子，而是造火箭 :)
: 不过我觉得现在armv8/risc-v的release consistency model已经是多核CPU最完美的consistency model了。x86 TSO约束的太死了，只允许read超前write，这导致coherence protocol设计和验证都太复杂，而且很多情况下软件也不需要那么严格的约束。release consistency刚刚好，软件只需要考虑acquire-release语义，按需要来决定程序要同步的地方，同时硬件上对于普通的read write可以任意乱序，提供了足够多的Memeory-level parallelism掩藏acquire/release coherence latency；同时release consistency又不像POWER那样有那么多乱序的可能性，搞出那么多种fence，学习成本太高
:
--
FROM 112.64.184.*