Using managed_shared_memory condition variables on Win32 can lead to deadlock on crash

[joe1chen@…]

The problem is that on Win32 the conditon variable implementation is emulated. The problem ultimately lies with the interprocess_mutex used by the condition variable. If an application crashed while holding the mutex, then other applications trying to acquire the mutex will wait indefinitely.

[Ion Gaztañaga]

The possibility of deadlock is inherent to the use of process-shared resources. The same can happen for inter-thread mutexes if a thread dies. Some operating systems can unlock the mutex if the process holding the mutex dies but in that case, the data to be protected to the mutex is likely to be corrupted.

POSIX does not mandate any deadlock so in many operating systems we'll get deadlocks even if using native mutexes and condition variables.

[anonymous]

I understand that POSIX does not mandate that mutexes are robust. When a mutex owner dies without releasing, other mutex waiters may stay deadlocked forever. However, this problem may be mitigated with the use of timeouts.

i.e. pthread_mutex_timedlock pthread_cond_wait

If I have a condition variable that is waiting with a timeout and the thread that is holding the mutex dies, the timeout should still allow the blocking thread to continue. At this point at least the thread can do something to try to recover (whether or not that attempt works or not is another story).

In the case of interprocess on win32, even timeouts are of no use. For instance, I define a named_condition and a named_mutex and then use timed_lock and timed_wait. When the process holding the lock dies, the threads using the timeouts are still deadlocked. The threads are not even given a chance to recover despite the use of timed_lock and timed_wait.

You may still argue that even pthread_mutex_timedlock is not universally supported (i.e OS X Leopard). However, it it really a shame that this issue is a showstopper for us because boost interprocess is a pretty slick library.

We are developing a browser plugin and another application that talk to each other via shared memory. As we all know, browsers are notorious for crashing depending on the kinds of plugins you have installed an all, so we don't really have any way of making the browser more crash-resistant. Without some way to recover from crashes, we would probably end up using the native implementations on each platform, which do offer some form of timeout/crash recovery.

If you still feel this is not a bug or is by design, perhaps consider this an enhancement request?

[Ion Gaztañaga]

Ok. I could try to use timed mutexes inside the condition variable implementation to see if that helps.

Let's put it as a feature request. Your browser example was quite convincing.

[Ion Gaztañaga]

Because of lack of time and resources, this feature won't be implemented. Robust mutex support will have to wait indefinitely.