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 14:41:56

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

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.