Re: [Boost-users] shared_lock( ) causes Segmentation Fault in CentOS 5.5 x64?

Subject: Re: [Boost-users] shared_lock( ) causes Segmentation Fault in CentOS 5.5 x64?
From: Zap (zippo.fire_at_[hidden])
Date: 2011-03-15 22:57:20

Howard Hinnant <howard.hinnant <at> gmail.com> writes:
> > It looks like you are locking your structure in "read mode" and then 
writing to it:
> 
> >   boost::shared_lock<boost::shared_mutex> lock(rwMutex);
> >   for(boost::unordered_set<int>::iterator it=tablePush[pair<string, string>
> > (type, code)].begin();it!=tablePush[pair<string, string>(type, code)].end
> > ();it++){  
> >      flag=true;
> >      des->push_back(*it);
> >   }
> 
> If you want to lock it in write mode do this:
> 
> boost::unique_lock<boost::shared_mutex> lock(rwMutex);
> 
> -Howard
> 

Hi Howard,

Did you mean des->push_back(*it) in this method?
actually in my program, 
there is an independent fdList(which called "des" in the method) 
in every thread,
in other words every thread have its own fdList and just reference into
this method when they calls this method. In my opinion,
if every fdList is declared independently in each thread, 
they won't take effect each other when they are referenced into this method
and ask to push_back what this method found in the loop to them.

did this also have to use write lock?
I thought it's still read mode(If I'm incorrect please tell me)
(this method push_backs what it found into every fdList every thread owned,
 they didn't push_backs in the same "global" fdList at the same time. This 
 method just "read" the same tablePush without write it,
 that's why I think it's just in read mode..)

Or did you mean the other place in my code is incorrect?

Thank you

Zap