Boost logo

Boost Users :

From: Patel Priyank-PPATEL1 (priyankpatel_at_[hidden])
Date: 2006-05-15 09:01:00


Thanks.. Let me try that out. Also, I will put check if mutex acquire
method returns success or not during
addition only than and than I will go ahead and add procedure in pool.
 
Thanks
Priyank
 

________________________________

From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Kobi
Cohen-Arazi
Sent: Friday, May 12, 2006 11:33 PM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] [multi_index] thread safety

Hi,

comments below

On 5/12/06, Patel Priyank-PPATEL1 <priyankpatel_at_[hidden]> wrote:

        Hi Joaquin,
        
        I have to use actually two or more threads on procedure pool. I
start seeing same
        Problem when I have three/four threads working on same procedure
pool. I tried to introduce mutex (ACE_Guard) but still having problems
in execution in one/two minute of execution.
        Seems I am guarding every method that is used by container.
Anything wrong with the
        Following code?
        
        
        int Procedure_Pool::add_by_id(Procedure * _procedure)
        {
                LD_TRACE("Procedure_Pool::add_by_id");
                ACE_ASSERT(_procedure != 0);
                ACE_DEBUG((LM_DEBUG, "ADDING %d\n", _procedure->id()));
        
                if (find_by_id(_procedure->id()) == 0) {
                        ACE_Guard<ACE_Mutex> guard(mutex_);
                        {
                                // procedure not found
                                procedure_by_id_.insert(_procedure);
                        }
                        // debug info
                        ACE_DEBUG((LM_DEBUG, "Added procedure : %d \n",
_procedure->id()));
                        // return success
                        return 0;
                } else {
                        // error
                        ACE_ERROR((LD_ERROR "%N:%l Error in adding
procedure : %d \n", _procedure->id()));
                        // return failure
                        return -1;
                }
        
        }
        
        int Procedure_Pool::remove_by_id(Procedure * _procedure)
        {
                LD_TRACE("Procedure_Pool::remove_by_id");
                ACE_ASSERT(_procedure != 0);
                ACE_DEBUG((LM_DEBUG, "REMOVING: %d \n",
_procedure->id()));
                if (find_by_id(_procedure->id()) != 0) {
                        ACE_Guard<ACE_Mutex> guard(mutex_);
                        {
                                // procedure found
        
procedure_by_id_.erase(_procedure->id());
                        }
                        ACE_DEBUG((LM_DEBUG, "Removed procedure : %d
\n", _procedure->id()));
                        return 0;
                } else {
                        ACE_ERROR((LD_ERROR "%N:%l Error in removing
procedure : %d \n", _procedure->id()));
                        return -1;
                }
        
        }
        
        Procedure * Procedure_Pool::find_by_id(int _id)
        {
                LD_TRACE("Procedure_Pool::find_by_id");
                ACE_Guard<ACE_Mutex> guard(mutex_);
                {
                        Procedure_By_Id::iterator it =
procedure_by_id_.find(_id);
                        if (it != procedure_by_id_.end()) {
                                ACE_DEBUG((LM_DEBUG, "%N:%l Found
procedure for id: %d \n", _id));
                                return *it;
                        }
                }
                ACE_DEBUG((LM_DEBUG, "%N:%l Not able to found procedure
for id: %d \n", _id));
                // return null
                return 0;
        }

Yes. There is a small theoretical problem with your code. A possible
race condition. you tried to find_by_id, using mutex, than release that
mutex and reacquire it for erase. That's a possible race condition. The
"find" until the "erase" must be atomic. At least IMHO.

Kobi.



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net