Re: [boost] Interprocess mutex & condition variable at process termination

Subject: Re: [boost] Interprocess mutex & condition variable at process termination
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-02-16 18:28:35

On 02/16/17 15: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
>> supported:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html
>>
>
> Thanks for pointing that out.  For some reason I thought that
> "robust" mutexes solved some other problem.
>
> 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?

No, to my knowkedge, Boost.Interprocess doesn't use rubust mutexes.

You have to know though that condition variables also include a mutex, 
and not a robust one. I don't know of any way, portable or not, to make 
a CV use a robust mutex internally.

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

It depends on whether the process was actually blocked on the futex used 
by CV to wait for notifications. If so, *I think* the failure might be 
recoverable - some other thread will notify more threads than there are 
actually waiting, and that's harmless. If not, then the internal mutex 
in the CV was abandoned in the locked state and the CV is unusable.

Basically, when you want robust mutexes, CVs are not an option. You 
might want to consider process-shared semaphores as a replacement.

http://pubs.opengroup.org/onlinepubs/7908799/xsh/sem_init.html

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

Yes, futexes are the way to go, if you target specifically Linux. The 
important advantage is that you're in control on the mutex/CV 
implementation and can define the behavior if the synchronization 
promitive was abandoned. The tricky part is to detect when it is abandoned.