Memory Ordering

19 min read

When two threads touch the same atomic, the question is no longer “is the operation indivisible?” but “what else is the compiler and CPU allowed to reorder around it?”. The Ordering argument every atomic method takes answers exactly that. This file covers the five variants — Relaxed, Acquire, Release, AcqRel, and SeqCst — what each one guarantees, and how to pick the right one.

Quick Overview

A modern CPU and an optimizing compiler both reorder memory accesses to go faster — a store you wrote first might become visible to another core after a store you wrote second. Memory ordering is the set of rules you opt into so that one thread’s writes become visible to another thread in a predictable way. In Rust you choose an ordering on every atomic operation via std::sync::atomic::Ordering; choosing too weak an ordering is a real (if rare) bug, and choosing too strong a one is just slower.

Note: This is the conceptual companion to atomic-operations.md. That file covers which atomic types and methods exist (load, store, fetch_add, compare_exchange). This file covers the Ordering argument those methods all take.

TypeScript/JavaScript Example

JavaScript hides almost all of this from you. A normal program is single-threaded, so within one thread the language guarantees your code appears to run in source order. The only place ordering becomes visible is the Atomics API used with a SharedArrayBuffer shared between the main thread and a Worker.

1
// worker-shared.ts — the shared-memory surface JS actually exposes.
2
const sab = new SharedArrayBuffer(8);
3
const view = new Int32Array(sab);
4

5
// Every Atomics operation is *sequentially consistent*. There is no
6
// "relaxed" or "acquire/release" knob in JavaScript at all.
7
Atomics.store(view, 0, 42); // publish
8
const seen = Atomics.load(view, 0); // observe -> always 42
9
console.log("load:", seen);
10

11
// Read-modify-write, also fully sequentially consistent:
12
const old = Atomics.add(view, 0, 1); // returns the previous value
13
console.log("add returned old value:", old); // 42
14
console.log("after add:", Atomics.load(view, 0)); // 43
15

16
// compareExchange(view, index, expected, replacement) -> previous value
17
console.log("cas:", Atomics.compareExchange(view, 0, 43, 100)); // 43
18
console.log("final:", Atomics.load(view, 0)); // 100

Running this under Node v22 prints:

1
load: 42
2
add returned old value: 42
3
after add: 43
4
cas: 43
5
final: 100

Key point: JavaScript gives you exactly one memory ordering — the strongest, sequentially-consistent one — and no way to weaken it. That is simpler, but it leaves performance on the table and gives you no vocabulary for the distinctions Rust makes explicit.

Rust Equivalent

Rust forces you to name an ordering on every atomic operation. The most common and most useful pattern is release/acquire publication: one thread writes some data and then “publishes” a flag with Release; another thread reads the flag with Acquire and is then guaranteed to see the data.

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4

5
fn main() {
6
    // Shared data plus a "ready" flag.
7
    let data = Arc::new(AtomicU64::new(0));
8
    let ready = Arc::new(AtomicBool::new(false));
9

10
    let data_producer = Arc::clone(&data);
11
    let ready_producer = Arc::clone(&ready);
12

13
    let producer = thread::spawn(move || {
14
        data_producer.store(42, Ordering::Relaxed); // (1) write the data
15
        ready_producer.store(true, Ordering::Release); // (2) publish: "data is ready"
16
    });
17

18
    let consumer = thread::spawn(move || {
19
        // Spin until we observe the Release store.
20
        while !ready.load(Ordering::Acquire) {
21
            std::hint::spin_loop();
22
        }
23
        // Acquire guarantees (1) is visible here, so this is always 42.
24
        let value = data.load(Ordering::Relaxed);
25
        println!("consumer saw data = {value}");
26
    });
27

28
    producer.join().unwrap();
29
    consumer.join().unwrap();
30
}

Output:

1
consumer saw data = 42

