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: Pekka Seppänen (pekka.seppanen_at_[hidden])
Date: 2012-07-19 09:59:21

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).

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.

-- Pekka