Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS

[Florian Weimer <fweimer at redhat dot com>]

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

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.

> We have, for example, atomic_fetch_add_* for various memory orders - if 
> one of those does the wrong thing in some cases, that needs to be fixed.  
> Older macros whose memory orders are unclear should be phased out.

That would be progress, yes.

>> If this is too much work, would it be easier to compile libatomic before
>> glibc instead?
> 
> libatomic depends on pthread.h and -lpthread.  And there's no 
> -static-libatomic option.  I don't think using libatomic in glibc is 
> practical.

Which architectures are supported by glibc, have SMP implementations
(even EOLed ones), but do not have a useful CAS?  Even PA-RISC has a CAS
in libgcc (with kernel assist).  Plain i386 is already unsupported for
SMP, I think, although there were some SMP systems at one point.

Part of the problem here, I think, is that it is so hard to get accurate
data on non-mainstream architectures.  This makes it difficult to
determine the design space.

I really, really want us to avoid maintaining multiple, parallel
implementations of atomics across the entire toolchain. The cost of that
is simply too high.

Florian