zylthinking
发表于 2011-10-14 12:05
靠, 我自己想明白了。
多CPU, 则如五楼所引用, 没有出问题可能;
单CPU就更没有可能了; CPU 的读写依赖可是和线程无关的, 就算它转到其他线程, 照样是一个读写依赖, 这足够保证不出问题的了
zylthinking
发表于 2011-10-14 12:27
虽然有读写依赖, 但由于线程变了, CS:EIP被切换, 虽然有依赖但似乎已经无法继续执行前一个线程的写操作, 不过在这里应该是CPU考虑的问题, 估计CPU会做某些动作; 至少指令进入CPU是顺序进入的, 只是在内部乱而已, 那么就算CS:EIP变了, 写指令也在改变之前进入CPU了, CPU应该有足够能力保证这个读写依赖的顺利执行
kouu
发表于 2011-10-14 12:39
回复 11# zylthinking
多CPU的问题,5楼的同学是断章取义了。塑料袋的帖子(http://bbs.chinaunix.net/viewthread.php?tid=3593865&rpid=21444816&ordertype=0&page=1#pid21444816)可没有说现在的所有CPU都严格按照这两条“原理”来设计吧。如果是这样,那还需要内存屏障干什么?
单CPU的问题,如何保证编译器不重排指令?如果指令不重排,貌似确实没什么问题。
eexplorer
发表于 2011-10-14 12:42
回复 11# zylthinking
搞不懂这个和线程切换有什么关系。假设多cpu,thread A 在cpu1, thread B在cpu 2, 如果cpu1 reorder了thread A的memory write,那么thread B在cpu2上就可能先看到enable的update,下面的memory copy就会有问题。
你的code在x86上没有关系,因为x86不会reorder memory write.
asuka2001
发表于 2011-10-14 13:01
回复 13# kouu
的确是我相当然了,感谢指出!
zylthinking
发表于 2011-10-14 13:58
回复zylthinking
多CPU的问题,5楼的同学是断章取义了。塑料袋的帖子()可没有说现在的所有CP ...
kouu 发表于 2011-10-14 12:39 http://bbs.chinaunix.net/images/common/back.gif
多CPU如果不考虑这个原则, 那就真的对应用程序来说是灾难了, 问题是几乎没有内存屏障概念的用户空间代码似乎在这方面没有出现过太多的问题, 自然也有可能是现实中大部分是x86的, 或者其他平台也未必一定不遵守这个约定; 就我记忆, 似乎情景分析下册 smp 那一章提到过x86的什么机制来着, 反正就是多核心变量同步对程序员做到透明了, 至于这样, 为什么还需要mb, barrier这些东西写在源码里, 我还真没思考过, 连这个内存屏障的基本作用也是今天才弄清楚了一点点。
单cpu编译器优化导致的问题, 很有可能就是现实存在的, 听说过很多gcc O3 优化导致出问题的说法, 但一直没研究过
ruslin
发表于 2011-10-14 15:37
回复 16# zylthinking
原来是我的帖子新开出来的啊。
其实我的文档里面写了,用户态多线程操作共享数据时都需要加锁的(类似于内核信号量),这应该是基本原则。我以前工作就是做linux用户态多线程服务器的,不加锁就等着段错把。
zylthinking
发表于 2011-10-14 15:39
回复zylthinking
原来是我的帖子新开出来的啊。
其实我的文档里面写了,用户态多线程操作 ...
ruslin 发表于 2011-10-14 15:37 http://bbs.chinaunix.net/images/common/back.gif
你没有仔细看我贴出的代码
塑料袋
发表于 2011-10-14 16:09
进程切换的时候,必然是需要一个同步点的,这是一个一般原则。
multipul processor memory consistency model (?好像是这个名字),又缩写为WRL-95-9的一篇文章里,专门有一章thread migration,谈了半天这个问题。
zylthinking
发表于 2011-10-14 16:22
进程切换的时候,必然是需要一个同步点的,这是一个一般原则。
multipul processor memory consistency...
塑料袋 发表于 2011-10-14 16:09 http://bbs.chinaunix.net/images/common/back.gif
就等你呢, 那么现在一个基本问题: 缺乏 barrier 造成的代码重排, 可能导致
thread A:
ptr->buf = malloc();
ptr->flag = 1;
thread B:
if(ptr->flag == 1){
memcpy(ptr->buf, ...)
}
会不会存在???
另一个问题:
CPU 乱序执行, 如果ptr->flag = 1先执行了, 但前一个还没有执行, 在X86 下, 很显然这个执行结果不会传出 CPU外, 那么同时CPU2 执行到 if(ptr->flag == 1), CPU2能不能即时得到 flag == 1 为 true 的消息???
第三个问题:
如果不是X86, 有没有可能 ptr->flag 能够先传出 CPU外而被 CPU2得知?
以上两种情况如果答案都是true, 都会导致memcpy(ptr->buf, ...), CPU如何防止这种结果
页:
1
[2]
3
4
5
6
7
8
9
10
11