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 Monday, November 22, 2010 10:06:20 pm Joseph S. Myers wrote:
> 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.

Ok, I see. This seems to be a clean approach for the future. Thank you for 
pointing that out. So, I guess the described consolidation approach is not 
desired because there is something better on the horizon.
The method I described would not prevent MIPS or any other architecture from 
defining the low level macros using inline assembly as they do today. 
Currently the default fall back is a non-atomic C implementation. As some 
platforms already seem to prefer the __sync* primitives, I thought it would be 
nice to provide these as a fall back instead (even if they are not ideal) and 
only use the non-atomic C implemenation if nothing else is available.

Regards
Ken


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