The Release store at (2) and the Acquire load that observes it form a happens-before edge: everything the producer did before the Release store (including the data write at (1)) is guaranteed visible to the consumer after its Acquire load returns true. That guarantee is the entire point of memory ordering.

Tip: The current stable toolchain is Rust 1.96.0 on the 2024 edition; cargo new selects it automatically. Atomics and Ordering have been stable since Rust 1.0 and follow the C++20 memory model.

Detailed Explanation

There are five Ordering values. Think of them as a ladder from “no synchronization, just atomicity” up to “global total order”.

`Relaxed` — atomicity only, no ordering

Relaxed guarantees the single operation is indivisible (no torn reads/writes) and nothing else. It creates no happens-before relationship with any other memory. It is perfect for a counter whose value is the only thing you care about:

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicUsize, Ordering};
3
use std::thread;
4

5
fn main() {
6
    let counter = Arc::new(AtomicUsize::new(0));
7

8
    let handles: Vec<_> = (0..8)
9
        .map(|_| {
10
            let counter = Arc::clone(&counter);
11
            thread::spawn(move || {
12
                for _ in 0..100_000 {
13
                    // Relaxed is enough: we only need the count to be correct,
14
                    // not to synchronize any *other* memory with it.
15
                    counter.fetch_add(1, Ordering::Relaxed);
16
                }
17
            })
18
        })
19
        .collect();
20

21
    for h in handles {
22
        h.join().unwrap();
23
    }
24

25
    println!("final count = {}", counter.load(Ordering::Relaxed));
26
}

Output:

1
final count = 800000

The total is always exactly 800000 because each fetch_add is atomic. Relaxed is correct here precisely because the count does not guard any other data — no thread reads the counter and then assumes some other memory is in a particular state.

`Release` — a one-way “publish” barrier (stores only)

A Release store says: “every memory write I did before this store must not be reordered after it, and becomes visible to any thread that later acquires this value.” It is the write half of publication. Release is only valid on operations that write (store, the success path of compare_exchange, fetch_*).

`Acquire` — a one-way “observe” barrier (loads only)

An Acquire load says: “every memory read I do after this load must not be reordered before it; and if I observe a value written by a Release, I see everything that thread did before that Release.” It is the read half of publication. Acquire is only valid on operations that read.

Release and Acquire only do anything as a pair, on the same atomic variable. A lone Release with no matching Acquire synchronizes with nobody.

`AcqRel` — both halves at once (read-modify-write only)

A read-modify-write operation (fetch_add, swap, compare_exchange) both reads and writes. AcqRel makes the read half an Acquire and the write half a Release. Use it when a single RMW both observes a previous publication and publishes its own result:

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicU32, Ordering};
3
use std::thread;
4

5
// A counter built from compare_exchange (a read-modify-write), so AcqRel
6
// is the natural fit: it both reads and writes the location.
7
fn main() {
8
    let value = Arc::new(AtomicU32::new(0));
9
    let handles: Vec<_> = (0..4)
10
        .map(|_| {
11
            let value = Arc::clone(&value);
12
            thread::spawn(move || {
13
                for _ in 0..50_000 {
14
                    let mut current = value.load(Ordering::Relaxed);
15
                    loop {
16
                        let next = current + 1;
17
                        match value.compare_exchange_weak(
18
                            current,
19
                            next,
20
                            Ordering::AcqRel,  // success: acquire+release the RMW
21
                            Ordering::Relaxed, // failure: we just retry, no sync needed
22
                        ) {
23
                            Ok(_) => break,
24
                            Err(observed) => current = observed,
25
                        }
26
                    }
27
                }
28
            })
29
        })
30
        .collect();
31
    for h in handles {
32
        h.join().unwrap();
33
    }
34
    println!("CAS counter = {}", value.load(Ordering::Relaxed));
35
}

Output:

1
CAS counter = 200000

