Boost logo

Boost :

Subject: [boost] Interprocess mutex & condition variable at process termination
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2017-02-15 17:42:45


Dear Experts,

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.

Google tells me that I'm not the first to be surprised by this; there
have been previous posts here, stack overflow questions etc.

One often-valid observation is that if a process crashes - or
otherwise terminates without executing its destructors - while it
holds a lock on a shared data structure then the data is probably
now corrupt, so unlocking the mutex that protects it is not very
useful. I think there is an important case where that does not
apply - when the process that crashes is only reading the shared
data. In my case, I had written a "monitor" utility that loops
forever, waiting on a shared condition, taking the corresponding
mutex, and then dumping the shared data to stdout. I had been
running this and stopping it by pressing ctrl-C and it had not
occurred to me that this might not work as I expected. My
attempt at debugging using this utility was making my problems worse,
not better! Modifying this code to run destructors on ctrl-C is
non-trivial.

I am aware that the SysV shared semaphore is able to undo on
process termination (see SEM_UNDO in man semop), and I had assumed
that Boost.Interprocess was using this or something like it. I
now see that it is using pthreads, which I didn't even realise
could work between processes, and I don't think this API has
any way to specify process termination behaviour.

Anyway, I'd like to suggest that the interprocess docs should
make some mention of the behaviour of the synchronisation
primitives on process termination, e.g. somewhere near the
beginning of http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes

I may now try to implement some primitives that use semop() and
unlock automatically. I haven't yet looked at what's involved to
implement a condition variable on top of a semaphore, so I may not
get very far! Has anyone else ever tried this?

Also, I note that Interprocess is using "old style" times, not
std::chrono like the std::mutex/condition do. Are there any plans
to update this?

Thanks,

Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk