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