Re: [Boost-users] shared_ptr and thread safety

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2007-08-06 09:49:43

Ok, just looking at the example will bring more light into your questions.

First non-safe scenario:
// thread A
p = p3; // reads p3, writes p

// thread B
p3.reset(); // writes p3; undefined, simultaneous read/write

Either thread B is executed before thread A, then you assign empty shared pointer in thread A (to
prior pointer deletion in thread B) OR thread A is executed before thread B, then a valid pointer
is assigned in B. Possible scenario here as well: Value of p3 is read, scheduler switches to
thread B; deletes pointer owned by p3; switches back to thread A and assignes invalid pointer
value to p (deletion of pointee can happen probably twice and it is also undefined what is in
memory at the point of assignment and what will be written later on...)

Other scenarios are pretty similar.

With Kind Regards,

Ovanes Markarian

On Mon, August 6, 2007 14:51, gast128 wrote:
> Dear all,
>
> it is already posted a dozen times, but still I do not get it. I understand
> that if you have a class, the shared_ptr will not make this thread safe.
> That's fair. Non const operations accessed by different threads should still
> be guarded (and probably their const versions then also).
>
> But what about the shared_ptr itself. From the doc's
> (http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety) I read that
> reading and writing to the shared_ptr object (not the pointee) is safe:
>
> 'A shared_ptr instance can be "read" (accessed using only const operations)
> simultaneously by multiple threads. Different shared_ptr instances can
> be "written to" (accessed using mutable operations such as operator= or reset)
> simultaneosly by multiple threads (even when these instances are copies, and
> share the same reference count underneath.)'
>
> However then a couple of examples are listed where both operator= and a dtor
> call are marked as undefined, and this is of course the most use (share a
> shared pointer over multiple threads and let them decide who finishes last,
> but this is then illegal?)
>
>>From the code I see that the ref counting is implemented through atomic inc's
> and dec's, and I would therefore expect that it is thread safe after all,
> since only the thread which makes the ref count 0 will be assigned the job
> of 'dispose', and the ref counting is thread safe.
>
> who can help this poor programmer...
>
> wkr,
> me
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>