Re: [Boost-users] [Interprocess] Deadlock when using interprocess_semaphore

Subject: Re: [Boost-users] [Interprocess] Deadlock when using interprocess_semaphore
From: Derek Kivi (derek.kivi_at_[hidden])
Date: 2009-03-06 12:37:51

> Derek Kivi wrote:
> > We are seeing a deadlock when making use of the
interprocess_semaphore.
> >
> > In our case we have two running threads where the first thread is
stuck
> > waiting at a timed_wait() call while the second thread is stuck at a
> > post() call.
> >
> > Also, a symptom we are seeing is that the lock value is set to 1
before
> > both threads try to acquire the lock -- we think this is why the
threads
> > get stuck in the lock calls.
> >
> > We are running 1.36 at the moment. Have there been any fixes in 1.37
or
> > 1.38 that might help us to avoid this problem?
> 
> I don't remember any fix but I can't be sure. Thanks for the report,
but
> I'm afraid this will be difficult to catch :-(
> 
> > Thanks,
> > Derek
> 
> Regards,
> 
> Ion

Hi Ion,

Thanks for your reply.

A co-worker has looked into this a bit more and believes that he has
found the source of the problem. He thinks that this is a bug in
interprocess_condition::do_timed_wait().

Here is his description to me:

----------------------------------
In the code there's one hole where it doesn't unlock the m_enter_mut
mutex before it leaves do_wait. This is in the following code:

//Notification occurred, we will lock the checking interprocess_mutex so
that
//if a notify_one notification occurs, only one thread can exit
//---------------------------------------------------------------
InternalLock lock;
if(tout_enabled){
        InternalLock dummy(m_check_mut, abs_time);
        lock = detail::move_impl(dummy);
}
else{
        InternalLock dummy(m_check_mut);
        lock = detail::move_impl(dummy);
}

if(!lock)
{
        return false;
}

The return false; is the problem here. It's at the point where
m_check_mut can't be locked that this routine exits without unlocking
m_enter_mut, and thus causing the deadlock.

Trivially, this can be fixed by executing m_enter_mut.unlock(); before
returning.
----------------------------------

Ion, do you think that it is okay to add an m_enter_mut.unlock() call
before returning? Will this cause some other problem in another part of
the code?

Thanks for your help,
Derek

-- 
Derek Kivi
Senior Software Developer
QuIC Financial Technologies Inc. 
Office: [phone] 
Mobile: [phone] 
derek.kivi_at_[hidden]
Risk. Managed.
www.quic.com 
Confidentiality Notice: The information transmitted is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the email and any related material from any computer.
ver. QuIC 0707