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:
>>> 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
>> 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
> 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
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk