basic_string atomicity

[Jonathan Wakely]

On 5 January 2012 20:17, David Edelsohn wrote:
>>
>> I thought the __sync builtins were always full barriers too?
>
> The description was not that precise, and they were not always
> implemented as SEQUENTIAL CONSISTENCY.

OK.

>>> 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.
>
> What consistency model does libstdc++ require?  __sync_fetch_and_xxx
> has become more heavy-weight and even the earlier memory model
> probably was unnecessarily expensive for its usage in libstdc++ based
> on our analysis for POWER.

std::string is required by C++11 to be not reference-counted, so
changing the details of the ref-counted implementation isn't a high
priority if we're going to replace it anyway (although we will retain
a ref-counted COW string as __gnu_cxx::__rc_string.)

I'm not sure what the memory ordering requirements are for
std::string, I think decrementing the count to zero needs to
synchronise with deallocating the memory, but I'm not sure about
increments.