This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: atomic operations for shared_ptr ?
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Bronek Kozicki <brok at spamcop dot net>
- Cc: Federico Terraneo <fede dot tft at hotmail dot it>, libstdc++ at gcc dot gnu dot org
- Date: Sun, 25 Aug 2013 13:52:12 +0200
- Subject: Re: atomic operations for shared_ptr ?
- References: <5218F14F dot 9080804 at spamcop dot net> <CAH6eHdTX+Un55-xK6w4Qx-T8s2TT=KjPLYzW23EJFwswAqRuKg at mail dot gmail dot com> <52190267 dot 5010905 at spamcop dot net> <BLU0-SMTP12993E26F073F8C75358371F9480 at phx dot gbl> <5219ECF2 dot 1070009 at spamcop dot net>
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>>
> 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?
Cheers,
Oleg