Mutex vs RWLock

flowchart TB
  reader_1["Reader 1 Idle"]
  reader_2["Reader 2 Idle"]
  rwlock["RWLock Exclusive"]
  writer["Writer Writing"]
  reader_1 -->|Read lock| rwlock
  reader_2 -->|Read lock| rwlock
  writer -->|Write wait| rwlock
  reader_1 -->|Read unlock| rwlock
  reader_2 -->|Read unlock| rwlock
  rwlock -->|Exclusive| writer
  writer -->|Write unlock| rwlock
  reader_2 -->|Cut in| rwlock
  rwlock -->|Starves| writer
  reader_1 -->|Still held| rwlock
  reader_1 -->|Serialize| writer
  reader_2 -->|Ping-pong| rwlock

Overview

Both locks can be correct. The interview question is cost and fairness: which one is faster for this read/write mix and section length, and which one can starve a writer.

In production the wrong pick shows up as a throughput ceiling (a mutex around a read-heavy cache) or as writer starvation and p99 spikes (a reader-preferring RWLock under a steady read stream).

By the end you should be able to:

• Say how a mutex and an RWLock track their state
• Explain reader-count cache-line ping-pong, and why Go's RWMutex scales poorly with CPU count
• Pick reader-preferring, writer-preferring, or fair from the platform you actually run
• Refuse an in-place upgrade, and re-check state after you drop the read lock
• Name what fails if you choose the other lock

Diagrams - step by step

Three small diagrams for Mutex vs RWLock. Step numbers in the labels give the animation order.

Diagram 1 - Happy path: many readers share, one writer gets exclusive access

Readers overlap because shared mode lets any number of them in at once. The writer only enters when the reader count drops to zero, and then it is alone, exactly like a mutex. This is the case where an RWLock pays off: reads dominate and readers really do overlap.

Diagram 2 - Failure path: writer starvation on a reader-preferring lock

If new readers can keep joining while a writer waits, a steady read stream keeps the reader count above zero and the writer may never run. Writer-preferring or fair (FIFO) RWLocks stop admitting new readers once a writer is queued. The cost is that readers now wait behind writers, so read latency goes up.

Diagram 3 - Decision: Mutex or RWLock, and what goes wrong with the other

Default to a plain mutex. An RWLock earns its extra bookkeeping only when reads dominate and each read holds the lock long enough for readers to overlap. On tiny sections every reader still does an atomic update on the shared reader count, so the cache line ping-pongs between cores and a mutex is often faster.

How each lock works

A mutex is one word of state: held or free. Unlock happens-before the next lock on that same mutex. Details live on happens-before.

An RWLock tracks a reader count plus a writer flag, and often a count of queued writers. Readers increment the count on entry and decrement it on exit. A writer waits until the count is 0 and then holds the lock alone, exactly like a mutex.

Python's threading.Lock is a mutex. threading.RLock is a reentrant mutex, not a readers-writer lock. The stdlib has no RWLock. Java pairs ReentrantLock with ReentrantReadWriteLock. C++ pairs std::mutex with std::shared_mutex. Rust pairs Mutex with RwLock.

Why an RWLock can lose

The reader count is shared, written state. Every read_lock and read_unlock is an atomic read-modify-write on the same cache line. With many cores doing short reads, that line bounces between caches and readers serialize on it anyway, now with more overhead than a mutex.

Go has a long-standing report of this: sync.RWMutex scales poorly with CPU count. A laptop benchmark often misses it. Measure at the core count you run in production, and record hold time, wait time, and CPU time spent on the lock word.

If the shared state is one word (a counter, a flag, a published pointer), use an atomic instead of either lock.

Why a mutex can lose

If read sections are long and reads dominate, a mutex makes readers queue behind each other even though none of them changes anything. Throughput is capped at one reader at a time. That is the case where an RWLock pays off: readers really do overlap.

Preference policy

A reader-preferring RWLock keeps admitting new readers while a writer waits, so a steady read stream can starve the writer. A writer-preferring lock blocks new readers once a writer is queued: writer wait is bounded, and read latency goes up. Fair locks (FIFO or phase-fair) alternate.

Know the platform:

• glibc pthread rwlocks prefer readers by default.
• Java ReentrantReadWriteLock has an optional fair mode. Unfair is the starvation default. Pick it explicitly.
• Go RWMutex blocks new readers as soon as a writer calls Lock.

Holding either lock across I/O while you also need a second lock is how you join the deadlock page. Copy what you need, drop the lock, then do the I/O.

Upgrades

