This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Transition to C11 atomics and memory model
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Tue, 16 Sep 2014 16:06:00 +0000
- Subject: Re: Transition to C11 atomics and memory model
- Authentication-results: sourceware.org; auth=none
- References: <1410719669 dot 4967 dot 160 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1409151641570 dot 16736 at digraph dot polyomino dot org dot uk> <1410809263 dot 4967 dot 221 dot camel at triegel dot csb>
On Mon, 15 Sep 2014, Torvald Riegel wrote:
> > * In some cases those macros are defined by GCC even though the operations
> > are out of line in libgcc. On PA the HAVE_sync_compare_and_swap* macros
> > are defined in pa-linux.h to cause __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* to
> > be predefined; for Tile GCC has special target-specific code to define
> > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_*. Do we believe such out-of-line libgcc
> > versions will work in glibc, and is it preferable to use them or inline
> > asm? (My guess is that they might work except for cases such as the
> > 64-bit ARM atomics with references to libc interfaces.)
>
> I believe they should work from a correctness perspective, but might
> have a slight performance disadvantage. I'm not sure I understand the
> ARM case you mention.
The 64-bit ARM atomics (linux-atomic-64bit.c) rely on kernel helpers that
are only available in some kernel versions and involve a function called
at startup to test for availability of those helpers and call __write /
abort if not available.
I don't know if that would work in all places where glibc uses atomics,
but I think we should avoid the issue by making sure not to use 64-bit
atomics at all on 32-bit platforms (and hopefully ensure that such atomics
produce a compile / link failure if used).
--
Joseph S. Myers
joseph@codesourcery.com