Re: [boost] [boost.thread] Atomic condition notify/wait on anothercondition

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-11-28 21:14:56

Eugene Prystupa wrote:
> Peter,
>
>> Why do you want to atomically pulse a condvar and acquire a mutex?
>> What do you mean by pulse, and what do you have in mind when you say
>> "atomically" in
>> this context? If you acquire the mutex first, then notify/broadcast,
>> how could your threads detect the non-atomicity of these two
>> actions, and why are they able to?
>
> To be precise I want to notify/broadcast one condition variable and
> simultaneously (atomically) start waiting on another condition
> variable. If I simply notify the first condition variable (and wake thread 
> A) and
> then start waiting on the second condition variable (in thread B),
> chances are thread A may notify on the first condition before thread
> B starts waiting on it.

These races typically don't occur in CV designs since a thread never waits 
for a CV, it waits for a condition in a while loop

lock lk( mx );

while( !condition )
{
    cv.wait( lk );
}

and it's checking the condition under the protection of mx. If the thread 
that modifies 'condition' also does so under the protection of mx, there are 
no races.

You can't use a condition variable as a signalling primitive such as an 
event, because it maintains no state and keeps no memory of the 
notify/broadcast calls. So you need to keep an external predicate.

Sorry if this is already clear. Maybe if you can give more information or a 
simple program that demonstrates what you're after, we'll be able to offer 
some more substantive help.