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