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 29 June 2011 20:45, Joseph S. Myers <joseph@codesourcery.com> wrote:

Thanks for the reply,

> 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).

OK.

>> ? 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.

Great; that's one less piece of work to do.

>> ? 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.

OK; that may cause trouble at some point - there was quite a discussion
that took a while to resolve about the positioning of a memory barrier that
came down to the precise wording of gcc's semantics.

>> ? 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?

It's the same mechanism used by the fallbacks that are already called in
ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h ; i.e. a jump to
a special address in the commpage at 0xfff0... - if the CPU is a new
CPU then it does exactly the same thing as we would have inlined
(using ldrexd etc), if it's old then:
   1) If it's not SMP then it just does it using a non-atomic set of
instructions
but has a catcher in the interrupt handlers such that if that sequence
is interrupted
it goes back to the start of it in a controlled way.
   2) Or it can end up performing a system call to do it (although I
can't find the
definition of that system call...)

Nicolas Pitre's patch for the 64bit helper is here:
https://patchwork.kernel.org/patch/894932/

> 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.

Given that the 64bit fallback is the same type of callback used for
the other sizes on older hardware, and it's actually doing the atomic operation
asked for I don't think that's a problem; the only gotcha in the 64bit case
is that the 64bit fallback is only present on newer kernels.

Dave
> --
> 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]