id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1951	boost::interprocess::named_condition::do_wait() releases mutex prematurely, may miss notification	Stas Maximov <smaximov@…>	Ion Gaztañaga	"Implementation of boost::interprocess::named_condition::do_wait() is shown below:

template <class Lock>
void do_wait(Lock& lock)
{
   lock_inverter<Lock> inverted_lock(lock);
   //unlock internal first to avoid deadlock with near simultaneous waits
   scoped_lock<lock_inverter<Lock> >   external_unlock(inverted_lock);
   scoped_lock<interprocess_mutex>     internal_lock(*this->mutex());
   this->condition()->wait(internal_lock);
}

Lock lock is associated with the condition variable and must be released only inside wait(). This implementation releases the lock before it enters the wait(). If lock released before wait() is entered, this function may be pre-empted by a notifier thread, just after the lock has been released, but before wait() has been entered. In such case notification will be missed by the wait().

Having a mutex associated with condition variable is a fundamental requirement. Use of another mutex (internal_lock in this case), not known to the notifier is not a solution. Both the receiver and the notifier, both must use the same CV *and* MX.

This is like a root cause of hangs in named_condition_test on Fedora9 running on single-cpu system under vmware-server-1.0.5.



"	Bugs	closed	Boost 1.36.0	interprocess	Boost 1.35.0	Showstopper	fixed	named_condition_variable interprocess sync mutex condition_variable