This is the mail archive of the
mailing list for the libstdc++ project.
Re: basic_string atomicity
On 01/08/2012 07:50 AM, Gabriel Dos Reis wrote:
On Fri, Jan 6, 2012 at 8:12 PM, Jonathan Wakely<email@example.com> wrote:
Thats the danger. the __sync routines were suppose to be seq-cst unless
otherwise specified, and I believe the fetch_and_add family in
particular should have always been treated as seq-cst...
On 6 January 2012 14:34, David Edelsohn wrote:
Unfortunately the changes to __sync_fetch_and_add because of the C++11
memory model changes to GCC ALREADY HAVE CAUSED A REGRESSION that
affects libstdc++. G++ now produces worse code, at least for
architectures that can make a distinction among the various memory
We probably want to CC Andrew and Aldy here, as I can't speak for the
other libstdc++ maintainers but personally I usually try not to touch
the existing code using atomic ops unless they're broken, and even
then I prefer to ask an expert!
Andrew, Aldy, please see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 for the sync vs
lwsync change, and the thread starting at
I agree that we need to change std::string implementation for C++11
to move away from refcounting.
I also think that we need to unbreak libstdc++ on powerpc.
Hence I am leaning towards David's patch. The real question
is whether it does harm on other architectures that are less
"fine grained" than power.
We can change libstdc++ to use a less stringent memory model, but we'd
have to be sure that its correct for *all* platforms... ie, that
'exchange_and_add' is really acquire/release and not seq-cst sometimes.
I expect for the next release to go through everything and remove
all references to the old __sync routines and replace them with __atomic
Im not really familiar with the atomicity.h stuff, bkoz has been taking
care of that, maybe he can chip in here on what the model expected for
exchange_and_add and others really should be.
In any case, the patch shouldn't be using numbers for the memory model,
they should be using the CPP predefines like
__atomic_fetch_sub(__mem, __val, __ATOMIC_RELEASE);