This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atomic operations for shared_ptr ?


-----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-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]