Upgrading a read lock to a write lock deadlocks when two readers try it at once, because each waits for the other to leave. Most RWLocks do not support upgrade. Release the read lock, take the write lock, then re-check the state, because it may have changed in between. That re-check is the same rule as a Mesa wait: the predicate can be false by the time you run.

Some libraries offer an upgradable-read mode that only one thread may hold at a time (Rust parking_lot, Boost upgrade_mutex). If yours does not, do not invent an upgrade.

Checking state under the read lock, releasing it, then writing under the write lock without re-checking is a TOCTOU race. The TypeScript sample marks the same bug inside an async lock: the check and the take must be one synchronous step. An await between them lets another task pass the same check.

What goes wrong with the wrong pick

Mutex on long read-heavy sections: readers serialize and throughput drops to one reader at a time.

RWLock on tiny or write-heavy sections: the extra bookkeeping and the reader-count cache-line ping-pong make it slower than a mutex, and a reader-preferring lock can also starve writers.

A config map that is read on every request and rebuilt once a minute often wants neither lock. Build the new map off to the side and publish it with an atomic pointer swap. Readers take a snapshot with one atomic load. If you must lock, a writer-preferring RWLock fits, because writes are rare and short and must not starve.

Pros and cons

Working Python

Run python3 mutex_rwlock.py (stdlib only, about 2 seconds). Reads sleep inside the lock to stand in for real work. With the GIL, CPU-bound Python readers would not run in parallel anyway, so the win shown here is overlap. The in-page sandbox has no operating-system threads, so run this file locally.

"""Mutex vs RWLock: readers overlap, writers are exclusive, and preference policy decides starvation.

Run: python3 mutex_rwlock.py  (stdlib only, about 2 seconds)
Reads sleep inside the lock to stand in for real work (I/O, parsing). With the GIL,
CPU-bound Python readers would not run in parallel anyway, so the win shown here is overlap.
"""
import threading
import time


class RWLock:
    """Many readers OR one writer. prefer_writer=True blocks new readers once a writer waits."""

    def __init__(self, prefer_writer: bool = False) -> None:
        self._cv = threading.Condition()  # one mutex + condition guards all counters
        self._readers = 0                 # readers currently inside
        self._writer = False              # a writer is inside
        self._writers_waiting = 0         # queued writers (used only when prefer_writer)
        self._prefer_writer = prefer_writer

    def acquire_read(self) -> None:
        with self._cv:
            # Mesa semantics: always re-check the predicate in a while loop.
            while self._writer or (self._prefer_writer and self._writers_waiting > 0):
                self._cv.wait()
            self._readers += 1            # shared counter every reader must update

    def release_read(self) -> None:
        with self._cv:
            self._readers -= 1
            if self._readers == 0:
                self._cv.notify_all()     # last reader out lets a writer in

    def acquire_write(self) -> None:
        with self._cv:
            self._writers_waiting += 1
            while self._writer or self._readers > 0:
                self._cv.wait()
            self._writers_waiting -= 1
            self._writer = True

    def release_write(self) -> None:
        with self._cv:
            self._writer = False
            self._cv.notify_all()


def overlap_demo() -> None:
    """Same 8 reads of 50 ms: a Mutex serializes them, an RWLock lets them overlap."""
    def run(enter, leave) -> float:
        def reader() -> None:
            enter(); time.sleep(0.05); leave()
        ts = [threading.Thread(target=reader) for _ in range(8)]
        t0 = time.perf_counter()
        for t in ts: t.start()
        for t in ts: t.join()
        return time.perf_counter() - t0

    m = threading.Lock()
    rw = RWLock()
    print(f"8 readers with Mutex : {run(m.acquire, m.release):.2f}s (serialized)")
    print(f"8 readers with RWLock: {run(rw.acquire_read, rw.release_read):.2f}s (overlapped)")


def starvation_demo(prefer_writer: bool) -> float:
    """4 readers re-enter back to back for 1 s; how long does one writer wait?"""
    lock = RWLock(prefer_writer)
    stop = time.perf_counter() + 1.0

    def reader(offset: float) -> None:
        time.sleep(offset)                # stagger so read sections always overlap
        while time.perf_counter() < stop:
            lock.acquire_read(); time.sleep(0.02); lock.release_read()

    rs = [threading.Thread(target=reader, args=(i * 0.005,)) for i in range(4)]
    for t in rs: t.start()
    time.sleep(0.1)                       # readers are now streaming
    t0 = time.perf_counter()
    lock.acquire_write(); waited = time.perf_counter() - t0; lock.release_write()
    for t in rs: t.join()
    return waited


