Re: atomic operations for shared_ptr ?

[Bronek Kozicki <brok at spamcop dot net>]

On 25/08/2013 12:52, Oleg Endo wrote:
> On Sun, 2013-08-25 at 12:39 +0100, Bronek Kozicki wrote:
> > The problem is with accessing the shared_ptr at the same moment when it
> > is being reset by another thread, to a new pointee. This is not
> > guaranteed to be thread-safe and thus either separate synchronization is
> > needed, or one has to use atomic_load, atomic_store etc. overloads for
> > shared_ptr, if they are implemented.
>
> So effectively this is about std::atomic<std::shared_ptr<T>>

in a sense. There is no such specialisation of std::atomic, but there 
are free functions overloads with the same functionality as for other 
atomic types. You can see 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2674.htm for 
rationale.

> > Actually, our problem can be easily solved on architectures with
> > optimistic synchronisation primitives (since they enable atomic updates
> > of multiple memory locations), but currently only one processer type has
> > the necessary instructions, it is Intel TSX (only some processors of
> > Haswell family). Before this becomes more popular (and supported by gcc,
> > e.g. via intrinsics) we simply need a way to efficiently lock _M_ptr and
> > _M_refcount before reading or writing those inside implementation of
> > atomic_load, etc. overloads for shared_ptr.
>
> Just for my understanding, on targets that use 32 bit pointers and have
> a 64 bit atomic (compare and) exchange, that would be a no-brainer,
> wouldn't it?

it would be simpler, yes.


B.