Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Fri, Nov 11, 2016 at 5:13 AM, Torvald Riegel <triegel@redhat.com> wrote:
> These architectures seem to all use various sorts of emulation for
> compare-and-exchange operations (CAS).  If these emulations do not stop
> the world during a CAS, or do something else that prevents concurrent
> write operations to the same memory location as the CAS, then atomic
> store operations in glibc need to use a CAS to perform stores.
> Otherwise, concurrent stores can happen between the load(s) and the
> store that the CAS consists of.
>
> If your architecture is affected by this, then it may be possible that
> glibc's current concurrent code does not work correctly; this is because
> we may still have plain stores in places where atomic stores should be
> used.  Once we have completed the conversion to C11 atomics, all
> concurrent stores will go through atomic_store_*().
> See Chris Metcalf's patch for tilepro:
> https://sourceware.org/ml/libc-alpha/2016-11/msg00414.html


atomic-machine.h for arm was rewritten to use the __atomic builtins a
few years back. Thus if userland compiled these at architecture levels
less than the architecture levels where these could be inlined, the
emulation would be through calls to kernel helper pages. It is my
understanding the kernel helper routines if running on MP systems that
had the ldrex / strex instructions the kernel would use those to
implement CAS. Furthermore I don't know of any SMP systems that didn't
have the LDREX / STREX instructions thus I don't think that ARM is
affected by this. CC'ing Will and Catalin for a more definitive
answer.

Thanks,
Ramana
>
> If your architecture is not affected, I suggest adding a comment why
> that is not the case.
>