Read-Write and Optimistic Locks

## The idea A plain mutex treats all access as conflicting. But two threads that only *read* shared state cannot corrupt it or observe each other's partial updates — the conflict only arises with a writer. A **readers-writer lock** (also shared/exclusive lock) encodes that distinction directly. It offers two acquisition modes: | Requested \ Held | nothing | shared | exclusive | |---|---|---|---| | **shared** | grant | grant | block | | **exclusive** | grant | block | block | The caller declares its intent. Readers take shared mode and proceed together; a writer takes exclusive mode and waits until every reader has left, then locks everyone out for the duration of its update. ## What it costs A mutex, uncontended, is roughly one atomic read-modify-write plus one store to release. A readers-writer lock must track *how many* readers are inside so the last one out can release the lock and let a waiting writer in. That means: - Shared acquire and release are each an atomic update to a shared counter — two atomic operations instead of one for a read. - That counter lives on one cache line, and **every reader on every core writes to it**. Under high read concurrency this line ping-pongs between cores, and the lock itself becomes the contention point even though the readers never actually conflict logically. - The state machine (readers present, writer waiting, writer active) is more complex, so implementations tend to have longer fast paths. Hence the standard rule of thumb: a readers-writer lock wins when reads dominate heavily (often quoted as roughly 90% or more of acquisitions) *and* critical sections are long enough — microseconds, not nanoseconds — for the parallelism to outweigh the bookkeeping. For nanosecond-scale reads, the counter contention alone can make it slower than the mutex it replaced. ## Correctness obligations - **Shared means read-only, and the lock cannot enforce it.** Nothing stops a thread from mutating state while holding shared mode; if it does, you have a data race among the concurrent shared holders, and it will be subtle because 'the code took the lock'. - **Do not leak references.** Returning a mutable internal object to a caller who then uses it after releasing the read lock defeats the whole scheme. Return copies, immutable views, or perform the work inside the critical section. - **Consistency spans the whole section.** Two separate read acquisitions can straddle a writer, so any invariant across two reads must be held in one shared acquisition. - **Writers still need the same discipline as with a mutex**: keep the exclusive section short and never block on I/O inside it, since it excludes every reader in the system. ## Where it genuinely fits Good fits are read-mostly reference data with occasional refresh: routing or configuration tables, permission and feature-flag caches, in-memory indexes rebuilt periodically, metadata that many request threads consult and a background task updates. In each, reads are frequent and non-trivial (a lookup plus some traversal), and writes are rare. Poor fits are counters and tiny fields (the read is shorter than the lock overhead — use an atomic), write-heavy structures (the exclusive mode dominates and you have paid extra for nothing), and cases where the data is small enough to publish as an immutable snapshot that readers take with no lock at all. ## Fairness enters immediately One question the compatibility rule does not answer: when a writer is waiting and a *new* reader arrives while readers are still inside, is the newcomer admitted? Admitting it maximises read throughput but can keep the writer waiting indefinitely; blocking it protects the writer at some cost to readers. That policy choice — reader-preference versus writer-preference versus fair — is a defining property of any real readers-writer lock, and you should know which one you are using before deploying it under load.