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

Subject: Re: [Boost-users] [Interprocess] deadlocking race condition in emulation interprocess_condition.hpp
From: Young, Zachariah L (zachariah.l.young_at_[hidden])
Date: 2009-09-16 23:20:29

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_at_[hidden]'
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_cast<boost::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_at_[hidden]]
Sent: Wednesday, September 16, 2009 5:39 AM
To: boost-users_at_[hidden]
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_cast<boost::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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users