remove @fence

[Rexicon226]

closes #11650

Release Notes:

In Zig 0.14, @fence has been removed. @fence was provided to be consistent with the C11 memory model, however, it complicates semantics by modifying the memory orderings of all previous and future atomic operations. This creates unforeseen constraints that are hard to model in a sanitizer. Fences can be substituted by either upgrading atomic memory orderings or adding new atomic operations.

The most common use cases for @fence can be replaced by utilizing stronger memory orderings or by introducing a new atomic variable.

StoreLoad Barriers

The most common use case is @fence(.seq_cst). This is primarily used to ensure a consistent order between multiple operations on different atomic variables.
For example:

thread-1:                     thread-2:
    store X         // A          store Y          // C
    fence(seq_cst)  // F1         fence(seq_cst)   // F2   
    load  Y         // B          load  X          // D

The goal is to ensure either load X (D) sees store X (A), or load Y (B) sees store Y (C). The pair of Sequentially Consistent fences guarantees this via two invariance.

Now that @fence is removed, there are other ways of achieving this relationship:

• Making all related stores and loads (A, B, C, and D) SeqCst, including them all in the total order.
• Making a store (A/C) Acquire and its matching load (D/B) Release. Semantically, this would mean upgrading them to read-modify-write operations, which could be such ordering. Loads can be replaced with a non-mutating RMW, i.e. fetchAdd(0) or fetchOr(0).
  Optimizers like LLVM may reduce this into a @fence(.seq_cst) + load internally.

Conditional Barriers

Another use case for fences is conditionally creating a synchronizes-with relationship with previous or future atomic operations, using Acquire or Release respectively. A simple example of this in the real world is an atomic reference counter:

fn inc(counter: *RefCounter) void {
    _ = counter.rc.fetchAdd(1, .monotonic);
}

fn dec(counter: *RefCounter) void {
    if (counter.rc.fetchSub(1, .release) == 1) {
        @fence(.acquire); 
        counter.deinit(); 
    }
}

The load in the fetchSub(1) only needs to be Acquire for the last ref-count decrement to ensure previous decrements
happen-before the deinit(). The @fence(.acquire) here creates this relationship using the load part of the fetchSub(1).

Without @fence, there are two approaches here:

1. Unconditionally strengthen the desired atomic operations with the fence's ordering.
   For example:

    if (counter.rc.fetchSub(1, .acq_rel) == 1) {

2. Conditionally duplicate the desired store or load with the fence's ordering.
   For example:

    if (counter.rc.fetchSub(1, .release) == 1) {
        _ = counter.rc.load(.acquire);

The Acquire will synchronize-with the longest release-sequence in rc's modification order, making all previous decrements happen-before the deinit().

Synchronize External Operations

The least common usage of @fence is providing additional synchronization to atomic operations the programmer has no control over (i.e. external function calls). Using a @fence in this situation relies on the "hidden" functions having atomic operations with undesirably weak orderings.

Ideally, the "hidden" functions would be accessible to the user and they could simply increase the order in the source code. But if this isn't possible, a last resort is introducing an atomic variable to simulate the fence's barriers. For example:

thread-1:                    thread-2:
   queue.push()                e = signal.listen()
   fence(.seq_cst)             fence(.seq_cst)
   signal.notify()             if queue.empty(): e.wait()

thread-1:                    thread-2:
   queue.push()                e = signal.listen()
   fetchAdd(0, .seq_cst)       fetchAdd(0, .seq_cst)
   signal.notify()             if queue.empty(): e.wait()

[The-King-of-Toasters]

I believe the zig_fence definitions in the *.h files should also be removed, no?

[Rexicon226]

I believe the zig_fence definitions in the *.h files should also be removed, no?

Good catch, I totally missed that!

[andrewrk]

Good thing I never bothered to write these docs 🙃