NetBSD-Bugs archive

[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: Kamil Rytarowski <>
To: "" <>
Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
Date: Sat, 3 Aug 2019 03:46:10 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 Content-Type: multipart/mixed; boundary="nCr0hHIhWCUhGTUoQz54UCM092GVXeHbN";
 From: Kamil Rytarowski <>
 To: "" <>
 Message-ID: <>
 Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
 References: <>
 In-Reply-To: <>
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 On 03.08.2019 02:44, Joerg Sonnenberger wrote:
 > 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 wit=
 >>  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=
 ras(9) having nearly 0 overhead is debatable as it is used in every
 cpu_switchto(9) call, even if there are nearly no users of it on modern
 Similar with libatomic, users of it do not care about shared memory
 unless they are doing something wrongly. No need to push the bar too
 high that cannot be solved (without switching to UP kernel mode)
 I see no problem with performance hit. It can be really slow, but
 running existing unmodified code is a good tradeoff.
 >>  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 reason=
 > that certain folks are loudly pushing for futex semantics everywhere is=
 > because they want to implement locking primitives in shared memory, tha=
 > shouldn't be surprising at all. Given that double width cas is the
 > typical solution for dealing with lock-free data structures, even less.=
 With the switch from libatomic_ops to C11/C++14 atomics there will be a
 growing demand for a fallback library implementation (unless we will
 stop caring about hardware predating 64/128bit atomic operations).
 One of the candidates for libatomic in base is LLDB (I am aware that we
 can patch LLDB to stop demanding it).
 >>  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 coun=
 > 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.
 With the push toward at least CHERI 128bit pointer architecture, we are
 going to have a growing need for 128bit atomics.
 They are already in toolchains and allocators.
 > Joerg
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

Home | Main Index | Thread Index | Old Index