Atomics vs Locks

flowchart TB
  thread_1["Thread 1 CAS set 7"]
  counter["Atomic counter Value 7"]
  thread_2["Thread 2 Added 1"]
  mutex["Mutex Idle"]
  thread_1 -->|Load 5| counter
  thread_2 -->|Fetch add| counter
  thread_1 -->|CAS miss| counter
  thread_1 -->|CAS set 7| counter
  thread_1 -->|No block| thread_2
  thread_1 -->|Retry storm| counter
  thread_2 -->|ABA| counter
  thread_2 -->|Convoy| mutex
  thread_1 -->|Torn pair| thread_2
  counter -->|Hot lock| mutex
  mutex -->|Shard| counter

Overview

Interviewers want the edge where atomics stop helping: multi-field invariants, CAS retry storms, ABA, and memory ordering. They also want you to refuse the claim that lock-free means faster.

In production a hot lock shows up as convoys and p99 spikes. A hot atomic shows up as CPU burned in retries with flat throughput. The fix for both is usually less sharing, not a different primitive.

By the end you should be able to:

• Pick an atomic or a lock from the invariant, not from the vibe
• Walk a CAS loop and name ABA, retry storms, and side effects that run twice
• Contrast blocking, lock-free, and wait-free
• Choose release/acquire or relaxed and say why a lock gets ordering for free
• Say what a torn pair looks like when each field is atomic

Diagrams - step by step

Three small diagrams for Atomics vs Locks. Step numbers in the labels give the animation order.

Diagram 1 - Happy path: lock-free update of one word with CAS and FAA

Atomics work on a single word with read-modify-write instructions. FAA (fetch_add) always succeeds in one step; a CAS loop re-reads and retries when another thread changed the value first. No thread sleeps or holds anything, which is why simple counters and flags are the sweet spot for atomics.

Diagram 2 - Contention: CAS retry storm vs lock convoy

Neither tool removes contention on one hot location. Atomics fail by spinning: retries waste CPU while the cache line moves between cores. Locks fail by queueing: one slow holder makes everyone wait in line. The real fix is to reduce sharing, for example per-core counters merged later.

Diagram 3 - Decision: atomic or lock, and what goes wrong with the other

Locks are the default for clarity, and they are required when an invariant covers several fields. Atomics win for single-word counters and flags. Making each field atomic does not make the group atomic, so a multi-field invariant built from atomics can still be torn.

What an atomic gives you

Hardware instructions make one read-modify-write on one aligned word indivisible: x86 LOCK XADD and CMPXCHG, ARM LDXR/STXR or LSE atomics. fetch_add always succeeds in one step. compare_and_swap(expected, new) succeeds only if nobody changed the word since you read it, so anything more complex than an add becomes a CAS loop: read, compute, CAS, retry on failure.

Python has no user-level hardware CAS. The sample below emulates one instruction with a tiny internal lock. The algorithm is the same one C++ compare_exchange, Java AtomicInteger, and JavaScript Atomics.compareExchange run in hardware. Progress terms and CAS-loop structure are on atomic operations and CAS loops.

What a lock gives you

Mutual exclusion over an arbitrary block of code, so several fields, a whole data structure, or a syscall can change as one unit. Uncontended, a good mutex is itself one atomic CAS to acquire and one store to release. The cost appears under contention, when waiters spin and then sleep in the kernel (futex) and every handoff is a context switch.

A lock also gives acquire on lock and release on unlock. That is one reason locks are easier to get right than a hand-rolled atomic flag. Ordering rules: relaxed, acquire/release, seqcst. Waiting for a predicate is a condition variable, not a spin on a flag. Several locks still need an order, or you deadlock: deadlock prevention.

Progress guarantees

Using AtomicInteger inside a method that also takes a lock is not a lock-free algorithm. Lock-free is a property of the algorithm, not of the type you imported.

Memory ordering

An atomic also orders the memory around it. Use release on the store that publishes data and acquire on the load that reads the flag. Relaxed is only for values nobody uses to publish other data, such as statistics counters. A reader that sees a relaxed flag set can still observe stale payload.

A lock gives these edges for free. Two relaxed stores of balance and version are a torn pair even though each store is atomic.

