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
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
>> 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.
> _______________________________________________ Unsubscribe & other
> changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk