Subject: Re: [boost] [interprocess] locked mutex and process killed
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-03-24 13:31:06
Ion GaztaÃ±aga wrote:
> Vicente Botet Escriba wrote:
>> Edouard A. wrote:
>>> The answer to your question is "an exception will be thrown" since the
>>> will return "EOWNERDEAD".
>>> Generally speaking when a thread terminates while holding a mutex, the
>>> mutex is considered abandoned and shared resources protected by the
>>> are in an undetermined state. Hope you like quantum physics. ;)
>> if this is the case, what do you think about adding a kind of resource
>> manager that will ensure all the shared resources are released (and in
>> particular the interprocess::mutex are unlocked) on a cleanup phase just
>> before diing?
> There is no guarantee at all. POSIX does not guarantee EOWNERDEAD if you
> don't use robust mutexes, which is now an option in POSIX 2008 (O'll try
> to add it ASAP but adding robust mutexes has some interface problems)
> but is not mandatory.
> Adding a resource manager is not trivial, it needs to periodically check
> if processes are alive and that's not easy. Interprocess does not offer
> any guarantee that the underlying OS does not offer.
> Unsubscribe & other changes:
what kind of interface problems have adding robust mutexes?
Do you mean that you plan to use robust mutex when available? Should this be
My initial question was, on which state a locked interprocess mutex is when
the owning process dies (with the current implementation)? is it locked?
unlocked? it is undefined?
How an application can recover from this situation?
-- View this message in context: http://www.nabble.com/-interprocess--locked-mutex-and-process-killed-tp22671125p22685302.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk