首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >内存障碍:软件黑客的硬件视图示例3

内存障碍:软件黑客的硬件视图示例3
EN

Stack Overflow用户
提问于 2017-10-09 21:55:55
回答 1查看 666关注 0票数 3

我正在从原来的论文内存障碍:软件黑客的硬件视图中拷贝这个数字的文本。

表4显示了由CPU 0、1和2并发执行的三个代码片段,所有变量最初为零。 请注意,CPU 1和CPU 2在第3行看到CPU 0分配给“b”之前,都不能继续到第5行。一旦CPU 1和2在第4行执行了它们的内存屏障,它们都保证在第2行的内存屏障之前看到CPU 0的所有分配。类似地,第8行的CPU 0与第4行的CPU 1和2的内存屏障一样,所以CPU 0在第9行分配到“a”之后才能执行对其他CPU的“e”分配。因此,CPU 2在第9行的断言保证不会触发。

对我来说,CPU0上的第6-9行似乎完全没有必要,因为第2行的内存屏障对于CPU 0,第4行的内存屏障是用于CPU 1和2的,这保证了b=1的效果,并且所有存储之前的存储,也就是a=1。然后,断言e == 0 || a == 1总是成功的。

我不知道我是否忽略了什么。如有任何澄清,我们将不胜感激。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2017-10-11 02:47:17

将第6-9行排除在CPU 0之外,肯定会防止assert()触发。同样,如果e被初始化为零,那么除assert之外的所有代码也会被删除。然而,这两种修改都没有帮助。相反,断言的关键点是“CPU 2是否有可能在执行结束时看到状态e==1&&a==0?”从这个角度来看,这应该会迫使你去思考什么价值观是按照什么顺序传播的。

但你忽略的主要问题是,这篇论文非常古老,从那以后,在理解和形式化内存排序方面已经取得了巨大的进步。我正在为并行编程很难,如果是的话,你能做些什么?添加一个新的内存排序章节,同时,这里这里这两篇文章可能会有所帮助。

或者,如果您想查看这本书的当前状态,git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.git

票数 4
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/46655547

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档