Contention

One hot word bounces between cores whichever primitive you use. Shard it (per-thread or per-core counters summed on read, like Java LongAdder or Linux per-CPU counters), batch updates locally and flush, or add backoff to CAS loops. That removes the shared cache line. A faster primitive on the same line does not. When the profile says the lock is the hot path and the structure is one you can review, that is the page on when locks win.

What goes wrong with the wrong pick

Atomics for multi-field state: each field updates atomically, but a reader can see the new balance with the old version number. Fix it with a lock, a seqlock (writers bump a sequence around the update and readers retry if it changed), or by packing both into one word or one immutable object swapped by pointer.

A lock around a hot one-word counter: every increment pays for a lock handoff, and waiters convoy behind a preempted holder, when one fetch_add would do.

ABA is the other CAS failure. The value goes A to B to A, and the CAS succeeds on a different A. Pointer-based lock-free stacks and queues hit this when memory is reused. Tagged pointers, hazard pointers, or epoch reclamation are the usual fixes. That is lock-free queues, stacks, and ABA.

Pros and cons

Working Python

Run python3 atomics_locks.py (stdlib only, a few seconds). AtomicInt emulates one hardware instruction with a tiny internal lock so the lost-update, CAS, and mutex paths share the same race window (time.sleep(0)). Run it locally. The in-page sandbox has no operating-system threads.

"""Atomics vs Locks: lost updates, a CAS retry loop, and a mutex, under the same contention.

Run: python3 atomics_locks.py  (stdlib only, a few seconds)
Python has no user-level hardware CAS, so AtomicInt emulates one instruction with a tiny
internal lock. The algorithm (read, compute, compare-and-swap, retry) is exactly what
C++ compare_exchange, Java AtomicInteger or JS Atomics.compareExchange do in hardware.
"""
import threading
import time

THREADS, OPS = 8, 5_000


class AtomicInt:
    def __init__(self, v: int = 0) -> None:
        self._v, self._hw = v, threading.Lock()   # _hw stands in for the CPU instruction
    def load(self) -> int:
        return self._v
    def compare_and_set(self, expected: int, new: int) -> bool:
        with self._hw:                             # one indivisible step
            if self._v != expected:
                return False                       # someone else won, caller retries
            self._v = new
            return True


def run(worker) -> float:
    ts = [threading.Thread(target=worker) for _ in range(THREADS)]
    t0 = time.perf_counter()
    for t in ts: t.start()
    for t in ts: t.join()
    return time.perf_counter() - t0


def racy() -> None:
    box = {"n": 0}
    def worker() -> None:
        for _ in range(OPS):
            v = box["n"]          # read
            time.sleep(0)         # yield: another thread can run between read and write
            box["n"] = v + 1      # write back a stale value = lost update
    secs = run(worker)
    print(f"plain read-modify-write: {box['n']:>6} of {THREADS*OPS} ({secs:.2f}s) lost updates")


def cas_loop() -> None:
    a, retries = AtomicInt(), [0] * THREADS
    def worker(i: int) -> None:
        for _ in range(OPS):
            while True:
                v = a.load()
                time.sleep(0)     # same window as above, but CAS detects the conflict
                if a.compare_and_set(v, v + 1):
                    break
                retries[i] += 1   # contention shows up as wasted retries, not wrong data
    ts = [threading.Thread(target=worker, args=(i,)) for i in range(THREADS)]
    t0 = time.perf_counter()
    for t in ts: t.start()
    for t in ts: t.join()
    secs = time.perf_counter() - t0
    print(f"CAS loop               : {a.load():>6} of {THREADS*OPS} ({secs:.2f}s) retries={sum(retries)}")


def with_lock() -> None:
    box, lock = {"n": 0}, threading.Lock()
    def worker() -> None:
        for _ in range(OPS):
            with lock:            # nobody else can enter, so the same window is harmless
                v = box["n"]
                time.sleep(0)     # but every other thread now waits while we sleep
                box["n"] = v + 1
    secs = run(worker)
    print(f"mutex                  : {box['n']:>6} of {THREADS*OPS} ({secs:.2f}s) zero retries, waiters block")


if __name__ == "__main__":
    racy()
    cas_loop()
    with_lock()

Sample run, 8 threads times 5000 increments: plain read-modify-write ended at 5008 of 40000 (lost updates). The CAS loop reached 40000 of 40000 in 1.56s with 177830 retries. The mutex reached 40000 of 40000 in 2.62s with zero retries, and the other threads blocked inside the lock.

Working TypeScript

Run npx tsx atomics_locks.ts (Node 16+, no dependencies). Four worker_threads share one SharedArrayBuffer and compare a plain load/store, Atomics.add, a CAS loop, and a futex-style mutex (Atomics.wait / Atomics.notify). Run it in Node. The page sandbox cannot start worker_threads.

// Atomics vs Locks with real threads: worker_threads sharing one SharedArrayBuffer.
// Run: npx tsx atomics_locks.ts  (Node 16+, no dependencies)
import { Worker } from "node:worker_threads";

const THREADS = 4, OPS = 200_000;

// Worker body. It runs in a separate V8 isolate, so it is plain JS passed via eval.
// Slots in the shared Int32Array: [0] counter, [1] mutex word (0 free, 1 held), [2+i] retries of worker i
const WORKER_JS = `
const { workerData, parentPort } = require("node:worker_threads");
const { buf, mode, ops, id } = workerData;
const s = new Int32Array(buf);
for (let i = 0; i < ops; i++) {
  if (mode === "plain") {
    s[0] = s[0] + 1;                       // load then store: two steps, updates get lost
  } else if (mode === "faa") {
    Atomics.add(s, 0, 1);                  // one fetch-and-add instruction, never retries
  } else if (mode === "cas") {
    for (;;) {                             // CAS loop: read, compute, swap if unchanged
      const v = Atomics.load(s, 0);
      if (Atomics.compareExchange(s, 0, v, v + 1) === v) break;
      Atomics.add(s, 2 + id, 1);           // lost the race, count the retry
    }
  } else {                                 // "mutex": a lock built from atomics plus a futex wait
    while (Atomics.compareExchange(s, 1, 0, 1) !== 0) Atomics.wait(s, 1, 1);
    s[0] = s[0] + 1;                       // plain access is safe inside the critical section
    Atomics.store(s, 1, 0);
    Atomics.notify(s, 1, 1);               // wake one sleeper if any
  }
}
parentPort.postMessage("done");
`;

async function trial(mode: string): Promise<void> {
  const buf = new SharedArrayBuffer(4 * (2 + THREADS));
  const s = new Int32Array(buf);
  const t0 = performance.now();
  await Promise.all(Array.from({ length: THREADS }, (_, id) => new Promise<void>((ok, fail) => {
    const w = new Worker(WORKER_JS, { eval: true, workerData: { buf, mode, ops: OPS, id } });
    w.once("message", () => { void w.terminate(); ok(); });
    w.once("error", fail);
  })));
  const ms = (performance.now() - t0).toFixed(0);
  let retries = 0;
  for (let i = 0; i < THREADS; i++) retries += s[2 + i];
  const note = mode === "cas" ? ` retries=${retries}` : "";
  console.log(`${mode.padEnd(5)}: ${String(s[0]).padStart(7)} of ${THREADS * OPS} in ${ms} ms${note}`);
}

async function main(): Promise<void> {
  for (const m of ["plain", "faa", "cas", "mutex"]) await trial(m);
}
main();

Sample run, 4 workers times 200000 increments on 8 cores: plain ended at 521093 of 800000 in 85 ms (lost updates). Atomics.add reached 800000 in 77 ms. The CAS loop reached 800000 in 103 ms with 293620 retries. The futex-style mutex reached 800000 in 264 ms.

Interview Q&A

Pitfalls

Go Deeper

• Mara Bos, Rust Atomics and Locks (free online book)
• Rust Atomics and Locks: the processor (cache lines and contention)
• MDN: JavaScript Atomics
• Node.js worker_threads and SharedArrayBuffer
• Jeff Preshing, An Introduction to Lock-Free Programming
• Compare-and-swap and the ABA problem (Wikipedia)

Cluster: happens-before · hub · CAS loops · memory ordering · lock-free queues · when locks win