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
> 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 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk