This is the mail archive of the
mailing list for the glibc project.
Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>, Chung-Lin Tang <chunglin_tang at mentor dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, catalin dot marinas at arm dot com, will dot deacon at arm dot com
- Date: Fri, 11 Nov 2016 11:33:38 +0000
- Subject: Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On Fri, Nov 11, 2016 at 5:13 AM, Torvald Riegel <email@example.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:
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
> If your architecture is not affected, I suggest adding a comment why
> that is not the case.