Re: [boost] [thread] thread interruption semantics

From: Preston A. Elder (prez_at_[hidden])
Date: 2007-11-13 14:50:04

Ironically, the new interface makes this whole thing harder.  Mainly 
because of two reasons:

1) inconsistent mechanisms for locking between different thread types, 
and no standard interface for locking.  In other words, in pthreads, 
boost::mutex has a lock(), unlock(), etc. call.  In the windows 
implementation it does not.  This means my new implementation has to work 
through the proxy interfaces of scoped_lock and such.  Which in and of 
itself makes things more complicated.

2) There is no mechanism to differentiate a lock/unlock when called from 
a condition, and when called by scoped_lock.  This differentiation in the 
was critical in my implementation of conditions using my interruptable 
mutex.  Namely it allowed me to use special handling when used in 
conditions to ensure that, inside a condition - I unlock the 'real' 
mutex, and acquire the 'internal' mutex for passing to the condition, and 
when the condition exited, I can unlock the 'internal' mutex, and re-lock 
the 'real' mutex in an interruptable fashion.

Basically, the use of the lock_ops class, which I could specialize made 
implementation much easier.  There is a lot more concrete code and 
inconsistent interfaces (especially at the interface level) for me to be 
able to do this through anything but a scoped_lock.

But anyway, I still think interruption is a dangerous facility when you 
cannot interrupt a mutex.lock() call waiting on a contested resource.

And to be honest, I would think that you should have 
interruptable_condition if you are going to have interruptable_mutex.  
The fact one can be interrupted and the other not is just strange a 
little jarring.

PreZ :)

On Tue, 13 Nov 2007 11:18:12 -0500, Howard Hinnant wrote:

> On Nov 13, 2007, at 10:55 AM, Anthony Williams wrote:
> 
>> One principle behind the new lock templates is that it should be easy
>> to incorporate new mutex and lock types, and they will still work with
>> the
>> existing facilities (e.g. condition_variable_any).
> 
> <nod> This is the reason I'm interested in Preston's work.  I see it as
> a test of the N2447
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm )
> interface.  I've been perusing interruptable_mutex.h this morning and
> noting that a lot of the complication is in dealing with the older
> boost::mutex interface (lock_ops and all that).  I'd be very interested
> in seeing this recast to the newer interface, just for the purpose of
> testing the new interface.
> 
> -Howard
> 
> _______________________________________________ Unsubscribe & other
> changes: http://lists.boost.org/mailman/listinfo.cgi/boost