Re: [boost] [thread] thread interruption semantics

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2007-11-14 07:23:05

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...

albeit interruptably. :-)

regards,
alexander.