Thanks, Peter. This is an explanation I was looking for. "Peter Dimov" <pdimov@mmltd.net> wrote in message news:004e01c7135c$2bd5f670$6607a8c0@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