On 24 Jul 2014 at 23:48, Jonathan Wakely wrote:
In my attempt to implement a robust mutex that models the C++11 Mutex concept I decided to add a new overload of try_lock, taking a tag type to indicate you are prepared to deal with the inconsistent state. The C++11 try_lock() function only returns true or false, which can't support the third state that can occur when locking a robust mutex, and I didn't want to rely on users calling an extra function to query whether a successful try_lock was *really* successful (in generic code working with any Mutex type failing to handle the inconsistent state could be disastrous).
If you call the normal zero-argument try_lock() on my type and it's inconsistent you get an exception and it's marked as unrecoverable. If you call the try_lock(robust_t) overload you get a chance to recover it.
I dislike this design approach. This is one of those few areas where I think an "inconsistent handling" callback handler is the best approach, with a default implementation using a heartbeat and pid based approach. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/