Problem statement
Design the object model and public API for a reader-writer lock: an in-process synchronization primitive that lets many threads read a shared resource concurrently but grants a writer exclusive access. It is a library building block other code acquires around a guarded resource, all inside a single runtime.
Operating context. One process, many threads. A caller acquires read access (shared) or write access (exclusive), does its work, and releases. The lock must decide a fairness policy so a steady stream of readers cannot starve a waiting writer forever. Callers expect a timed acquire that gives up rather than block indefinitely, and the primitive should support write-to-read downgrade for a thread that already holds the write lock.
Out of scope. Distributed or cross-process locks, the resource the lock guards, deadlock detection across several locks held at once, the OS thread scheduler internals, and persistence of any kind.
What to produce. The class hierarchy (the lock, its read-view and write-view handles, the internal waiter bookkeeping), the public API each type exposes, and the lock's state machine (free, read-held with a count, write-held). Be explicit about how you signal only the eligible waiters when the lock frees, how the fairness policy is a pluggable seam, and how reentrancy and downgrade are tracked without violating mutual exclusion.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design LLD
- Concurrency Locks
- Concurrency Condition-Variables
- Concurrency Fairness
- Oop Interface-Design