Re: [boost] [thread] thread interruption semantics

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-14 07:34:01

Alexander Terekhov <terekhov_at_[hidden]> writes:

> Anthony Williams wrote:
>> 
>> Alexander Terekhov <terekhov_at_[hidden]> writes:
>> 
>> > Anthony Williams wrote:
>> >>
>> >> "Preston A. Elder" <prez_at_[hidden]> writes:
>> >>
>> >> > On Tue, 13 Nov 2007 19:50:04 +0000, Preston A. Elder wrote:
>> >> >
>> >> >> Ironically, the new interface makes this whole thing harder.  Mainly
>> >> >> because of two reasons:
>> >> >
>> >> > OK, I take it all back!
>> >>
>> >> ;-)
>> >>
>> >> > Here is my new interruptable_mutex, using the new boost::thread:
>> >> > http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils/interruptable_mutex.h?r=428
>> >> >
>> >> > It turns out it is much simpler to implement ;)
>> >>
>> >> Excellent. I think there's a bug in your timed_lock --- it doesn't quit when
>> >> the timeout expires. Easy to fix --- just check the return value from
>> >> m_cond.timed_wait.
>> >
>> > This isn't the only bug. It uses condition variable totally incorrectly.
>> 
>> That's an interesting comment. Can you elaborate?
>
> t0: thread A holds the lock
> t1: thread B calls lock() and does internal try_lock() twice (both fail)
> t2: thread A calls unlock() and does notify_all() (nobody's waiting)
> t3: thread B enters wait() on condvar and waits and waits and waits...

Oh, that problem. I hadn't looked at the code close enough to spot that one,
but it's a common issue --- you need to hold the internal lock when you modify
the data being checked by the predicate (in this case unlocking the external
mutex).

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL