This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: atomic operations for shared_ptr ?
- From: Federico Terraneo <fede dot tft at hotmail dot it>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sun, 25 Aug 2013 16:28:27 +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>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/25/2013 01:39 PM, 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.
I know that. Isn't this thread about implementing atomic_load and
atomic_store?
>
> Trouble implementing those is that, in the typical implementation
> of shared pointer with reference count (both boost and libstdc++
> happen to be such), two pointers have to be updated atomically: one
> is a pointer to actual data (_M_ptr in shared_ptr here) and the
> other is pointer to reference counters (_Sp_counted_base<_Lp>*
> encapsulated in _M_refcount in shared_ptr here). Since changing the
> object layout would break ABI, we are not at freedom to change
> this, even if it made some efficient lockfree algorithm available.
> The implementation of atomic_load, atomic_store etc. has to ensure
> that, once one data member (eg _M_ptr) has been read or updated,
> the other (eg _M_refcount) will be read (or updated) in state
> consistent with the first one.
I may well be missing something, but isn't this the kind of problem
that the "atomic increment and fetch" algorithm in the article solves?
Simply quoting the aticle: "In RCP terms, it atomically copies the
reference out of memory, then increments the counter of the referent.
This has to be done atomically to avoid various race conditions. For
example, one thread may read the reference, another overwrites it and
deletes the old value (the one the first thread just read), and then
the first thread increments the counter of the now-defunct object,
which is bad."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSGhSHAAoJECkLFtN5Xr9fqLYH/RdNQFdkdOwTauLuvZfzDHnq
2LRY3Yi1JhOrGK2s2QbcXBXVkSPsiNc/JloAfy/oFpUH+PrOPyMNhwQbMVYHTnyr
OMF63ZdQNGjw/m7veR5JKzAuxT+drajPp3egeQVrHGiyf5itSFm0fbw3aCK6MNA3
lO9wEHjdGfwfS6KYofOCcNwcEDXYocbWaJ/IVjRWvEPJCXtHy0ajqvP4dAVvibEI
Zn6V95WMJU7Ai1tUswyk38YdiUK2f2ziSnOi9/f+m318Sn1ArOj598yFh1WBGJBp
mGhmfgGerJc2c4YHq4ngHdxLZPfrcyCHNM00yY972+QBEn51axxrssclTe5yLyg=
=I2W9
-----END PGP SIGNATURE-----