0
点赞
收藏
分享

微信扫一扫

你觉得好的代码可能并不是最优的解决方案


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

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

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

你觉得好的代码可能并不是最优的解决方案_java

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

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

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

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

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

你觉得好的代码可能并不是最优的解决方案_linux_02

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

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

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

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

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

之后就是

你觉得好的代码可能并不是最优的解决方案_算法_03

之后就是Linus的建议

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

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

你觉得好的代码可能并不是最优的解决方案_c++_04

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

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

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

你觉得好的代码可能并不是最优的解决方案_linux_05

——最后的修改如下

你觉得好的代码可能并不是最优的解决方案_java_06

你觉得好的代码可能并不是最优的解决方案_linux_07


举报

相关推荐

0 条评论