if __name__ == "__main__":
    overlap_demo()
    print(f"writer wait, reader-preferring: {starvation_demo(False):.2f}s (starved until readers stop)")
    print(f"writer wait, writer-preferring: {starvation_demo(True):.2f}s (new readers held back)")

Sample run: 8 readers with a mutex took 0.43s, and the same 8 readers with an RWLock took 0.05s. Writer wait under a steady read stream was 0.91s with a reader-preferring lock (starved until the readers stopped) and 0.02s with writer preference.

Working TypeScript

Run npx tsx mutex_rwlock.ts (no dependencies, about 2 seconds). Node runs JavaScript on one thread, but an await inside a critical section lets other tasks interleave, so a read-mostly cache still needs reader/writer locking. Run this file locally. The sleep loops are longer than the in-page sandbox allows.

// Mutex vs RWLock in Node: an async RWLock guarding state across await points.
// Run: npx tsx mutex_rwlock.ts  (no dependencies, about 2 seconds)
// Node runs JS on one thread, but an await inside a critical section lets other
// tasks interleave, so read-mostly caches still need reader/writer locking.
const sleep = (ms: number) => new Promise<void>((r) => setTimeout(r, ms));

class AsyncRWLock {
  private readers = 0;          // readers currently inside
  private writer = false;       // a writer is inside
  private writersWaiting = 0;   // queued writers
  private waiters: Array<() => void> = [];
  constructor(private preferWriter = false) {}

  private wake(): void {        // Mesa style: wake everyone, each re-checks its predicate
    const w = this.waiters; this.waiters = []; w.forEach((f) => f());
  }
  // Check and take must happen in the same synchronous step: an await between
  // them would let another task pass the same check (a TOCTOU bug).
  private async acquire(ok: () => boolean, take: () => void): Promise<void> {
    while (!ok()) await new Promise<void>((r) => this.waiters.push(r));
    take();
  }
  readLock(): Promise<void> {
    return this.acquire(
      () => !this.writer && !(this.preferWriter && this.writersWaiting > 0),
      () => { this.readers++; });
  }
  readUnlock(): void { if (--this.readers === 0) this.wake(); }
  writeLock(): Promise<void> {
    this.writersWaiting++;
    return this.acquire(
      () => !this.writer && this.readers === 0,
      () => { this.writersWaiting--; this.writer = true; });
  }
  writeUnlock(): void { this.writer = false; this.wake(); }
}

async function overlap(): Promise<void> {
  const rw = new AsyncRWLock();
  const asMutex = new AsyncRWLock();             // write mode only = a plain mutex
  const t0 = Date.now();
  await Promise.all(Array.from({ length: 8 }, async () => {
    await asMutex.writeLock(); await sleep(50); asMutex.writeUnlock();
  }));
  const t1 = Date.now();
  await Promise.all(Array.from({ length: 8 }, async () => {
    await rw.readLock(); await sleep(50); rw.readUnlock();
  }));
  console.log(`8 reads with Mutex : ${t1 - t0} ms (serialized)`);
  console.log(`8 reads with RWLock: ${Date.now() - t1} ms (overlapped)`);
}

async function writerWait(preferWriter: boolean): Promise<number> {
  const lock = new AsyncRWLock(preferWriter);
  const stop = Date.now() + 1000;
  const reader = async (offset: number) => {
    await sleep(offset);                         // stagger so read sections overlap
    while (Date.now() < stop) { await lock.readLock(); await sleep(20); lock.readUnlock(); }
  };
  const readers = [0, 5, 10, 15].map(reader);
  await sleep(100);
  const t0 = Date.now();
  await lock.writeLock(); const waited = Date.now() - t0; lock.writeUnlock();
  await Promise.all(readers);
  return waited;
}

async function main(): Promise<void> {
  await overlap();
  console.log(`writer wait, reader-preferring: ${await writerWait(false)} ms (starved)`);
  console.log(`writer wait, writer-preferring: ${await writerWait(true)} ms (new readers held back)`);
}
main();

Sample run: 8 reads with a mutex took 403 ms, and the RWLock took 53 ms. Writer wait was 919 ms reader-preferring and 17 ms writer-preferring. The comment in acquire marks a real bug found while writing it: checking and taking the lock across an await let every task pass the same check.

Interview Q&A

Pitfalls

Go Deeper

• Go sync.RWMutex
• Go issue 17973: sync.RWMutex scales poorly with CPU count
• Rust std::sync::RwLock
• Java ReentrantReadWriteLock (fair vs non-fair)
• POSIX pthread_rwlock_rdlock
• Readers-writer lock (Wikipedia)

Cluster: hub · next Mesa vs Hoare · when locks win