on Mon Aug 06 2007, gast128
Ovanes Markarian
writes: 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...) ... Ovanes Markarian
This should mean that shared_ptr is not at all thread safe, as in above race condition.
No, it's exactly "as threadsafe as int." Believe it or not, it's possible for things to be even less threadsafe when shared data (e.g. a reference count) is involved. For example, with p1 and p2 both shared_ptr<T>, pre-thread: p1 = p2 thread A: p1.reset() thread B: p2.reset() is safe. That sequence would not be safe with a naive reference-counted pointer that was totally unaware of thread safety. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com