Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1667: Using managed_shared_memory condition variables on Win32 can lead to deadlock on crash
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-03-04 01:50:05
#1667: Using managed_shared_memory condition variables on Win32 can lead to
deadlock on crash
--------------------------------------+-------------------------------------
Reporter: joe1chen_at_[hidden] | Owner: igaztanaga
Type: Bugs | Status: reopened
Milestone: Boost 1.36.0 | Component: interprocess
Version: Boost Development Trunk | Severity: Showstopper
Resolution: | Keywords:
--------------------------------------+-------------------------------------
Changes (by anonymous):
* status: closed => reopened
* resolution: invalid =>
Comment:
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?
--
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1667#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:57 UTC