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