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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users