Boost logo

Boost :

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
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at