M**u
发帖数: 10158 | 1 有一个全局变量flag,初始化为0
然后线程A写这个变量flag=1
另外一个线程B不停地读这个变量
while (flag != 1)
sleep (5); //waiting for flag to set as 1
thread_B_do_real_thing_with_flag_1 ();
没有别的线程操作这个flag，请问这种情况下，需要加锁么？
我感觉pthread_cond_wait做这个更好一点 |
g**e
发帖数: 6127 | 2 thread B may never jump out of the loop, even when flag is changed from 0 to
1.
you should use volatile key word for flag.
【在 M**u 的大作中提到】
: 有一个全局变量flag,初始化为0
: 然后线程A写这个变量flag=1
: 另外一个线程B不停地读这个变量
: while (flag != 1)
: sleep (5); //waiting for flag to set as 1
: thread_B_do_real_thing_with_flag_1 ();
: 没有别的线程操作这个flag，请问这种情况下，需要加锁么？
: 我感觉pthread_cond_wait做这个更好一点
|
M**u
发帖数: 10158 | 3 在用了volatile，防止compile的优化后，
还需不需要用lock呢？
to
【在 g**e 的大作中提到】
: thread B may never jump out of the loop, even when flag is changed from 0 to
: 1.
: you should use volatile key word for flag.
|
g**w
发帖数: 969 | 4 不需要
但是浪费CPU
【在 M**u 的大作中提到】
: 在用了volatile，防止compile的优化后，
: 还需不需要用lock呢？
:
: to
|
M**u
发帖数: 10158 | 5 所以其实还是lock要好？谢谢啊
【在 g**w 的大作中提到】
: 不需要
: 但是浪费CPU
|
g**w
发帖数: 969 | 6 看thread A的任务是啥，需要多少时间完成
如果B等的时间极短，比如几百，几千个cycle,可以用你的方法，类似spin lock,不停
的poll
如果时间很长，就用kernel mode的event之类，B wait on event, A signal event
when its task complete.
如果介于两者之间，用windows下类似critical section之类的，内部实现就是先spin
一会，如果不能acquire, switch to kernel mode wait.
【在 M**u 的大作中提到】
: 所以其实还是lock要好？谢谢啊
|
M**u
发帖数: 10158 | 7 等待的时间比较随机，取决于别的模块是不是正常工作。。。
还是用pthread_cond_wait/pthread_cond_signal了
spin
【在 g**w 的大作中提到】
: 看thread A的任务是啥，需要多少时间完成
: 如果B等的时间极短，比如几百，几千个cycle,可以用你的方法，类似spin lock,不停
: 的poll
: 如果时间很长，就用kernel mode的event之类，B wait on event, A signal event
: when its task complete.
: 如果介于两者之间，用windows下类似critical section之类的，内部实现就是先spin
: 一会，如果不能acquire, switch to kernel mode wait.
|
t****t
发帖数: 6806 | 8 use atomic if you can. volatile should work as well, but it is not as good
as atomic. for one thing, atomic R/W includes memory barrier.
【在 M**u 的大作中提到】
: 在用了volatile，防止compile的优化后，
: 还需不需要用lock呢？
:
: to
|
|
M**u
发帖数: 10158 | 9 恩
我觉得这两都是worked，但是我不知道哪一种最好，目前是用atomic了
谢谢了。。。
【在 t****t 的大作中提到】
: use atomic if you can. volatile should work as well, but it is not as good
: as atomic. for one thing, atomic R/W includes memory barrier.
|
h***i
发帖数: 1970 | 10 atomic是c++0x吧，你用boost?
【在 M**u 的大作中提到】
: 恩
: 我觉得这两都是worked，但是我不知道哪一种最好，目前是用atomic了
: 谢谢了。。。
|
|
|
F*******i
发帖数: 190 | 11 hi thrust,
can you give more insights about the atomic? is it a keyword or something
eles?
thanks!
【在 t****t 的大作中提到】
: use atomic if you can. volatile should work as well, but it is not as good
: as atomic. for one thing, atomic R/W includes memory barrier.
|
t****t
发帖数: 6806 | 12 it's part of c++0x. basically it's (volatile when needed) + barrier.
【在 F*******i 的大作中提到】
: hi thrust,
: can you give more insights about the atomic? is it a keyword or something
: eles?
: thanks!
|
n*********i
发帖数: 567 | 13 不需要加锁。如果你希望B response快，就像现在这样不停的CHECK。如果间隔时间长
，希望省一些CPU，就加个EVENT之类的。 |
m*****n
发帖数: 204 | 14 Volatile is not safe because reads and writes to a volatile variable are not
memory barriers. I remember reading something on William Pugh's web site.
His write up is in the context of java but applies to C as well. Basically,
volatile forces the optimizer to keep the memory access, but it does not
prevent the compiler from moving the read/write around. Therefore, the write
to flag by thread B may be moved forward, to somewhere when the work is not
done yet.
【在 M**u 的大作中提到】
: 恩
: 我觉得这两都是worked，但是我不知道哪一种最好，目前是用atomic了
: 谢谢了。。。
|
m*****e
发帖数: 4193 | 15 avoid volatile at all cost.
【在 M**u 的大作中提到】
: 恩
: 我觉得这两都是worked，但是我不知道哪一种最好，目前是用atomic了
: 谢谢了。。。
|
g**e
发帖数: 6127 | 16 你说的是c++的？ java里的1.5以后没啥不能用的
【在 m*****e 的大作中提到】
: avoid volatile at all cost.
|
s*******e
发帖数: 432 | 17 I thought you still need to lock the flag. Thinking about the following
situation: after your thread read flag value into the register and before
setting flag to 1, your program is interrupted. Then thread A is suspended
and registers snapshot is stored. Later the program is resumed and thread B
wake up first. then you get a problem |
t****t
发帖数: 6806 | 18 你没看清他的要求, A是不读flag的, 只写1
B是不写flag的, 只读1
只要顺序不错(即有barrier), 不需要lock
before
B
【在 s*******e 的大作中提到】
: I thought you still need to lock the flag. Thinking about the following
: situation: after your thread read flag value into the register and before
: setting flag to 1, your program is interrupted. Then thread A is suspended
: and registers snapshot is stored. Later the program is resumed and thread B
: wake up first. then you get a problem
|
