This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/3] sysdeps/arm/bits/atomic.h: Add a wider range of atomic operations
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, libc-alpha at sourceware dot org
- Date: Mon, 06 Oct 2014 15:29:35 +0200
- Subject: Re: [PATCH 2/3] sysdeps/arm/bits/atomic.h: Add a wider range of atomic operations
- Authentication-results: sourceware.org; auth=none
- References: <1412349086-11473-1-git-send-email-will dot newton at linaro dot org> <1412349086-11473-3-git-send-email-will dot newton at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1410031628020 dot 14538 at digraph dot polyomino dot org dot uk>
On Fri, 2014-10-03 at 16:31 +0000, Joseph S. Myers wrote:
> On Fri, 3 Oct 2014, Will Newton wrote:
>
> > -# define __arch_compare_and_exchange_bool_64_int(mem, newval, oldval, model) \
> > - ({__arm_link_error (); 0; })
> > +# define __arch_exchange_32_int(mem, newval, model) \
> > + __atomic_exchange_n (mem, newval, model)
>
> I think obvious link errors are desirable for 64-bit atomics, rather than
> possibly calling libatomic functions using locks, or libgcc functions that
> would introduce a hidden dependency on a more recent kernel version (for
> 64-bit atomics helpers) than we currently require (the helpers having been
> introduced in 3.1).
>
> (So in a generic header it should be configurable whether it provides
> 64-bit atomic operations or not.)
I don't feel like we need link errors for 64b atomics, but if we do I
agree that the generic header should take care of this, under
arch-specific control. I don't think we need to have finer granularity
than, roughly, "supports 64b atomic ops on naturally aligned 64b
integers".
Some concurrent algorithms might be written differently if an arch
provides atomic read-modify-write ops like atomic_or instead of just a
CAS; but I don't think we have such optimizations in current code, so we
can just add this later (including the arch-specific flags for this)
instead of havign to consider this now.