Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc

[Jason Thorpe <thorpej%me.com@localhost>]

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

From: Jason Thorpe <thorpej%me.com@localhost>
To: "gnats-bugs%netbsd.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: lib-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 "martin%netbsd.org@localhost" <martin%NetBSD.org@localhost>
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 22 Dec 2018 11:05:27 -0800

 > On Dec 22, 2018, at 9:55 AM, coypu%sdf.org@localhost wrote:
 >=20
 > The following reply was made to PR lib/53051; it has been noted by =
 GNATS.
 >=20
 > From: coypu%sdf.org@localhost
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
 > Date: Sat, 22 Dec 2018 17:51:13 +0000
 >=20
 > Worth noting that netbsd *does* have locked atomics for SPARC.
 > They are in src/common/lib/libc/arch/sparc/atomic
 
 So, the way I understand this is that, on the "sparc" architecture, this =
 would return true on a uniprocessor system and false on a multiprocessor =
 system.  This is because on a multiprocessor system, our atomics always =
 use an interlock table because sparc only has LDSTUB (and all of the =
 various operations are implemented on top of the interlocked =
 compare-and-swap primitive), whereas on a uniprocessor, it's implemented =
 using a restartable atomic sequence.
 
 That, however, assumes that all of the C11 atomic calls get vectored =
 through our libc implementation (which is based on the Solaris atomics =
 API) ... all bets are off if they end up using some random =
 implementation in libgcc.
 
 -- thorpej