Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, he%NetBSD.org@localhost
Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
Date: Sat, 3 Aug 2019 02:44:30 +0200

 On Fri, Aug 02, 2019 at 01:40:01PM +0000, Kamil Rytarowski wrote:
 >  We already ship with ras(9) that is significantly worse and does not
 >  work in probably any SMP or shared memory scenarios.. but we ship with
 >  it basically in every port as in UP setups it can be good enough.
 
 ras(9) is nearly zero overhead and *only* meant to help implementing
 atomics on UP architectures. It doesn't care about shared memory at all.
 
 >  libatomic in general works unless we are in fewer corner-cases.
 
 I do not call shared memory a corner case. Given that one of the reasons
 that certain folks are loudly pushing for futex semantics everywhere is
 because they want to implement locking primitives in shared memory, that
 shouldn't be surprising at all. Given that double width cas is the
 typical solution for dealing with lock-free data structures, even less.
 
 >  SPARC implementation could be improved if needed and should not block
 >  ppc or i386.
 
 I meanted Sparc because it is the one architecture with a non-trivial
 deployment of SMP systems and without native CAS or LL/SC. I don't count
 VAX. That said, the problems of Sparc atomics is shared with 64bit
 atomics on 32bit PPC and i386 as well as 128bit atomics on most LP64
 platforms.
 
 Joerg