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


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