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