This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Consolidating the use of the atomic builtin functions of bits/atomic.h
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ken Werner <ken at linux dot vnet dot ibm dot com>
- Cc: libc-ports at sources dot redhat dot com
- Date: Mon, 22 Nov 2010 21:06:20 +0000 (UTC)
- Subject: Re: Consolidating the use of the atomic builtin functions of bits/atomic.h
- References: <201011222038.32524.ken@linux.vnet.ibm.com>
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