compare_exchange and compare_exchange_weak take two orderings: one for success and one for failure. The failure ordering describes only the load that happened (the CAS did not write), so it may be Acquire, Relaxed, or SeqCst — never Release/AcqRel. See Common Pitfalls.

`SeqCst` — sequential consistency (the strongest)

SeqCst does everything AcqRel does and adds a single global total order that all SeqCst operations across all threads agree on. This extra guarantee matters only in subtle cases involving more than two variables, such as the store-buffer / Dekker pattern below: each thread writes its own flag and reads the other’s.

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};
3
use std::thread;
4

5
// Dekker-style store-buffer test, run many times.
6
fn run_once() -> usize {
7
    let x = Arc::new(AtomicBool::new(false));
8
    let y = Arc::new(AtomicBool::new(false));
9
    let z = Arc::new(AtomicUsize::new(0)); // how many threads saw the *other* flag as false
10

11
    let (x1, y1, z1) = (Arc::clone(&x), Arc::clone(&y), Arc::clone(&z));
12
    let t1 = thread::spawn(move || {
13
        x1.store(true, Ordering::SeqCst);
14
        if !y1.load(Ordering::SeqCst) {
15
            z1.fetch_add(1, Ordering::SeqCst);
16
        }
17
    });
18

19
    let (x2, y2, z2) = (Arc::clone(&x), Arc::clone(&y), Arc::clone(&z));
20
    let t2 = thread::spawn(move || {
21
        y2.store(true, Ordering::SeqCst);
22
        if !x2.load(Ordering::SeqCst) {
23
            z2.fetch_add(1, Ordering::SeqCst);
24
        }
25
    });
26

27
    t1.join().unwrap();
28
    t2.join().unwrap();
29
    z.load(Ordering::SeqCst)
30
}
31

32
fn main() {
33
    // Under SeqCst, z is never 2: a single global order forbids *both* threads
34
    // reading the other's flag as false.
35
    let mut max_seen = 0;
36
    for _ in 0..100_000 {
37
        max_seen = max_seen.max(run_once());
38
    }
39
    println!("max z observed over 100k runs = {max_seen} (SeqCst forbids 2)");
40
}

Output:

1
max z observed over 100k runs = 1 (SeqCst forbids 2)

If both stores and both loads used only Release/Acquire, the outcome z == 2 would be permitted by the memory model (each thread’s store could sit in a store buffer while it reads a stale false for the other flag). SeqCst rules that out because the four operations must fit into one consistent global sequence.

Note: z is 0 or 1 here, never 2. You will rarely need this multi-variable guarantee — but when you are not sure, SeqCst is the safe default and the one that matches JavaScript’s Atomics.

Key Differences

Concept	JavaScript `Atomics`	Rust `Ordering`
Available orderings	One (sequentially consistent)	Five (`Relaxed`/`Acquire`/`Release`/`AcqRel`/`SeqCst`)
Default / only choice	`SeqCst`-equivalent, forced	You must pick explicitly every call
Non-atomic shared writes	Not directly observable across threads	Reorderable; ordering only constrains relative to the atomic
Cost model	Hidden, always strongest	You pay only for what you ask for
Memory model basis	ECMAScript shared-memory model	C++20 (C11) memory model

A few rules worth internalizing:

Release is for stores, Acquire is for loads, AcqRel is for read-modify-writes. Asking for the wrong category is a compile error (shown below), not a silent footgun.
Synchronization is per-variable and pairwise. A Release on flag only synchronizes with an Acquire on flag that observes that store. It does nothing for some other atomic.
Ordering constrains surrounding memory, not just the atomic itself. That is the whole reason it exists: the Acquire/Release pair is what makes your non-atomic Vec, String, etc. safe to hand between threads once a flag flips.
Strength ladder: Relaxed < Release/Acquire < AcqRel < SeqCst. Pick the weakest one that is provably correct; default to SeqCst only when reasoning gets hard.

