Subject: Re: [boost] [interprocess] leaked named mutexes
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2013-03-07 13:21:21
On 7 March 2013 17:50, Kim Barrett wrote:
> On Mar 6, 2013, at 5:51 PM, Eric Niebler wrote:
>> I recently discovered that a process can very easily leave a named mutex
>> dangling. Consider the following:
> To deal with a mutex that was held by a thread whose process has died, one needs to use a "robust" mutex. There's a POSIX mutex construction attribute for making robust mutexes, and it's supported on Linux starting circa 2.6.18(?). I think (some versions of?) Windows provide this mechanism in the native mutexes too. There's a little protocol around mutex lock attempts, where an error return code indicates the earlier owner died, so that as part of lock acquisition you've now also acquired responsibility for dealing with any cleanup.
> Dealing with robust mutexes is tricky. With exception safety one relies on no-throw operations as basic primitives. The nearest cognate in the robust mutex / cross process world is (true, not emulated) atomic operations. You can probably guess what that does to complexity.
Tricky indeed, I've been trying to work out how to map robust mutexes
to the C++11 Mutex concepts, and have so far decided that calling
robust_mutex.lock() or robust_mutex.try_lock() should throw an
exception (with errc::state_not_recoverable) if the owner has died,
even though C++11 says try_lock() is non-throwing. Handling the
EOWNERDEAD case has to be requested explicitly by the user by passing
a special value of type robust_t:
auto result = robust_mutex.lock(robust);
if (result == robust_lock_result::locked)
// got the lock
else // result == robust_lock_result::inconsistent
// we have the lock, but state is unknown
// attempt to recover state and either
robust_mutex.unlock(); // mark mutex as unusable
Has anyone else looked at trying to fit robust mutexes into the C++11
concepts or into Boost?
I'd be interested in working with anyone looking into it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk