This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Nov 2015 10:49:00 +0100
- Subject: Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS
- Authentication-results: sourceware.org; auth=none
- References: <5649F832 dot 7000001 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511161758300 dot 30498 at digraph dot polyomino dot org dot uk> <564A1C64 dot 8010008 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511161825030 dot 30498 at digraph dot polyomino dot org dot uk>
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