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

From: Eugene Prystupa (prystupa_at_[hidden])
Date: 2006-11-29 21:01:48

Thanks, Peter. This is an explanation I was looking for.

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:004e01c7135c$2bd5f670$6607a8c0_at_pdimov2...
> 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.
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>