Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2015-11-17 at 10:49 +0100, Florian Weimer wrote:
> On 11/16/2015 07:30 PM, Joseph Myers wrote:
> 
> >> What do I have to do if I want to add atomic sub-and-fetch with
> >> acquire-release semantics?  Should I simply use CAS instead?
> > 
> > I don't have advice on the specifics of what operations are or are not 
> > portably available in glibc, given the need to fall back to things other 
> > than __atomic_*.  But the general goal is to move glibc's internal atomics 
> > macros towards C11 semantics, while not necessarily being implemented in 
> > terms of __atomic_* on all architectures; if some architectures or generic 
> > fallbacks fail to follow the appropriate documented memory order for the 
> > glibc macro in question, those architectures or fallbacks should be fixed.
> 
> There is no documentation, so it is unclear if there is a bug. :)

The semantics of the new-style C11-like atomics that one should use in
new code or when fixing concurrent code are exactly the C11 semantics,
so are documented.

If you encounter cases where you need to transform from old-style to
C11-like atomics, and are perhaps wondering what the old code did and
why it was supposed to work, then this is just a reminder that you
should review the old code carefully and transform it to C11 so the
semantics are clear.  We had quite a few cases where older
synchronization code wasn't actually portable nor race-free, so one
shouldn't just blindly transform from old to new-style.  Also, you
should document uses of C11 atomics properly (eg, why a certain MO is
required/sufficient), so you will have to review it anyway :)

> One advantage of using <stdatomic.h> is that we can use published C11
> material as the documentation, and we do not have to write our own.

The same advantage holds for the C11-like atomics.  Using the C11 memory
model is the primary reason why we have them.  Whether we use exactly
the same interface is secondary, and there are other factors that we
need to consider there -- as long as we're using the same memory model,
all is good.