Boost logo

Boost :

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
> 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at