Re: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

[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@xxxxxxx if there are any questions.
> Thanks,
> Jade
>
>
> From: Paul E. McKenney <paulmck@xxxxxxxxxx>
> Sent: 27 October 2023 22:08
> To: Alglave, Jade <j.alglave@xxxxxxxxx>; will@xxxxxxxxxx <will@xxxxxxxxxx>; catalin.marinas@xxxxxxx <catalin.marinas@xxxxxxx>; linux@xxxxxxxxxxxxxxx <linux@xxxxxxxxxxxxxxx>; mpe@xxxxxxxxxxxxxx <mpe@xxxxxxxxxxxxxx>; npiggin@xxxxxxxxx <npiggin@xxxxxxxxx>; palmer@xxxxxxxxxxx <palmer@xxxxxxxxxxx>; parri.andrea@xxxxxxxxx <parri.andrea@xxxxxxxxx>
> Cc: linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; linux-toolchains@xxxxxxxxxxxxxxx <linux-toolchains@xxxxxxxxxxxxxxx>; peterz@xxxxxxxxxxxxx <peterz@xxxxxxxxxxxxx>; boqun.feng@xxxxxxxxx <boqun.feng@xxxxxxxxx>; davidtgoldblatt@xxxxxxxxx <davidtgoldblatt@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxx> -----
>
> Date: Fri, 27 Oct 2023 11:09:18 -0700
> From: David Goldblatt via Parallel <parallel@xxxxxxxxxxxxxxxx>
> To: SG1 concurrency and parallelism <parallel@xxxxxxxxxxxxxxxx>
> Reply-To: parallel@xxxxxxxxxxxxxxxx
> Cc: David Goldblatt <davidtgoldblatt@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxx
> 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 -----