Boost logo

Boost :

Subject: Re: [boost] Interprocess mutex & condition variable at process termination
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-02-17 11:37:08

On 15/02/2017 18:42, Phil Endecott via Boost wrote:
> 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.

There is a very poor but effective workaround if your application can
support long delays. Search for
documented, but it should be added.

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

Yes, but SysV shared semaphroes can't be placed in shared memory.

> 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

Good suggestion.

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

There are several algorithms, but the problem is placing them in shared
memory. See an adapter in:

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

Yes, but I really can't get time to implement it. The idea one would
support std::chrono and boost::chrono. Patches welcome ;-)



Boost list run by bdawes at, gregod at, cpdaniel at, john at