This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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: Consolidating the use of the atomic builtin functions of bits/atomic.h


On Mon, 22 Nov 2010, Ken Werner wrote:

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

If you want to consolidate things relating to libc targets, you should be 
using libc-alpha.  But since __sync_* have stronger barrier semantics than 
are needed for the glibc operations (which makes them unsuitable to use 
as-is for MIPS, for example, I think you should start by working with the 
people working on C++0x/C1x atomics support in GCC, defining what the 
relevant built-in functions should be and what library support should back 
them up when the hardware may not have all the required operations, so 
that there is a set of built-in functions usable for both <stdatomic.h> 
and glibc's internal atomic operations.

http://gcc.gnu.org/wiki/Atomic

-- 
Joseph S. Myers
joseph@codesourcery.com


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