Rename compiler_barrier to compiler_fence

[jonhoo]

This addresses concerns raised following the merge of #41092. Specifically:

The naming of these seems surprising: the multithreaded functions (and both the single and multithreaded intrinsics themselves) are fences, but this is a barrier. It's not incorrect, but the latter is both inconsistent with the existing functions and slightly confusing with another type in std (e.g., Barrier).

compiler_fence carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in std.

[rust-highfive]

r? @GuillaumeGomez

(rust_highfive has picked a reviewer for you, use r? to override)

[jonhoo]

r? @parched

[alexcrichton]

I personally don't mind going either way on this, @jonhoo do you know if there's precedent for naming here we can draw from other languages perhaps?

[jonhoo]

I've been struggling to find other languages that expose this feature beyond C++ (which exposes it as atomic_signal_fence). D and Julie only have the full atomic fence (and called atomic_fence). Go only has a mark-and-sweep write barrier called gcmarkwb_m as far as I can tell. Java doesn't seem to have anything quite equivalent. The docs say that "each action in a thread happens-before every action in that thread that comes later in the program's order", but I don't know how that interacts with interrupt-like changes of execution, which is what atomic_signal_fence addresses.

I was and am hesitant to go with the C++ name for two reasons: it is not exclusively for signals (interrupts are also an important use-case), and atomic_signal_fence could too easily be misconstrued to also do cross-thread synchronization). compiler_barrier and compiler_fence to me both suggest that the operation is indeed entirely about what the compiler is allowed to do, which was the intention. I do agree with the objection raised in #41092 and quoted in the top post that _barrier could easily be connected (incorrectly) with sync::atomic::Barrier, and that fence is better since it associates more closely with the atomic_signal_fence equivalent in C++.

[bstrie]

Thanks for researching precedence! I concur with the arguments for compiler_fence over both compiler_barrier and atomic_signal_fence. If you want to get even more literal I might suggest reorder_fence (eh, maybe), but as long as we avoid conflation I'm not too concerned.

[jonhoo]

@bstrie I see what you're trying to do with reorder_fence, but I think it's more likely to cause confusion since so many things can be "reordered", especially when you also take into account the different Ordering arguments you can give. One alternative might be mem_reorder_fence, but I'm not sure it's really that much clearer than compiler_fence. It also still has the potential issue that users may not immediately recognize that we're only talking about compiler re-ordering.

[parched]

I think compiler_fence is good, the other one I would consider is single_thread_fence which probably makes more sense if rust is to ever add single thread atomics too.

[jonhoo]

@parched I'm actually skeptical of single_thread_fence, because that to me still sounds like it might prevent CPU re-ordering (which, of course, it does not). I think we should merge this change to compiler_fence.

[alexcrichton]

Thanks for the investigation @jonhoo and others for weighing in! I'm convinced of compiler_fence myself and this is unstable regardless, so let's land this and we can reevaluate during stabilization of course.

@bors: r+

[bors]

📌 Commit 368d560 has been approved by alexcrichton

[bors]

⌛ Testing commit 368d560 with merge e621e1c...