C语言标准有没有规定前一个语句必须在后一个语句之前完成？

塑料袋

[quote]
ptr->buffrt = malloc(xxx);
ptr->enable = true;
[\quote]

这两句话有关联，至少CPU认为他们可能有关联，所以只能顺序的将他们提交给load store queue。

因为这两句话完全有可能在对同一个地址进行写操作。谁也不知道在经过TLB转换地址后，ptr->buf和ptr->enable这两个虚拟地址，是不是转换成了同一个物理地址。

zylthinking

你俩对话真搞笑……

我也倾向于volatile也不行，但拿不出确实的证据。

我的理解是volatile只适合 ...
OwnWaterloo 发表于 2011-10-18 15:44

这个， 我连蒙带猜， 有点结论了。。。。。。。从http://baiy.cn/doc/cpp/advanced_ ... e_and_threading.htm里面， 似乎在验证我的想法， 就是确切不知道是不是想对了

zylthinking

[quote]
ptr->buffrt = malloc(xxx);
ptr->enable = true;
[\quote]

这两句话有关联，至少CPU认为他们 ...
塑料袋 发表于 2011-10-18 16:00

那么就是说， 不会乱序写？
不过如果因此不会乱序写，  a = b; c = d; 岂不是CPU也不能在获得物理地址前知道 a, c 地址是不是相同， 那还乱序执行啥， 啥都有这问题啊

狗蛋

请教一下，多线程需要看些什么书啊，  比较守护线程之类的...
多线程是我的一个盲点...
三月廿七 发表于 2011-10-18 14:45

    这个……

理论上说，多线程和多进程没两样，知道锁、旗标、临界区之类同步机制，知道何谓死锁、以及如何防止/解除死锁，知道如何防止数据脏读脏写等等概念就够了；到了实际工作中，根据自己正在打交道的那个线程模型（如posix线程），找相关文档看看即可。


不过，由于多线程模型还不够成熟之类问题，特定语言里可能会有类似volatile这样的尴尬问题。这就好像在好好的c封装上挖了个窟窿，这个窟窿暴露的还不是机器硬件细节，而是编译器内部优化细节。
这类问题可以看看相关语言多线程设计方面的书，了解一些禁忌/特例即可，不必过于深究。毕竟它们只是语言陷阱（语言模型上的漏洞），不涉及多线程机制本身。


至于守护线程，那是设计/实现层面的问题。这个可参考操作系统实现原理之类东西学习/设计。

AD8018

zylthinking，是否可以这样理解？

volatile保证生成的二进制代码里的顺序性。
但即使二进制代码里有顺序性，也挡不住CPU去乱序执行。

OwnWaterloo

ptr->buffrt = malloc(xxx);
ptr->enable = true;

这两句话有关联，至少CPU认为他们可能有关联，所以只能顺序的将他们提交给load store queue。

因为这两句话完全有可能在对同一个地址进行写操作。谁也不知道在经过TLB转换地址后，ptr->buf和ptr->enable这两个虚拟地址，是不是转换成了同一个物理地址。
塑料袋 发表于 2011-10-18 16:00

首先，排除掉typeof(*ptr)是union的情况 —— 这没异议吧？

你说的情况真的可能发生？
页也是有粒度与边界的，cache也是有关联性(associativity)的。
映射关系不是任意的、极度灵活的（不知道该怎么描述）。
lz以及zylthinking并没有指出两成员间的地址差，但也不会特别大吧？

cjaizss

如果不行,写驱动的不用混了
另外,要分清楚编译器行为和硬件行为,不相干的两个概念

zhaohongjian000

你俩对话真搞笑……

我也倾向于volatile也不行，但拿不出确实的证据。

我的理解是volatile只适合 ...
OwnWaterloo 发表于 2011-10-18 15:44

    印象里一些编译器的volatile会加内存屏障的。当然，这只是编译器的实现而已。

zylthinking

如果不行,写驱动的不用混了
cjaizss 发表于 2011-10-18 16:12

如果写驱动的不知道 barrier(), wmb(); rmb(); mb(); 他真的不用混了
无论编译器还是硬件行为， 如果对写代码产生了影响， 程序员就能说不关他事吗

塑料袋

那么就是说， 不会乱序写？
不过如果因此不会乱序写，  a = b; c = d; 岂不是CPU也不能在获得物理地址 ...
zylthinking 发表于 2011-10-18 16:05

   本地CPU看自己的读写，永远是顺序的。  

  因为本地CPU访问某地址时，是在同时查找load store queue和cache。  各读写永远顺序的进入load store queue，乱序的从load store queue出来并进入cache。


  所以其他CPU观察本地cache的话，读写是乱序的； 但是本地CPU根本不能仅仅观察本地cache，它只能同时观察本地cache和load store queue，所以看本CPU的读写是顺序的。

  因此，up上一般用barrier()；因为它只能自己观察自己，不管咋观察，也是看到的顺序读写的结果。

  但是，smp上用mb()；因为涉及到观察其他CPU的cache，会看到乱序的结果。