Consolidating the use of the atomic builtin functions of bits/atomic.h

[Ken Werner <ken at linux dot vnet dot ibm dot com>]

Hi,

Currently most of the platforms supported by glibc are using either non-atomic 
C code (glibc/bits/atomic.h) or inline assembly to implement the low level 
atomic_*/__arch_* macros used by include/atomic.h. However, it looks like this 
is something that can be left to the compiler. Platforms like i486, x86_64, 
ia64 and arm seem to prefer the atomic builtin functions (__sync*) provided by 
GCC and use the hard coded inline assembly as a fall back only. Therefore I'm 
wondering if it's desired to consolidate the use of the atomic builtin 
functions.

I think there are several ways to achieve this. For example:
A) Create sysdeps/generic/atomic.h which uses the atomic builtins if they are 
available/suitable and else includes <bits/atomic.h>. Change the platform 
specific bits/atomic.h header files to include <sysdeps/generic/sysdep.h> if 
desired/required.

B) Rename all the existent platform specific bits/atomic.h header files to 
bits/atomic_arch.h. Change glibc/bits/atomic.h (the generic bits/atomic.h) to 
check if the atomic builtins are available. If so, just use them, otherwise 
include <bits/atomic_arch.h> to fall back on what the platform provides.

So the default priorities would be:
  1) use the builtin functions provided by the compiler if they are 
available/suitable
  2) otherwise use the inline asm provided by the platform
  3) fall back to the non-atomic C implementation
A platform should easily be able to override the default priorities. And the 
change should be minimally invasive to the existent code.

Does this sound reasonable?
Any thoughts/comments are much appreciated.

Regards
Ken