Warning: Unlike TypeScript, where number precision and single-threading insulate you, getting Rust’s ordering too weak produces a bug that often passes every test on x86 (which is strongly ordered) and only fails on ARM or under heavy contention. Memory-ordering bugs do not show up as compiler errors — they show up as flaky production incidents. When in doubt, go stronger.

Common Pitfalls

Pitfall 1: Using a `Release` failure ordering on `compare_exchange`

A failed compare_exchange performs only a load, so a Release/AcqRel failure ordering is meaningless — and rejected at compile time by a built-in lint.

1
use std::sync::atomic::{AtomicU32, Ordering};
2

3
fn main() {
4
    let a = AtomicU32::new(0);
5
    // does not compile: failure ordering may not be Release or AcqRel
6
    let _ = a.compare_exchange(0, 1, Ordering::AcqRel, Ordering::Release);
7
}

Real compiler output:

1
error: `compare_exchange`'s failure ordering may not be `Release` or `AcqRel`, since a failed `compare_exchange` does not result in a write
2
 --> src/main.rs:6:56
3
  |
4
6 |     let _ = a.compare_exchange(0, 1, Ordering::AcqRel, Ordering::Release);
5
  |                                                        ^^^^^^^^^^^^^^^^^ invalid failure ordering
6
  |
7
  = help: consider using `Acquire` or `Relaxed` failure ordering instead
8
  = note: `#[deny(invalid_atomic_ordering)]` on by default

Fix: use Ordering::Acquire (if you need to observe the publication on failure) or Ordering::Relaxed (if you will just retry).

Pitfall 2: Asking a `store` for an `Acquire` ordering (or a `load` for `Release`)

The categories are enforced. A store cannot be Acquire/AcqRel; a load cannot be Release/AcqRel.

1
use std::sync::atomic::{AtomicBool, Ordering};
2

3
fn main() {
4
    let flag = AtomicBool::new(false);
5
    // does not compile: store cannot have Acquire/AcqRel ordering
6
    flag.store(true, Ordering::Acquire);
7
    let _ = flag.load(Ordering::Release);
8
}

Real compiler output:

1
error: atomic stores cannot have `Acquire` or `AcqRel` ordering
2
 --> src/main.rs:6:22
3
  |
4
6 |     flag.store(true, Ordering::Acquire);
5
  |                      ^^^^^^^^^^^^^^^^^
6
  |
7
  = help: consider using ordering modes `Release`, `SeqCst` or `Relaxed`
8
  = note: `#[deny(invalid_atomic_ordering)]` on by default
9

10
error: atomic loads cannot have `Release` or `AcqRel` ordering
11
 --> src/main.rs:7:23
12
  |
13
7 |     let _ = flag.load(Ordering::Release);
14
  |                       ^^^^^^^^^^^^^^^^^
15
  |
16
  = help: consider using ordering modes `Acquire`, `SeqCst` or `Relaxed`

Pitfall 3: Publishing with `Relaxed` (the silent one)

This is the dangerous one because it compiles cleanly — there is no diagnostic. It is a logic bug, not a type error.

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4

5
fn main() {
6
    let data = Arc::new(AtomicU64::new(0));
7
    let ready = Arc::new(AtomicBool::new(false));
8

9
    let (d, r) = (Arc::clone(&data), Arc::clone(&ready));
10
    let producer = thread::spawn(move || {
11
        d.store(42, Ordering::Relaxed);
12
        // BUG: Relaxed gives no ordering relative to the data store above.
13
        r.store(true, Ordering::Relaxed);
14
    });
15

16
    let consumer = thread::spawn(move || {
17
        while !ready.load(Ordering::Relaxed) {
18
            std::hint::spin_loop();
19
        }
20
        // With Relaxed there is NO happens-before edge. The CPU/compiler may let
21
        // this read run before the data store is visible. It usually prints 42 on
22
        // x86, but that is luck, not a guarantee — on a weakly-ordered CPU (ARM)
23
        // it can legitimately read 0.
24
        println!("consumer saw {}", data.load(Ordering::Relaxed));
25
    });
26

27
    producer.join().unwrap();
28
    consumer.join().unwrap();
29
}

