Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

["Peter Dimov" <pdimov at mmltd dot net>]

Phillip Jordan wrote:

> I'm also trying to work out thread-safe assignment semantics for the
> shared_ptr<>, but the lack of a 2-word compare-and-swap on some
> architectures makes this impossible without additional pointer
> dereferencing. Still better than a lock I suppose.

shared_ptr is not required to be atomic. That is, if you have

shared_ptr<X> px;

you can read it from multiple threads:

// T1

px2 = px;

// T2

px3 = px;

but you can't write to it from multiple threads:

// T1

px = px2;

// T2

px = px3; // undefined behavior, data race

An atomic reference-counted pointer is very hard to implement correctly, and 
an atomic shared_ptr is (to the best of my knowledge) impossible (without 
locks, of course).

Apologies if you know all this already; your mention of DWCAS made me think 
that you're trying to shoot for atomicity ("strong thread safety") instead 
of the usual and sufficient "basic thread safety". Unfortunately, the term 
"thread safe" doesn't have a single meaning and is used to denote different 
levels of thread safety in different contexts.