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]).
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.
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]).