On Mar 7, 2013, at 1:21 PM, Jonathan Wakely wrote:
Tricky indeed, I've been trying to work out how to map robust mutexes to the C++11 Mutex concepts, and have so far decided that calling robust_mutex.lock() or robust_mutex.try_lock() should throw an exception (with errc::state_not_recoverable) if the owner has died, even though C++11 says try_lock() is non-throwing.
I think that demonstrates that robust mutexes are not models of the C++11 Mutex concepts.
Handling the EOWNERDEAD case has to be requested explicitly by the user by passing a special value of type robust_t:
My approach to using robust mutexes does not attempt to treat them as models of the C++11 Mutex concept. Instead, there are now locking operations associated with them which *require* a handler function that gets invoked on EOWNERDEAD. This approach filtered up to condition variables too; can't use C++11 / boost.thread condition variables with these robust mutexes, because of the requirement for a handler for EOWNERDEAD. I thought about providing C++11 Mutex-like operations to allow these robust mutexes to be used like ordinary mutexes, but ultimately decided there was no real use-case for that, since the whole point of a robust mutex is to support EOWNERDEAD handling.