5 ms·

I also just added these to Julia for 1.14 (https://github.com/JuliaLang/julia/pull/60311 https://github.com/JuliaLang/julia/pull/60311).

• anon_farmer 2mo ago
  Thanks for the link, I didn't know it was implemented in Julia (or any other language for that matter). I took a brief look at the PR, and there was one comment that caught my attention: > Note that unlike the C++ spec, I have specified that atomic_fence_heavy does synchronize with atomic_fence. I don't think C++ can specify that guarantee for the following reason: The agreement is that if, for some reason, the OS does not provide the required abstraction, falling back to `std::atomic_thread_fence(std::memory_order_seq_cst)` should still be a conforming implementation. However, `std::atomic_thread_fence(std::memory_order_seq_cst)` does not establish any new synchronizes-with relationships (at least, not beyond those already provided by the existing release/acquire fence rules). We can see why this wording fails in Approach 2 of P1202R0. With `membarrier` specifically, I still have not figured out a case that would break this specifically, but theoretically it feels possible since there are cases where happens-before are not enforced. That said, heavyweight fences do provide everything that ordinary fences provide. As Concurrency TS2 states: > A heavyweight-fence has all the synchronization effects of a fence (C++20 §33.5.11 [atomics.fences]).
  • anon_farmer 2mo ago
    After playing around with it a bit more, I stand corrected: > but theoretically it feels possible since there are cases where happens-before are not enforced. It does seem there might be enough guarantees given by LKMM, but I'll probably have to dive a bit deeper to prove that.