Messages in this thread | | | Date | Sat, 4 Nov 2023 19:20:27 +0100 | Subject | Re: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion | From | Jonas Oberhauser <> |
| |
Thanks Jade.
I agree with the position you linked to in that the move is... unwise.
IMO, for a high-level language like C, if you need to outrule OOTA, just declare it impossible (Viktor, in CC, made this suggestion a while ago) by a "no OOTA axiom".
BTW, is there at least a proof that just making relaxed atomics ordered in this way rules out OOTA in programs that contain non-atomics? Or can we have something like the LKMM OOTA example I sent around last year?
best wishes,
jonas
Am 11/3/2023 um 6:02 PM schrieb Alglave, Jade: > Dear all, (resending because I accidentally sent it in html first, sorry) > > Arm’s official position on the topic can be found in this recent blog: > https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-technical-view-on-relaxed-atomics > > Please do reach out to memory-model@arm.com if there are any questions. > Thanks, > Jade > > > From: Paul E. McKenney <paulmck@kernel.org> > Sent: 27 October 2023 22:08 > To: Alglave, Jade <j.alglave@ucl.ac.uk>; will@kernel.org <will@kernel.org>; catalin.marinas@arm.com <catalin.marinas@arm.com>; linux@armlinux.org.uk <linux@armlinux.org.uk>; mpe@ellerman.id.au <mpe@ellerman.id.au>; npiggin@gmail.com <npiggin@gmail.com>; palmer@dabbelt.com <palmer@dabbelt.com>; parri.andrea@gmail.com <parri.andrea@gmail.com> > Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-toolchains@vger.kernel.org <linux-toolchains@vger.kernel.org>; peterz@infradead.org <peterz@infradead.org>; boqun.feng@gmail.com <boqun.feng@gmail.com>; davidtgoldblatt@gmail.com <davidtgoldblatt@gmail.com> > Subject: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion > > ⚠ Caution: External sender > > > Hello! > > FYI, unless someone complains, it is quite likely that C++ (and thus > likely C) compilers and standards will enforce Hans Boehm's proposal > for ordering relaxed loads before relaxed stores. The document [1] > cites "Bounding data races in space and time" by Dolan et al. [2], and > notes an "average a 2.x% slow down" for ARMv8 and PowerPC. In the past, > this has been considered unacceptable, among other things, due to the > fact that this issue is strictly theoretical. > > This would not (repeat, not) affect the current Linux kernel, which > relies on volatile loads and stores rather than C/C++ atomics. > > To be clear, the initial proposal is not to change the standards, but > rather to add a command-line argument to enforce the stronger ordering. > However, given the long list of ARM-related folks in the Acknowledgments > section, the future direction is clear. > > So, do any ARMv8, PowerPC, or RISC-V people still care? If so, I strongly > recommend speaking up. ;-) > > Thanx, Paul > > [1] https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/ > [2] https://dl.acm.org/doi/10.1145/3192366.3192421 > > ----- Forwarded message from David Goldblatt via Parallel <parallel@lists.isocpp.org> ----- > > Date: Fri, 27 Oct 2023 11:09:18 -0700 > From: David Goldblatt via Parallel <parallel@lists.isocpp.org> > To: SG1 concurrency and parallelism <parallel@lists.isocpp.org> > Reply-To: parallel@lists.isocpp.org > Cc: David Goldblatt <davidtgoldblatt@gmail.com> > Subject: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion > > Those who read this list but not the LLVM discourse might be interested in: > - This discussion, proposing `-mstrict-rlx-atomics`: > https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-implementation-behind-mstrict-rlx-atomics-flag/74473 > to enforce load-store ordering > - The associated blog post here: > https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/ > > - David > > _______________________________________________ > Parallel mailing list > Parallel@lists.isocpp.org > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/parallel > Link to this post: http://lists.isocpp.org/parallel/2023/10/4151.php > > > ----- End forwarded message -----
| |