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 supported:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_...
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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/