Re: [boost] [interprocess] locked mutex and process killed

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
>>> call
>>> will return "EOWNERDEAD".
>>>
>>> Generally speaking when a thread terminates while holding a mutex, the
>>> mutex is considered abandoned and shared resources protected by the
>>> mutex
>>> 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.
> 
> Best,
> 
> Ion
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 

Hi,

what kind of interface problems have adding robust mutexes?

Do you mean that you plan to use robust mutex when available? Should this be
an option?

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?

Best,
Vicente

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