This builds and, on a typical x86 desktop, will print consumer saw 42 every time — which is exactly why the bug is so insidious. The fix is the Rust Equivalent at the top: publish with Release, observe with Acquire. To catch this class of bug, run your tests under cargo +nightly miri test (Miri’s randomized weak-memory emulation can surface the missing edge) or ThreadSanitizer.

Pitfall 4: Expecting two unrelated `Release`/`Acquire` pairs to give a total order

Release/Acquire only orders memory relative to the one variable in the pair. If your algorithm needs all threads to agree on the interleaving of operations on several variables (the store-buffer case), you need SeqCst. Reaching for Acquire/Release there is a classic over-optimization that introduces a rare reordering bug.

Best Practices

Default to SeqCst while prototyping. It matches JavaScript’s Atomics, it is the easiest to reason about, and it is correct everywhere. Weaken to Acquire/Release/Relaxed only after you can articulate why the weaker ordering is sufficient.
Use Relaxed for standalone counters and statistics — values that are not used to guard other memory (request counts, metrics, ID generators).
Use Release to publish and Acquire to consume whenever a flag or pointer “hands off” other data between threads. This is the workhorse pattern.
Use AcqRel on read-modify-writes (fetch_*, swap, compare_exchange success) that both observe and publish.
Prefer a higher-level abstraction first. Mutex, RwLock, OnceLock, channels (channels.md), and the standard collections already encapsulate correct orderings. Hand-rolled atomics with custom orderings belong in lock-free data structures and hot paths, not everyday code.
Document the pairing. Write a comment naming which Release pairs with which Acquire; future readers cannot infer it from types alone.
Verify with tooling. Run concurrency-sensitive code under Miri (cargo +nightly miri test) and/or loom for exhaustive interleaving checks before trusting a weak ordering.

Real-World Example

A background metrics worker that increments a Relaxed counter and watches a Release/Acquire shutdown flag — the two most common orderings, each used where it is exactly right.

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4
use std::time::Duration;
5

6
/// Shared state for a background metrics worker.
7
struct Metrics {
8
    requests: AtomicU64,
9
    shutdown: AtomicBool,
10
}
11

12
fn main() {
13
    let metrics = Arc::new(Metrics {
14
        requests: AtomicU64::new(0),
15
        shutdown: AtomicBool::new(false),
16
    });
17

18
    // Worker: increments a counter until asked to stop.
19
    let worker = {
20
        let metrics = Arc::clone(&metrics);
21
        thread::spawn(move || {
22
            // Acquire pairs with the Release store in the shutdown signal below.
23
            while !metrics.shutdown.load(Ordering::Acquire) {
24
                // Relaxed: the count guards no other memory, so atomicity is enough.
25
                metrics.requests.fetch_add(1, Ordering::Relaxed);
26
                thread::sleep(Duration::from_micros(50));
27
            }
28
            // Final count after we observed the shutdown signal.
29
            metrics.requests.load(Ordering::Relaxed)
30
        })
31
    };
32

33
    thread::sleep(Duration::from_millis(5));
34

35
    // Signal shutdown. Release ensures every write we did before this store is
36
    // visible to the worker once it Acquire-loads `true`.
37
    metrics.shutdown.store(true, Ordering::Release);
38

39
    let processed = worker.join().unwrap();
40
    println!("worker processed {processed} requests before shutdown");
41
}

This compiles and runs; the exact count varies run to run (it depends on timing), but the worker always stops promptly after the Release store, and the printed total is always the value it actually reached — never a torn or stale number. The pattern generalizes directly to graceful shutdown of HTTP servers and background jobs; for OS-signal-driven shutdown see signals.md.

