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: Torvald Riegel <triegel at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Tue, 16 Sep 2014 18:46:13 +0200
- 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> <Pine dot LNX dot 4 dot 64 dot 1409161603350 dot 18320 at digraph dot polyomino dot org dot uk>
On Tue, 2014-09-16 at 16:06 +0000, Joseph S. Myers wrote:
> 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).
Agreed. I think we should by default not expect more than pointer-sized
atomic ops. If a particular concurrent algorithm implementation really
needs more, it's often more efficient to use a solution specific to that
algorithm (e.g., exploiting monotonicity in the values or such) rather
than try to rely on kernel helpers or locks for that.