晚上我看到了JeffXie 写了一篇关于内存屏障的文章，后面又看到Linus对一次内存屏障修改的建议，所以就有了这篇文章。

https://mp.weixin.qq.com/s/H7Pw8xCKcNu41UGaYB648w

在我看来，内存屏障谁为了让计算机做更加正确的事情，不希望计算机对计算进行排序导致结果不符合预期。

因为是多核计算机，所以会对上面的计算进行指令排序，说指令排序可能觉得拗口，可以认为多核计算的顺序是随机的，随机的执行就会导致随机的结果。

随机的执行结果肯定不符合我们的预期。

—— 所以就出现了内存屏障

内存屏障如果理解简单一些，可以认为是写优先，读次之，因为是对同一片内存「同一个变量」操作。

加了内存屏障的标志，多个cpu之间互相可见，比如cpu1要对变量a操作，如果加了内存屏障其他cpu也会看到cpu1的这个执行指令，就会先等cpu1完成后再去读。

最近的一个关于内存屏障的提交，被Linus驳回重写

提交的理由和代码修改如下

Mikulas是这部分的代码的修改提交，他首先提出了自己的疑问，在wait_on_bit这个函数里面加上内存屏障是否合适？

他觉得应该加上内存屏障的原因是因为这个函数在其他地方要调用，在一些weak memory ordering架构上，这个函数有可能返回无效的值。

关于weak memory ordering 我认为是对指令的一种排序，如果在排序不恰当的架构上，就有可能引起问题。

之后就是

之后就是Linus的建议

首先这是一个基础的接口函数，这个问题在x86上是没有问题的。

之后又说明了内存屏障是不能轻易使用的，要正确的使用它，你为什么还视图提交这方面的comments。

其中提到的修改建议最后被使用在最新的内核代码中，就是重新写一个test_bit_acquire()函数。

而新的函数里面有一个函数是 smp_load_acquire()，这个函数我查了很多资料，最后我自己的理解是，获取这个地址是否有在被其他cpu写，如果没有，就表示当前的cpu可以使用这个地址的值。

可以认为是内存屏障更加精细的函数操作。

——最后的修改如下

关于如何正确只用内存屏障，下面的文章会非常适合大家

https://mp.weixin.qq.com/s/d8UwmHzTxKICN3HvGnbdHQ

参考：

https://lkml.org/lkml/2022/8/25/1225

https://www.kernel.org/doc/Documentation/memory-barriers.txt

http://vh21.github.io/linux/2015/04/25/linux-barrier-api.html