This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM 64 bit atomics


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]