Re: [boost] [thread] thread interruption semantics

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

"Preston A. Elder" <prez_at_[hidden]> writes:

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

The Windows implementation has lock(), unlock() etc as well. They are in the
public base class detail::basic_timed_mutex

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

I still don't see why you need to do that.

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

It seems to me that the interfaces are much more consistent with the new
implementation.

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

I agree there are circumstances where that is useful.

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

I can understand that point of view, but the current boost interface matches
POSIX cancellation, so it doesn't seem jarring to me.

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