Why does boost's interprocess_condition deadlock in notify_one?

问题

This is a link to an MCVE that demonstrates the deadlock

It contains five parts:

1. SharedEvent is an implementation of an AutoResetEvent that is stored in shared memory.

2. CreatedSharedEvent creates a named shared memory object in which a SharedEvent is allocated. It provides an accessor method that returns a reference to the SharedEvent.

3. OpenedSharedEvent opens a named shared memory object in which a SharedEvent has already been allocated. It also provides an accessor method that returns a reference to the SharedEvent.

4. A server console application that creates a SharedEvent using a CreatedShareEvent and sets the event every 2 seconds. It prints a message every time the event is set.

5. A console application that opens the shared event using an OpenedShareEvent and waits on the event in a loop. It prints a message every time the wait call returns.

To reproduce the problem:

1. Run the server. Observe the messages printed every 2 seconds.

2. Run the client. Observe the messages printed every 2 seconds.

3. Close the client. Observe that the server ceases to print messages. It is blocked in interprocess_condition::notify_one()

回答1:

The cause of the problem is the same as described here:

This use of boost interprocess cannot be used in a situation where a process might crash and still be holding the lock.

I will post a different question to see if anyone has discovered a good replacement for boosts condition_variable and interprocess_mutex.

来源：https://stackoverflow.com/questions/44991510/why-does-boosts-interprocess-condition-deadlock-in-notify-one