Re: kern/58340: 64-bit atomic ops unusable for armv7: __HAVE_ATOMIC64_{OPS,LOADSTORE} confusion

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 18 Jun 2024 23:44:01 +0900
> From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
> 
> (1) Shouldn't we document things explicitly in, e.g., SIZE AND ALIGNMENT
> section in atomic_loadstore(9)?

I added a paragraph about this.  Does that help?

> (2) Can't we provide 64-bit atomic-ops API for ILP32 platforms? If no,
> do you speak about something by which we don't provide such runtime
> routines with our libc?

I don't understand.  Are you suggesting that we implement
atomic_load/store_* in terms of atomic_swap_*, or are you talking
about hash-locked atomic r/m/w like sparc32 and hppa, or what?

The point of __HAVE_ATOMIC64_LOADSTORE is to test whether the
architecture supports a _cheap_ atomic 64-bit load/store which can
safely be used without locking.  (Well, except for the hash-locked
architectures -- sparc32, hppa -- where atomic _stores_ can't be done
cheaply at all because they have to coordinate with the hash-locked
CAS anyway.)

So while it would be possible in principle (in the kernel, at least,
with all code cooperating in the protocol) to use a hash-locked scheme
for 64-bit atomic_load/store_*, this is almost certainly a waste --
better to just use an application-specific lock for better performance
and easier reasoning.