This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: ARM 64 bit atomics
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Gilbert <david dot gilbert at linaro dot org>
- Cc: libc-ports at sourceware dot org
- Date: Wed, 29 Jun 2011 19:45:04 +0000 (UTC)
- Subject: Re: ARM 64 bit atomics
- References: <BANLkTinK9RwufUyGUzRWQ4HV8a8XXbMy+Q@mail.gmail.com>
On Wed, 29 Jun 2011, David Gilbert wrote:
> 2) But if that's so trivial why do the other sizes in that atomic.h
> also not just
> let gcc produce the fallback routines rather than have their own implementation?
The code predates the libgcc implementation, which in turn is older than
the support for doing the operations inline, and it's possible there is
some performance impact to going via library calls when using the kernel
helpers rather than NPTL calling the helpers directly with inline assembly
(this should be benchmarked, however).
> 3) Would a 64bit implementation actually get called via libc? I can't see any
> uses within libc of greater than 32bits, and I can't see where these calls are
> exposed to the users of libc except by things like pthread' - so is
> there any point
> adding the 64bit __arch_compare_and_exchange_val_64_acq to libc?
This is not exposed to users of libc. There is no point in adding
versions for any type sizes that currently produce link errors because the
absence of such link errors when building libc/libpthread shows they are
not used.
> 4) Are there any stricter definitions of the semantics of the atomic
> calls used inside
> glibc - i.e. what barriers should exist when?
I don't know definitions beyond those implicit in the names of the macros.
> 5) When gcc generates a fallback (for an ARM earlier than ARMv6k) it ends up
> using a kernel helper; but it needs to check that the kernel version
How do these kernel helpers work? What precedent is there on other
architectures for providing any support, kernel-assisted or otherwise, for
64-bit atomic operations where not native on the hardware?
Note that C1X requires atomic operations on types of any size -
structures, for example - with the assumption that locks (based on hashes
of the address, maybe) will be used implicitly (and facilities in
stdatomic.h to report whether operations on a given object will be
lock-free). If other architectures without native 64-bit atomics end up
using some implicit locking scheme for 64-bit atomics we don't want ARM to
do something different from all other architectures.
--
Joseph S. Myers
joseph@codesourcery.com