This is the mail archive of the 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


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

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