Note: For a single boolean stop flag like this, even Relaxed on both ends would technically suffice because the worker reads no other shared state through the flag. The Acquire/Release pair is the right habit to build, and it is what you must use the moment the flag also guards other data (a results buffer, a config pointer, etc.).

Exercises

Exercise 1: Fix the broken publish

Difficulty: Beginner

Objective: Recognize a missing happens-before edge and repair it with the correct orderings.

Instructions: The program below publishes a value through a flag using Relaxed on both ends, so the consumer’s read of data is not guaranteed to see 1234. Change only the orderings so the data is correctly published, and have the consumer assert_eq! it.

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4

5
fn main() {
6
    let data = Arc::new(AtomicU64::new(0));
7
    let ready = Arc::new(AtomicBool::new(false));
8

9
    let (d, r) = (Arc::clone(&data), Arc::clone(&ready));
10
    let producer = thread::spawn(move || {
11
        d.store(1234, Ordering::Relaxed);
12
        r.store(true, /* ??? */ Ordering::Relaxed); // publish
13
    });
14

15
    let consumer = thread::spawn(move || {
16
        while !ready.load(/* ??? */ Ordering::Relaxed) {
17
            std::hint::spin_loop();
18
        }
19
        // TODO: assert the data is 1234
20
    });
21

22
    producer.join().unwrap();
23
    consumer.join().unwrap();
24
}

Solution

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4

5
fn main() {
6
    let data = Arc::new(AtomicU64::new(0));
7
    let ready = Arc::new(AtomicBool::new(false));
8

9
    let (d, r) = (Arc::clone(&data), Arc::clone(&ready));
10
    let producer = thread::spawn(move || {
11
        d.store(1234, Ordering::Relaxed);
12
        r.store(true, Ordering::Release); // publish
13
    });
14

15
    let consumer = thread::spawn(move || {
16
        while !ready.load(Ordering::Acquire) {
17
            std::hint::spin_loop();
18
        }
19
        assert_eq!(data.load(Ordering::Relaxed), 1234);
20
        println!("ok: data correctly published");
21
    });
22

23
    producer.join().unwrap();
24
    consumer.join().unwrap();
25
}

Output:

1
ok: data correctly published

The Release store and the Acquire load that observes true create the happens-before edge that makes the Relaxed read of data see 1234.

Exercise 2: Run-once initialization with `compare_exchange`

Difficulty: Intermediate

Objective: Use a read-modify-write with AcqRel to ensure a block of work runs exactly once, even when many threads race to run it.

Instructions: Spawn eight threads that all try to perform a one-time initialization. Use an AtomicU8 state machine (UNINIT → RUNNING → DONE) and compare_exchange so that exactly one thread wins the UNINIT → RUNNING transition and does the init. Prove only one ran by counting.

Solution

1
use std::sync::Arc;
2
use std::sync::atomic::{AtomicU8, Ordering};
3
use std::thread;
4

5
const UNINIT: u8 = 0;
6
const RUNNING: u8 = 1;
7
const DONE: u8 = 2;
8

9
fn main() {
10
    let state = Arc::new(AtomicU8::new(UNINIT));
11
    let init_count = Arc::new(AtomicU8::new(0));
12

13
    let handles: Vec<_> = (0..8)
14
        .map(|_| {
15
            let state = Arc::clone(&state);
16
            let init_count = Arc::clone(&init_count);
17
            thread::spawn(move || {
18
                // Only one thread wins the UNINIT -> RUNNING transition.
19
                // AcqRel on success: acquire any prior publication, release our
20
                // init writes. Acquire on failure: observe the winner's state.
21
                if state
22
                    .compare_exchange(UNINIT, RUNNING, Ordering::AcqRel, Ordering::Acquire)
23
                    .is_ok()
24
                {
25
                    init_count.fetch_add(1, Ordering::Relaxed); // "do the init"
26
                    state.store(DONE, Ordering::Release);
27
                }
28
            })
29
        })
30
        .collect();
31

32
    for h in handles {
33
        h.join().unwrap();
34
    }
35
    println!("init ran {} time(s)", init_count.load(Ordering::Relaxed));
36
}

