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

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

The following reply was made to PR kern/58340; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58340: 64-bit atomic ops unusable for armv7:
	__HAVE_ATOMIC64_{OPS,LOADSTORE} confusion
Date: Tue, 18 Jun 2024 19:14:23 +0000

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