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