Re: [Boost-users] [Interprocess] deadlocking race condition in emulation interprocess_condition.hpp

17 Sep 2009

      Actually, why lock the m_check_mut at all?

Why not delete that whole thing and remove the m_check_mut from the class entirely, as it apparently exists only to synchronize the get and set of m_command on line 177 (before any edits), which is an atomic compare-and-set (ie, doesn't need synchronization)?

-Zach

-----Original Message-----
From: Young, Zachariah L 
Sent: Wednesday, September 16, 2009 8:06 PM
To: 'boost-users@lists.boost.org'
Subject: RE: [Boost-users] [Interprocess] deadlocking race condition in emulation interprocess_condition.hpp

Hello Ion,

I have been looking at this code for awhile now and I am convinced that my original suggestion is not adequate.  I am now getting deadlock with 4 waiters doing timed_waits on a tight timeout (now + 8ms) while using a single notify_all.  I am wondering why abs_time is taken into consideration at all in the else clause, since the if clause is meant to handle the timeout case.

I believe that 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 = boost::interprocess::move(dummy);
         }
         else{
            InternalLock dummy(m_check_mut);
            lock = boost::interprocess::move(dummy);
         }

         if(!lock){
            detail::atomic_dec32(const_castboost::uint32_t*(&m_num_waiters));
            timed_out = true;
            unlock_enter_mut = true;
            break;
         }
         //---------------------------------------------------------------

Should be changed to this:

         //Notification occurred, we will lock the checking interprocess_mutex so that
         //if a notify_one notification occurs, only one thread can exit
        //---------------------------------------------------------------
         InternalLock lock(m_check_mut);
         //---------------------------------------------------------------

I do not see the point of the abs_time consideration or the lock check.

Am I mistaken?  Am I missing something?

-Zach

-----Original Message-----
From: Ion Gaztañaga [mailto:igaztanaga@gmail.com]
Sent: Wednesday, September 16, 2009 5:39 AM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [Interprocess] deadlocking race conditionin emulation interprocess_condition.hpp

Young, Zachariah L escribió:
...
My straightforward idea is to add the following line at line 172 of
boost/interprocess/sync/emulation/interprocess_condition.hpp:
if(!lock){
detail::atomic_dec32(const_castboost::uint32_t*(&m_num_waiters));
            timed_out = true;
            unlock_enter_mut = true;
            break;
         }
I think you are right. The count should be decremented because this thread will exit the wait logic .

thanks,

Ion
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users