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: basic_string atomicity


On 5 January 2012 19:45, David Edelsohn wrote:
> Libstdc++ basic_string ultimately uses the GCC builtin
> __sync_fetch_and_add for atomicity:
>
> #include <ext/atomicity.h>
> ? ? ? ? ? ?__gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
>
> The GTHREAD path in atomicity.h is:
>
> ?__atomic_add_dispatch(_Atomic_word* __mem, int __val)
> ?{
> ? ? ?__atomic_add(__mem, __val);
> ?}
>
> ?static inline void
> ?__atomic_add(volatile _Atomic_word* __mem, int __val)
> ?{ __sync_fetch_and_add(__mem, __val); }
>
> With the addition of C++11 memory model, this builtin now performs
> heavy-weight, full barrier SEQUENTIAL CONSISTENCY semantics.

I thought the __sync builtins were always full barriers too?

> What memory model is required? ?It seems like the context for the code
> expects something closer to ACQUIRE semantics.
>
> I opened a GCC Bugzilla about the change in __sync_fetch_and_xxx
> semantics, but it appears that libstdc++ internally should use the new
> __atomic_fetch_add() builtin with more precise semantic intentions.

Yes, eventually.  Similarly for shared_ptr.


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