Build fluency in the vocabulary of a lock allowing many simultaneous readers but only one exclusive writer.
0 / 5 completed
1 / 5
At standup, a dev mentions a lock that allows any number of threads to hold it simultaneously for reading, but requires a thread to hold it exclusively, with no other reader or writer present, before it can write. What is this kind of lock called?
A read-write lock is exactly this: it allows any number of threads to hold it simultaneously for reading, since concurrent reads can't corrupt anything, but requires a thread to acquire it exclusively, with no other reader or writer holding it at the same time, before it's allowed to write. A deadlock is an unrelated concurrency failure about threads permanently blocked on each other, not about how many readers or writers a single lock allows at once. This many-readers-or-one-writer rule is exactly what lets a read-write lock offer much higher throughput than a plain mutex on a workload dominated by reads.
2 / 5
During a design review, the team switches a heavily-read, rarely-written shared cache from a plain mutex to a read-write lock. Which capability does this switch provide?
Switching to a read-write lock here provides much higher read throughput, since many threads can now hold the lock simultaneously for reading, running concurrently instead of each read having to wait its turn behind every other thread the way a plain mutex would force. A plain mutex only ever lets one thread hold it at a time, regardless of whether that thread only intends to read, forcing reads to serialize even though concurrent reads are perfectly safe. This concurrent-reader capability is exactly why a read-write lock is the standard upgrade for a shared resource that's read far more often than it's written.
3 / 5
In a code review, a dev notices a shared configuration cache, read constantly by many threads and written only rarely, is protected by a single plain mutex that forces every read to wait behind every other read and write, one at a time. What does this represent?
This is a missed read-write-lock opportunity, since a plain mutex forces every single read to wait behind every other read and write, one thread at a time, even though concurrent reads of a rarely-written configuration cache are perfectly safe, when a read-write lock would let all those frequent reads run concurrently and only serialize the genuinely rare writes. A cache eviction policy is an unrelated concept about discarded cache entries. This unnecessary read-serialization pattern is exactly the kind of throughput bottleneck a read-write lock is designed to remove for a read-heavy, write-rare shared resource.
4 / 5
An incident report shows a shared configuration cache's read throughput collapsed under heavy concurrent load, because it was protected by a single plain mutex forcing every read to wait behind every other read and write, even though writes to that cache were extremely rare. What practice would prevent this?
Replacing the plain mutex with a read-write lock lets many threads hold the lock concurrently for reading, only serializing the genuinely rare writes, which is exactly the fix for the read-throughput collapse described in this incident. Continuing to protect the cache with a single plain mutex regardless of its overwhelmingly read-heavy access pattern is exactly what caused reads to serialize needlessly under heavy load. This read-write-lock upgrade is the standard fix once a shared resource's actual access pattern is confirmed to be dominated by reads with only occasional writes.
5 / 5
During a PR review, a teammate asks why the team reaches for a read-write lock instead of just using a plain mutex everywhere, given that a read-write lock is more complex to reason about. What is the reasoning?
A plain mutex forces every single access, even simultaneous reads that can never actually conflict with each other, to serialize one thread at a time, while a read-write lock lets any number of readers run concurrently, only forcing serialization for the genuinely conflicting case of a write. This difference matters a great deal once reads vastly outnumber writes, since a plain mutex would otherwise be needlessly limiting throughput on the overwhelming majority of accesses. The tradeoff is a read-write lock's somewhat more complex implementation and slightly higher per-acquisition overhead, which is well worth it for a resource that's read far more often than it's written.