Read-Write locks

Two doors, four rules

• A reader may enter if no writer is inside. Other readers are irrelevant — they don't block each other, because reading is not a change.
• A writer may enter only when the room is completely empty — no readers, no other writer. Exclusive means exclusive.
• A waiting writer must wait for the readers to drain. It cannot kick anyone out; it sits in the queue until the last current reader releases its lock.
• While a writer is waiting or working, new readers are held out. Otherwise a steady trickle of readers would keep the room permanently non-empty and the writer would never get in.

That last rule is the interesting one. It's why the prototype shows a reader queueing with the tag waiting: writer queued even though nobody is technically writing yet. The lock is deliberately holding the door shut so the writer eventually gets its turn.

ReadWriteLock rw = new ReentrantReadWriteLock();
Map<String, String> config = new HashMap<>();

String get(String key) {
    rw.readLock().lock();          // SHARED — many threads at once
    try   { return config.get(key); }
    finally { rw.readLock().unlock(); }   // always in a finally
}

void reload(Map<String, String> fresh) {
    rw.writeLock().lock();         // EXCLUSIVE — waits for readers to drain
    try   { config = fresh; }
    finally { rw.writeLock().unlock(); }
}

Note the shape: lock() outside the try, unlock() inside a finally. Unlike Java's synchronized block, an explicit lock is not released for you when an exception flies out — forget the finally and the lock is held forever, which freezes every other thread. This is the single most common bug in hand-written lock code.

When it pays off — and when it doesn't

A read-write lock is not free. It has to track how many readers are inside, wake a writer when the count hits zero, and decide who goes next — that's more state and more atomic operations than a mutex, which only tracks locked-or-not. You are paying that overhead on every single acquire, including all the reads.

• It pays off when reads hugely outnumber writes and the critical sections are long enough for the parallelism to matter — an in-memory catalogue read a thousand times per update, a routing table, a cache of parsed config.
• It does not pay off when writes are frequent: the write lock serialises everything anyway, so you've bought the bookkeeping and none of the concurrency.
• It does not pay off for very short critical sections — reading one field, incrementing one counter. The lock's own overhead dwarfs the work being protected, and a plain mutex (or an atomic variable) is measurably faster.

The honest default is: start with a plain mutex. Move to a read-write lock only when you've measured a read-heavy contention problem. Swapping one in "because it sounds faster" often makes things slower.

Starvation: who gets to go next?

If the lock simply let readers in whenever no writer was currently inside, a busy system could keep at least one reader in the room forever, and the writer would sit in the queue indefinitely. That's writer starvation — a thread that is never technically deadlocked, just permanently unlucky. The fix is a policy:

• Read-preferring — readers jump straight in whenever no writer holds the lock. Best raw read throughput, but writers can starve.
• Write-preferring — once a writer is waiting, new readers queue behind it. Writers always get their turn; read throughput dips slightly. This is what the prototype does.
• Fair (FIFO) — everyone is served in arrival order. No starvation for anyone, but readers that could have shared a turn are split up, so throughput drops. Java's new ReentrantReadWriteLock(true) gives you this.

Downgrading is fine — upgrading deadlocks

Downgrading means going from the write lock to the read lock: while still holding the write lock, acquire the read lock, then release the write lock. This is legal and useful — you finish your update and keep reading the fresh value without ever letting go and racing someone else for it.

What your language gives you

• Java — ReentrantReadWriteLock (optionally fair) is the standard one. StampedLock is faster but not reentrant, and adds an optimistic read: you read without locking, then call validate() to ask "did a writer touch this while I was reading?" — if it says no, you paid almost nothing; if it says yes, you retry with a real read lock.
• C++ — std::shared_mutex (C++17), taken with std::shared_lock for readers and std::unique_lock for writers.
• Go — sync.RWMutex, with RLock()/RUnlock() for readers and Lock()/Unlock() for writers.
• Python — the standard library has no read-write lock. You either build one from threading.Condition (about twenty lines) or reach for a library. In CPython the GIL already serialises bytecode, so the win is smaller than you'd expect for pure-Python work.

The alternative: don't share mutable state at all

Before adding a read-write lock, consider making the data immutable and swapping whole snapshots instead. A writer builds a brand-new copy, then atomically publishes it by reassigning one reference; readers just grab the current reference and read it with no lock at all. That's copy-on-write — CopyOnWriteArrayList in Java, or a plain AtomicReference to an immutable map. Readers become completely free and can never see a half-finished update; the cost is a full copy per write, so it only suits data that is written rarely. The immutability lesson later in this phase goes deeper.

Reach for a read-write lock when...

• Reads vastly outnumber writes — a rough rule of thumb is 10:1 or better. A config cache, a routing table, an in-memory catalogue, a permissions map.
• The critical section is long enough to matter — parsing, scanning a collection, serialising a response. Letting ten of those run in parallel is a real win.
• The data must stay mutable in place — you can't just publish an immutable snapshot because the structure is large and updates are partial.

Skip it when...

• Writes are common — the write lock serialises everything anyway, so you pay the extra bookkeeping for no parallelism. A plain mutex is simpler and faster.
• The critical section is tiny — one field read, one counter bump. Use a plain mutex, or an atomic variable and skip locking entirely.
• The data is small and rarely written — copy-on-write or an immutable snapshot behind an atomic reference gives readers a completely lock-free path.
• You haven't measured — reach for the simple mutex first and only upgrade when a profiler shows read contention.