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

Subject: Re: [Boost-users] [Interprocess] hang locking p_hdr->m_mutex
From: David Byron (dbyron_at_[hidden])
Date: 2011-08-25 14:53:12

On 8/19/2011 11:21 PM, Ion Gaztañaga wrote:
> 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.

Instead of using a persistent integer on windows, how about CreateMutex 
Then if the mutex holder dies, the other side learns about it because 
WaitForSingleObject returns WAIT_ABANDONED.  But then it's not so 
important to learn that the other side is dead...just that we've got the 
mutex and it's OK to proceed.

At the moment I see two implementations in 
interprocess/sync/interprocess_mutex.hpp -- a posix one and 
emulation/mutex.xpp.

My understanding is that a process waiting on a posix interprocess_mutex 
wakes up (having taken ownership) if the owner process dies.  Is that 
right?  Adding an implementation for windows that behaves that way feels 
like a big bonus -- way better than hanging.

Is something like this feasible?  I'm fairly new to boost so I have a 
feeling creating a patch is going to be pretty slow going but but I'll 
take a crack if it would help.

Barring this, I'm struggling to come up with a safe way to use 
boost::interprocess::message_queue on windows (or any platform that uses 
the emulation interprocess_mutex really).  If anyone has any 
suggestions, I'd love to hear them.

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

That's useful information, but what I'm also curious about is whether 
the process waiting for the mutex wakes up or not.  Using the emulated 
interprocess_mutex, I'm not sure.  Because the waiting process still 
likely has a handle, I guess it hangs forever, yes?

Thanks for your help.

-DB