Re: [Boost-users] [thread] Out of order problem signalling a condition and waiting on a predicate

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-05-09 11:37:07

Kirit Sælensminde wrote:

> This does raise a couple of questions though. I'm not sure that I
> understand why the mutex lock is required here anyway. If the
> condition requires a lock for the notify to operate properly then
> shouldn't the notify operations take a lock like the wait operations
> do? Or is it my use of the flag that causes this to require a lock?

The condition doesn't require a lock for notifications, but your 
manipulation of the predicate needs to be protected with a lock. You could 
do

{
  scoped_lock lock( m_mutex );
  m_completed = true;
}
m_control.notify_all();

If you take away the lock entirely, it won't work even if m_completed is 
atomic. The minimum that you need for correctness in this case is:

m_completed = true; // assumed atomic_store_release
{
  scoped_lock lock( m_mutex );
}
m_control.notify_all();

Most people never encounter this issue because they don't use atomic 
variables as predicates and the lock is needed to avoid the data race. You 
don't gain much from the atomicity anyway.