"Preston A. Elder" <prez@neuromancy.net> 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