Subject: Re: [boost] Portable robust mutex an another try...
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-27 07:48:38
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
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk