Memory Barriers

Every program you write runs in a world that looks sequential — one instruction after the next, in the order you wrote them. That illusion is carefully maintained, but only for a single thread.

The moment two threads share a variable, the deal changes. Modern CPUs execute instructions out of order to keep their pipelines busy, and compilers reorder stores and loads to reduce memory traffic. Each thread still sees a consistent view of its own operations, but what another thread observes can look scrambled in time.

A memory barrier (also called a memory fence) is an instruction that says: "every load and store before me must complete before any load or store after me begins." It is the only portable tool that puts time back in order across cores.

The subject sits at the intersection of hardware microarchitecture and the correctness of concurrent programs. Getting it wrong produces bugs that appear once in a million runs — and vanish the moment you add a print statement to debug them.

The demo below simulates two threads sharing two variables, flag and data, on a weak memory model. Thread A writes data first, then sets flag. Thread B spins until it sees flag set, then reads data.

<!-- {{c_intro}} -->
<div class="panel">
  <div class="legend">
    <span class="dot thread-a"></span> {{label_thread_a}}
    <span class="dot thread-b"></span> {{label_thread_b}}
  </div>
  <div class="vars-row">
    <div class="var-box" id="box-data">
      <div class="var-name">data</div>
      <div class="var-val" id="val-data">0</div>
    </div>
    <div class="fence-col" id="fence-col">
      <div class="fence-label" id="fence-label">{{label_no_fence}}</div>
      <div class="fence-line" id="fence-line"></div>
    </div>
    <div class="var-box" id="box-flag">
      <div class="var-name">flag</div>
      <div class="var-val" id="val-flag">0</div>
    </div>
  </div>
  <div class="step-row" id="step-row">
    <div class="step" id="step-a"></div>
    <div class="step" id="step-b"></div>
  </div>
  <div class="status" id="status">{{status_idle}}</div>
  <div class="btns">
    <button id="btn-no-fence" type="button">{{btn_no_fence}}</button>
    <button id="btn-fence" type="button" class="safe">{{btn_fence}}</button>
    <button id="btn-reset" type="button" class="ghost">{{btn_reset}}</button>
  </div>
  <div class="scoreboard" id="scoreboard">
    <div class="score-item">
      <div class="score-label">{{label_runs}}</div>
      <div class="score-val" id="sc-runs">0</div>
    </div>
    <div class="score-item bad">
      <div class="score-label">{{label_bugs}}</div>
      <div class="score-val" id="sc-bugs">0</div>
    </div>
    <div class="score-item ok">
      <div class="score-label">{{label_ok}}</div>
      <div class="score-val" id="sc-ok">0</div>
    </div>
  </div>
</div>

/* {{c_reset}} */
* { box-sizing: border-box; margin: 0; padding: 0; }
body { font-family: system-ui, sans-serif; color: #222; background: #f5f7fa; }
.panel { max-width: 420px; margin: 0 auto; padding: 1rem; }
.legend { display: flex; align-items: center; gap: .8rem; font-size: .85rem; color: #555; margin-bottom: .8rem; }
.dot { display: inline-block; width: 10px; height: 10px; border-radius: 50%; }
.thread-a { background: #1d3557; }
.thread-b { background: #e76f51; }
/* {{c_vars}} */
.vars-row { display: flex; align-items: center; justify-content: center; gap: 0; margin: .5rem 0; }
.var-box { background: #fff; border: 2px solid #cdd9e3; border-radius: 10px; padding: .6rem 1.2rem;
           text-align: center; min-width: 90px; }
.var-name { font-size: .75rem; color: #888; font-weight: 600; letter-spacing: .05em; text-transform: uppercase; }
.var-val  { font-size: 2rem; font-weight: 700; color: #1d3557; line-height: 1.2; transition: color .2s; }
.var-val.flash-ok  { color: #0a7d33; }
.var-val.flash-bad { color: #c92f3c; }
/* {{c_fence}} */
.fence-col { display: flex; flex-direction: column; align-items: center; width: 60px; }
.fence-label { font-size: .65rem; font-weight: 700; letter-spacing: .04em; text-transform: uppercase;
               color: #aaa; margin-bottom: 2px; }
.fence-line { width: 2px; height: 60px; background: #ccc; transition: background .3s; }
.fence-col.active .fence-label { color: #0a7d33; }
.fence-col.active .fence-line { background: #0a7d33; box-shadow: 0 0 6px #0a7d3380; }
/* {{c_steps}} */
.step-row { display: flex; gap: .5rem; min-height: 2.4rem; margin: .5rem 0; }
.step { flex: 1; font-size: .82rem; color: #333; background: #e8eef3; border-radius: 7px;
        padding: .35rem .5rem; text-align: center; min-height: 2.2rem; display: flex;
        align-items: center; justify-content: center; transition: background .2s; }
.step.a { background: #d0d9e8; }
.step.b { background: #fde8e0; }
.status { font-size: 1rem; font-weight: 600; margin: .4rem 0; min-height: 1.4em; }
.status.ok  { color: #0a7d33; }
.status.bad { color: #c92f3c; }
.btns { display: flex; gap: .5rem; flex-wrap: wrap; margin-bottom: .8rem; }
button { font: 600 13px system-ui; padding: .45rem .8rem; border: 1px solid #1d3557;
         background: #1d3557; color: #fff; border-radius: 8px; cursor: pointer; }
button.safe  { background: #0a7d33; border-color: #0a7d33; }
button.ghost { background: #fff; color: #1d3557; }
/* {{c_scoreboard}} */
.scoreboard { display: flex; gap: .5rem; }
.score-item { flex: 1; background: #fff; border: 1px solid #cdd9e3; border-radius: 8px;
              padding: .4rem .3rem; text-align: center; }
.score-item.bad .score-val { color: #c92f3c; }
.score-item.ok  .score-val { color: #0a7d33; }
.score-label { font-size: .68rem; color: #888; font-weight: 600; text-transform: uppercase; }
.score-val   { font-size: 1.4rem; font-weight: 700; }

// Code not found

Without a barrier, the CPU is free to deliver the write to flag before the write to data reaches the other core — so Thread B can read flag = 1 and still see data = 0. Click Run without barrier to trigger the bug, then click Run with barrier to see the fence restore ordering. The numbers update live across many simulated runs.

Memory barriers are not a single thing — they are a family of guarantees defined by each hardware platform's memory model.

• Sequential consistency (SC) is the programmer's ideal: operations appear to execute in the global order they were issued. Almost no real CPU provides this by default, because it requires stalling the pipeline after every shared-memory access.
• Total Store Order (TSO), used by x86 and SPARC, allows a store to sit in a write buffer before becoming globally visible, so a store-load pair can appear reordered. A single fence flushes the buffer.
• Weak models (ARM, POWER, RISC-V) allow almost any reordering between independent memory operations. They require fences to restore even store-store and load-load order.
• Acquire and Release semantics are the high-level vocabulary: an acquire fence prevents later operations from moving before it; a release fence prevents earlier operations from moving after it. Together they implement the "publish-subscribe" pattern that lock-free data structures depend on.

The formal study of memory models is connected to the theory of concurrent computation pioneered by Leslie Lamport in his 1979 paper that introduced sequential consistency. Deciding whether a program is data-race-free — and therefore safe under SC — is undecidable in general, making memory model analysis a neighbor of the halting problem.

Compiler barriers are a separate concern: the C++ keyword volatile prevents the compiler from caching a variable in a register, but does not emit a hardware fence — a common source of bugs. The correct tool is std::atomic with explicit memory_order annotations, or POSIX mutex primitives that carry implied barriers.

Any system that touches shared state across threads is downstream of memory barriers:

• Lock-free data structures: ring buffers, Michael–Scott queues, and hazard-pointer schemes all rely on carefully placed acquire/release fences to publish nodes without holding a lock.
• Operating system kernels: context switches, interrupt handlers, and inter-CPU communication (IPI) rely on barriers to keep per-CPU state synchronized. Linux's smp_mb(), smp_rmb(), and smp_wmb() macros are the canonical examples.
• Database engines: write-ahead logging (WAL) must ensure a log record hits durable storage before the database acknowledges a commit. The fsync + barrier sequence is the correctness guarantee.
• Language runtimes: garbage collectors that run concurrently with application threads use read/write barriers (a different but related concept) to track which objects have been modified since the last GC pass.
• Hardware drivers: memory-mapped I/O requires barriers to prevent the CPU from buffering a write to a device register behind a later read from the same device.

Understanding barriers also unlocks the design of correct concurrent algorithms and helps explain why simply declaring a variable volatile is not enough to write a correct spinlock.

Memory barriers are the price of performance. Every technique a CPU uses to run fast — out-of-order execution, store buffers, write combining — can make shared variables appear in the wrong order to another core. Barriers are the handshake that tells the hardware: this ordering is not optional.

The topic feels low-level, but it surfaces everywhere: lock-free libraries, database durability, OS kernels, and even compilers all trade on the same guarantees. Getting memory ordering right is one of the few places where the gap between "the code looks correct" and "the code is correct" can be a single missing instruction — invisible until the bug strikes under the worst possible conditions.

If you found this interesting, the study of what computations are even possible when threads communicate through shared memory connects deeply to the halting problem and the broader limits of what we can reason about automatically.