Output:

1
init ran 1 time(s)

In real code you would not hand-roll this — std::sync::OnceLock / OnceCell and std::sync::Once encapsulate exactly this pattern with the correct orderings already chosen.

Exercise 3: Publish with explicit fences

Difficulty: Advanced

Objective: Reproduce the release/acquire publication using a pair of standalone fences plus Relaxed atomics, to understand that fences and tagged operations are two ways to express the same edge.

Instructions: Rewrite Exercise 1’s publication so the flag store and the flag load are both Relaxed, but the producer issues a fence(Ordering::Release) before the flag store and the consumer issues a fence(Ordering::Acquire) after observing the flag. The data read must still be guaranteed to see the published value.

Solution

1
use std::sync::Arc;
2
use std::sync::atomic::{fence, AtomicBool, AtomicU64, Ordering};
3
use std::thread;
4

5
fn main() {
6
    let data = Arc::new(AtomicU64::new(0));
7
    let ready = Arc::new(AtomicBool::new(false));
8

9
    let (d, r) = (Arc::clone(&data), Arc::clone(&ready));
10
    let producer = thread::spawn(move || {
11
        d.store(7, Ordering::Relaxed);
12
        fence(Ordering::Release);         // release fence
13
        r.store(true, Ordering::Relaxed); // the Relaxed store is "covered" by the fence
14
    });
15

16
    let consumer = thread::spawn(move || {
17
        while !ready.load(Ordering::Relaxed) {
18
            std::hint::spin_loop();
19
        }
20
        fence(Ordering::Acquire);         // acquire fence pairs with the release fence
21
        assert_eq!(data.load(Ordering::Relaxed), 7);
22
        println!("ok: fence-paired publish works");
23
    });
24

25
    producer.join().unwrap();
26
    consumer.join().unwrap();
27
}

Output:

1
ok: fence-paired publish works

A fence(Release) before a Relaxed store, paired with a fence(Acquire) after the Relaxed load that observes it, builds the same happens-before edge as tagging the store/load themselves with Release/Acquire. Fences are useful when one fence needs to cover several nearby relaxed operations; for a single store/load, the tagged form in Exercise 1 is more idiomatic.

Memory Ordering

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Relaxed — atomicity only, no ordering

Release — a one-way “publish” barrier (stores only)

Acquire — a one-way “observe” barrier (loads only)

AcqRel — both halves at once (read-modify-write only)

SeqCst — sequential consistency (the strongest)

Key Differences

Common Pitfalls

Pitfall 1: Using a Release failure ordering on compare_exchange

Pitfall 2: Asking a store for an Acquire ordering (or a load for Release)

Pitfall 3: Publishing with Relaxed (the silent one)

Pitfall 4: Expecting two unrelated Release/Acquire pairs to give a total order

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Fix the broken publish

Exercise 2: Run-once initialization with compare_exchange

Exercise 3: Publish with explicit fences

`Relaxed` — atomicity only, no ordering

`Release` — a one-way “publish” barrier (stores only)

`Acquire` — a one-way “observe” barrier (loads only)

`AcqRel` — both halves at once (read-modify-write only)

`SeqCst` — sequential consistency (the strongest)

Pitfall 1: Using a `Release` failure ordering on `compare_exchange`

Pitfall 2: Asking a `store` for an `Acquire` ordering (or a `load` for `Release`)

Pitfall 3: Publishing with `Relaxed` (the silent one)

Pitfall 4: Expecting two unrelated `Release`/`Acquire` pairs to give a total order

Exercise 2: Run-once initialization with `compare_exchange`