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

Subject: Re: [Boost-users] [Interprocess] Deadlock when using interprocess_semaphore
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-03-07 05:13:41

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

Thanks for the report. I'll look at it in detail ASAP.

Best,

Ion

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

Sorry, I couldn't see it clearly. Yes, there is definitely something 
wrong. In theory the code should have only a single exit point but 
recent changes to add timeouts in internal mutexes seem to have 
introduced the bug. Could you do a little test changing

"return false;"

with

unlock_enter_mut = true;
break;

?

Then I think code should have a single exit point unlocking 
m_enter_mutex when it's needed. Thanks again for spotting the bug.

Regards,

Ion