Subject: Re: [boost] Interprocess mutex & condition variable at process termination
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-02-16 18:02:18
On 16/02/2017 12:31, Phil Endecott via Boost wrote:
> Andrey Semashev wrote:
>> On 02/15/17 20:42, Phil Endecott via Boost wrote:
>>> I've just been surprised by the behaviour of the interprocess
>>> mutex and condition variable on abnormal process termination, i.e.
>>> they are not automatically released.
>> There is a way to handle this case, but this API is not universally
> I think that in my case where I have some processes that only
> read the shared data, it would be possible to handle EOWNERDEAD
> by either continuing if the previous lock were a read-lock, or
> by throwing if it were a write lock. I don't think Interprocess
> does any of this, does it?
>> The best solution to these problems, however, is to avoid locks
>> altogether and use lock-free algorithms in such a way that any data in
>> the shared memory is valid and can be handled.
> Maybe, though my next concern would be how to implement the functionality
> of a condition variable. What happens if a process crashes while it
> is waiting on a condition variable? I did once know how Linux
> implements condition variables using atomics and futexes, and I
> think it's probably safe to crash in this situation, but I guess
> there are no guarantees.
The only portable way that I know of to build a portable interprocess
mutex which knows when one of the processes has died is using a pipe
instance. You write a byte to "unlock" the mutex and read all bytes
until it's empty to "lock" the mutex. select() can be used to block
until the mutex is unlocked.
I've built a fair few of these over the years and performance is
actually pretty good considering what it is. I'm kinda surprised that
Boost.Interprocess doesn't have one yet.
-- 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