x*********h
发帖数: 25 | |
T*******i
发帖数: 4992 | 2 nothing new
【在 x*********h 的大作中提到】
: http://www.zxbc.cn/html/20070628/24030.html
: 关于c++线程和内存模型的讨论
: 感觉不少东西颠覆了俺的一些认识
|
m*****e
发帖数: 4193 | 3 没看那个paper，不过就是一个memory barrier的问题。这个确实是标准的缺陷，但是
practically大家已经在用compiler/memory barrier了。只是是否标准化的问题。
【在 x*********h 的大作中提到】
: http://www.zxbc.cn/html/20070628/24030.html
: 关于c++线程和内存模型的讨论
: 感觉不少东西颠覆了俺的一些认识
|
x*********h
发帖数: 25 | 4 我得疑问是c++编译器对于程序优化导致data-race那一段，
感觉有些疑问，
以前好像没有遇到过
【在 m*****e 的大作中提到】
: 没看那个paper，不过就是一个memory barrier的问题。这个确实是标准的缺陷，但是
: practically大家已经在用compiler/memory barrier了。只是是否标准化的问题。
|
m*****e
发帖数: 4193 | 5 You don't normally encounter it because you normally use lock/unlock which
are memory-barrier primitives.
It's only a problem for trick situations where you think you can avoid the
lock/unlock but you actually cannot due to this reason.
【在 x*********h 的大作中提到】
: 我得疑问是c++编译器对于程序优化导致data-race那一段，
: 感觉有些疑问，
: 以前好像没有遇到过
|
x*********h
发帖数: 25 | 6 int count = 0;
bool flag = false;
Thread1 Thread2
count = 1; while(!flag);
flag = true; r0 = count;
Frankly speaking, if coding like above, I would assume that the r0 is 1.
What is the mentioned "Observable Behavior" mentioned in this situation? Is
it because that the changes of variables in memory may not be observed by
other thread?
If the first case can be understood as the "Observable Behavior" situation,
the below case make me confused.
x = y = 0;
Thread1 Thread2
x = 1; y =
【在 m*****e 的大作中提到】
: You don't normally encounter it because you normally use lock/unlock which
: are memory-barrier primitives.
: It's only a problem for trick situations where you think you can avoid the
: lock/unlock but you actually cannot due to this reason.
|
x****u
发帖数: 44466 | 7 典型小p孩写的垃圾文章，胡说八道并且故弄玄虚。
概要意思就是说编译器优化可能会乱序执行某些东西，所以关掉优化就好了。好个p啊。
如果用了互斥原语以外的机制做同步互斥，就可能会出现问题。但是问题在于，使用互
斥原语外的方法来做同步互斥本身就是有问题。就算编译器不优化，CPU也是有乱序执
行的技术的。
无数例子警告我们，除非万不得已并且花了很大代价调研，否则绝对不要轻易使用某些
想当然的重复自创的技巧，哪怕是OS课上老师讲过的。
至于多线程关掉优化，就两个字，胡扯。C++03的做法一点没错，因为你管得住编译器
也管不住CPU。
讲个笑话，某个小p孩曾经鄙视过我，说你还用WaitForSingleObject这么土的WinAPI，
我用汇编写的自旋锁又快又简单，微软还搞个API，真是猪头。我的伟大的SDK里面就是
不用它！
【在 x*********h 的大作中提到】
: http://www.zxbc.cn/html/20070628/24030.html
: 关于c++线程和内存模型的讨论
: 感觉不少东西颠覆了俺的一些认识
|
x****u
发帖数: 44466 | 8 在这个地方标准没缺陷，只是小p孩脑残。如果C++作为一个编译成机器码的语言存在的
话，这个问题在编译层次解决不了。实际上本来也不必解决。C++的设计思想就是不给
CS文盲擦屁股。
【在 m*****e 的大作中提到】
: 没看那个paper，不过就是一个memory barrier的问题。这个确实是标准的缺陷，但是
: practically大家已经在用compiler/memory barrier了。只是是否标准化的问题。
|
m*****e
发帖数: 4193 | 9 The problem of standard is the "volatile" keyword. It tries to use it to
achieve some kind of concurrent programming model but it's never well-
defined and in practice harmful to use (it pretty much turns off all
optimizations).
【在 x****u 的大作中提到】
: 在这个地方标准没缺陷，只是小p孩脑残。如果C++作为一个编译成机器码的语言存在的
: 话，这个问题在编译层次解决不了。实际上本来也不必解决。C++的设计思想就是不给
: CS文盲擦屁股。
|
m*****e
发帖数: 4193 | 10
Because the compiler does not have the concept of concurrency, it thinks the
two instructions for thread1 are independent and thus it's free to re-order
them. So you need a compiler-barrier between them to avoid this kind of re-
ordering.
Is
And there are things like this on the CPU level that the changes to memory
are not visible in the same order too. You'd need memory-barriers (including
read, write and full barriers) to avoid it.
So if you don't want locks, then you can do:
Thread 1
count =
【在 x*********h 的大作中提到】
: int count = 0;
: bool flag = false;
: Thread1 Thread2
: count = 1; while(!flag);
: flag = true; r0 = count;
: Frankly speaking, if coding like above, I would assume that the r0 is 1.
: What is the mentioned "Observable Behavior" mentioned in this situation? Is
: it because that the changes of variables in memory may not be observed by
: other thread?
: If the first case can be understood as the "Observable Behavior" situation,
|
|
|
x****u
发帖数: 44466 | 11 volatile不是干这个用的啊，它不能禁止优化，控制程序执行路径啊。
程序被乱序编译或被乱序执行是常识，在OS的代码里面就可以看到大量的执行次序敏感
代码，看看就明白了。
【在 m*****e 的大作中提到】
: The problem of standard is the "volatile" keyword. It tries to use it to
: achieve some kind of concurrent programming model but it's never well-
: defined and in practice harmful to use (it pretty much turns off all
: optimizations).
|
m*****e
发帖数: 4193 | 12 volatile was introduced to avoid optimizations that break concurrency.
【在 x****u 的大作中提到】
: volatile不是干这个用的啊，它不能禁止优化，控制程序执行路径啊。
: 程序被乱序编译或被乱序执行是常识，在OS的代码里面就可以看到大量的执行次序敏感
: 代码，看看就明白了。
|
t****t
发帖数: 6806 | 13 嗯, 同意
不用OS支持的多线程本来就是problematic
啊。
【在 x****u 的大作中提到】
: 典型小p孩写的垃圾文章，胡说八道并且故弄玄虚。
: 概要意思就是说编译器优化可能会乱序执行某些东西，所以关掉优化就好了。好个p啊。
: 如果用了互斥原语以外的机制做同步互斥，就可能会出现问题。但是问题在于，使用互
: 斥原语外的方法来做同步互斥本身就是有问题。就算编译器不优化，CPU也是有乱序执
: 行的技术的。
: 无数例子警告我们，除非万不得已并且花了很大代价调研，否则绝对不要轻易使用某些
: 想当然的重复自创的技巧，哪怕是OS课上老师讲过的。
: 至于多线程关掉优化，就两个字，胡扯。C++03的做法一点没错，因为你管得住编译器
: 也管不住CPU。
: 讲个笑话，某个小p孩曾经鄙视过我，说你还用WaitForSingleObject这么土的WinAPI，
|
x*********h
发帖数: 25 | 14 呵呵,谢谢
查了一些资料,明白是怎么回事了
【在 x****u 的大作中提到】
: 在这个地方标准没缺陷，只是小p孩脑残。如果C++作为一个编译成机器码的语言存在的
: 话，这个问题在编译层次解决不了。实际上本来也不必解决。C++的设计思想就是不给
: CS文盲擦屁股。
|
a****l
发帖数: 8211 | 15 the problem is that text programs are inheierently sequential, thus you have
all kinds of problem when going to parallel world.
Change to dataflow programming, and lots of problems can be simply avoided.
【在 x*********h 的大作中提到】
: http://www.zxbc.cn/html/20070628/24030.html
: 关于c++线程和内存模型的讨论
: 感觉不少东西颠覆了俺的一些认识
|
x****u
发帖数: 44466 | 16 volatile只能用在变量上面，怎么禁止优化？
【在 m*****e 的大作中提到】
: volatile was introduced to avoid optimizations that break concurrency.
|
