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

From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2007-05-09 09:13:06

Peter Dimov wrote:
> Kirit Sælensminde wrote:
> 
>> // Notify joins
>> boost::mutex::scoped_lock lock( m_mutex );
>> j->first->m_completed = true;
>> j->first->m_control.notify_all();
> 
> Are you sure that you want to lock m_mutex here and not j->first->m_mutex? 
> (Also applies to the catch clauses.) 

Absolutely brilliant! Thanks Peter. I've been staring at that code for a 
few days and not seen that.

I've made the changes and run this a few times and no lock-ups yet so 
hopefully that's the last problem there.

I knew I could rely on me being daft :)

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 very next set of primitives that I need to work on is a thread pool. 
The Boost pool doesn't really seem to have much in the way of 
functionality. What I really need to be able to do is to wait on a 
collection of conditions and then queue more work for whichever thread 
finishes first.

I think I can do this given the Boost primitives if I spend another 
thread to co-ordinate it all, but I haven't thought this through 
properly yet so it may be just another condition/mutex pair per pool 
(which seems more likely).

A final question would be about the value of including a condition/mutex 
pair that wrap the wait and notify operations one step further to stop 
the sort of mistake I was making?

BTW, I'm quite happy to work to add these extensions to the Boost 
threads library if there is thought to be any value in doing so. If not 
they will eventually make it into an open source library anyway though.

K