[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
The following reply was made to PR toolchain/54431; it has been noted by GNATS.
From: Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%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
Main Index |
Thread Index |