Re: [RFC][PATCH 0/5] arch: atomic rework

From: Will Deacon
Date: Mon Feb 17 2014 - 14:20:13 EST


On Mon, Feb 17, 2014 at 06:59:31PM +0000, Joseph S. Myers wrote:
> On Sat, 15 Feb 2014, Torvald Riegel wrote:
>
> > glibc is a counterexample that comes to mind, although it's a smaller
> > code base. (It's currently not using C11 atomics, but transitioning
> > there makes sense, and some thing I want to get to eventually.)
>
> glibc is using C11 atomics (GCC builtins rather than _Atomic /
> <stdatomic.h>, but using __atomic_* with explicitly specified memory model
> rather than the older __sync_*) on AArch64, plus in certain cases on ARM
> and MIPS.

Hmm, actually that results in a change in behaviour for the __sync_*
primitives on AArch64. The documentation for those states that:

`In most cases, these built-in functions are considered a full barrier. That
is, no memory operand is moved across the operation, either forward or
backward. Further, instructions are issued as necessary to prevent the
processor from speculating loads across the operation and from queuing stores
after the operation.'

which is stronger than simply mapping them to memory_model_seq_cst, which
seems to be what the AArch64 compiler is doing (so you get acquire + release
instead of a full fence).

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/