This is the mail archive of the
mailing list for the libstdc++ project.
Re: atomic operations for shared_ptr ?
- From: Bronek Kozicki <brok at spamcop dot net>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Sat, 24 Aug 2013 20:34:42 +0100
- 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> <CAH6eHdQOQuWv0tsZPc=6nnLs0duuObtXKNQar_mZjzLR1GoXDQ at mail dot gmail dot com>
On 24/08/2013 20:26, Jonathan Wakely wrote:
On 24 August 2013 19:58, Bronek Kozicki wrote:
On 24/08/2013 18:51, Jonathan Wakely wrote:
On 24 August 2013 18:45, Bronek Kozicki wrote:
what are the current plans for supporting atomic_* free functions for
shared_ptr, as defined in C++11 (20.6.2 "Header <memory> synopsis")?
would be very useful for passing shared_ptr objects between threads, esp.
there are multiple readers and single writer.
I've been thinking about it recently and am probably just going to
implement it with a single global mutex used for all shared_ptr
erm, but that would be even worse than using mutexes as in my example code
It would perform badly, yes, but would mean the feature would not stay
Perhaps spinlock could be implemented without breaking ABI? Please check
performance comparison figures at the end of this document:
Here they suggest use "a spinlock pool keyed on a hash of the address of
the instance", although perhaps a special value of _M_ptr might be used
instead (that value being the address of _M_ptr itself).
Alternatively, a single bit might be sacrificed in existing data members
although that would most likely impose performance penalty on most
common uses, so I'm not really advocating it.