Re: [boost] boost interprocess (>1.45) robust mutexes

Subject: Re: [boost] boost interprocess (>1.45) robust mutexes
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2011-03-31 15:04:53

On Mar 31, 2011, at 2:41 PM, Kim Barrett wrote:
> On Mar 31, 2011, at 1:09 PM, Ion Gaztañaga wrote:
>> El 31/03/2011 17:09, Rusk . escribió:
>>> Thanks very much for your reply.
>>> 
>>> In my application I wanted to use interprocess_condition class as well -
>>> what would I need to modify in there to cope with EOWNERDEAD errors?
>> 
>> I'm afraid I haven't experimented with condition variables and EOWNERDEAD. Currently there is no interface to know if EOWNERDEAD was returned from internal condition variable wait. I don't know which solution will be best. You will need to experiment a bit...
> 
> 
> I developed an API for robust mutexes and associated condition variables that has been in use for a while by my employer. 
> 
> The key to the API is that all locking operations, which includes condition wait operations (since they implicitly unlock and then relock) take a handler function that is called within the lock context if the lock operation indicated EOWNERDEAD.  This handler function should do one of the following:
> 
> - die in turn, leaving the mutex "inconsistent" for the next locker,
> 
> - determine it can proceed, possibly after performing some fixups, and reset the mutex to "consistent", or
> 
> - determine that recovery is not possible and set the mutex to "unrecoverable", which cannot later be changed back to "consistent".

Forgot one thing: unlock of an "inconsistent" (e.g. returned EOWNERDEAD and not set consistent) sets the mutex unrecoverable.

> 
> In this API robust mutexes don't try to model the Boost.Thread Lockable concept.  That concept's lock() and try_lock() operations don't provide any direct mechanism for indicating EOWNERDEAD to the caller.  While robust mutexes could additionally provide such functions which fail in that situation, I don't think there's any real use-case for such behavior because the primary reason for using a robust mutex is to have access to the EOWNERDEAD information.
> 
> I've been given permission by my employer to share this code if it will help get support for robust mutexes into boost.interprocess.  I might need to sanitize it a bit first though, and the above discussion is really the important bit, the rest is just straight forward code.
> 
> 
>