Re: [Boost-users] [interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr

Subject: Re: [Boost-users] [interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr
From: Gaetan Gaumer (gaetan.gaumer_at_[hidden])
Date: 2012-07-19 11:48:05

2012/7/19 Pekka Seppänen <pekka.seppanen_at_[hidden]>

> On 19.7.2012 16:07, Gaetan Gaumer wrote:
> > Hello Ion a others interprocess guru,
> > I'm currently using an interprocess::vector storing
> intreprocess::weak_ptr to
> > data.
> > Sometimes after adding a shared_ptr to my vector with push_back, the
> weak_ptr
> > stored at the end of the vector is not
> > the one I just inserted, but a copy of a previously inserted weak_ptr.
> >
> > For examples the code below :
> > void addData (const SharableDataTypes<Data>::SharedPtrType & PData){
> > dataWPVector.push_back(PData);
> > if (dataWPVector.rbegin()->lock()->getObjectId() !=
> PData->getObjectId()){
> > std::cerr << "After pushback in dataWPVector vector last elem Id=" <<
> >  dataWPVector.rbegin()->lock()->getObjectId()
> >                          << " added cable Id =" << PData->getObjectId()
> <<
> > std::endl;
> > }
> > }
> >
> > spills the trace :
> > "After pushback in  dataWPVector  vector last elem Id=50332165 added
> elem Id
> > =352322053"
> > which should obviously not happen.
> >
>
> Hi.
>
> As you are using IPC (and the sample code doesn't actually reproduce the
> problem, as you said), I'm assuming you running that particular piece of
> code
> in a multi-thread/process environment (and did see some pthread traces
> there).
>
>
We do  are in a multi-thread/multi-process environment but in this
particular case, this vector
is filled by only one thread in one process. The commented trace was here
only to be sure of that.

> If so, you've simply forgotten to add a synchronization mechanism to your
> code. Multiple writers, multiple readers; Things like that happen as the
> code
> is not executed atomically and the other process (or thread) happens to
> write
> data to vector between the push_back() and rbegin().

> Perhaps the resize operation happens to take so much time, that it only
> happens then. If my guess was correct, simply (allocate a shared mutex, )
> acquire an exclusive lock when you are writing and a sharable lock if
> you're
> only reading data.
>
>
I already thought about it but that's not the case here, all our calls to
addData() are already protected
by some interprocess mutexes and interthread mutexes which work well with
other structures.

-- Pekka
>

Cheers,
Gaëtan