Re: [Boost-users] [Interprocess] hang locking p_hdr->m_mutex

Subject: Re: [Boost-users] [Interprocess] hang locking p_hdr->m_mutex
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-08-20 02:21:14

El 20/08/2011 1:57, David Byron escribió:
> Except that the above code is in message_queue.hpp even in try_send or
> timed_send. It's in get_num_msg() for example. So short of modifying
> message_queue.hpp I'm not sure what to do.

Sorry, I didn't understand you. In those cases, the only solution would 
be to configure at compile time (macro or whatever) a maximum lock time 
and throw an exception just to notify that a deadlock might be ocurring. 
Detecting the dead of a mutex owner is not an easy task without kernel 
support.

> One thing that came to mind is always calling message_queue::remove on
> startup. I think that gets passed this problem, but may introduce some
> other complications if the two processes that use the message queue
> start and end at undefined times in an undefined order. I'm still trying
> to test this, but perhaps you can help by answering this question:
>
> If a process is waiting for the mutex like this:
>
> scoped_lock<interprocess_mutex> lock(p_hdr->m_mutex);
>
> what happens if another process removes the message queue?

The queue is removed (in windows, the name of the queue is changed so 
that no other connection succeeds and marked to be erased when the last 
handle is closed,

Ion