Transition to C11 atomics and memory model

[Torvald Riegel]

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.