Implement Reader-Writer Lock from Scratch

Many Readers, One Writer

Reader-writer locks optimize read-heavy workloads: concurrent readers proceed in parallel, writers take exclusive access. The lock must track active reader count and block writers until readers drain.

State Machine

Common implementation fields:

• reader_count guarded by an internal mutex
• writer_waiting flag to prevent writer starvation
• write_locked boolean for exclusive phase

For example, with 8 threads parsing a config file, all 8 may hold the read lock simultaneously; a writer updating the file waits until reader_count drops to 0.

Why This Matters in Production

POSIX's pthread_rwlock_t and Java's ReentrantReadWriteLock exist because read-mostly workloads like configuration caches and in-memory databases waste enormous throughput serializing readers behind a plain mutex. The writer-starvation problem you're asked to prevent here is a real, documented pitfall: naive Linux glibc rwlock implementations historically favored readers so heavily that writers could starve indefinitely under sustained read load.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will build rwlock_rdlock, rwlock_wrlock, and unlock paths from pthread-style primitives or your mutex. This exercise requires a test where readers overlap and a writer serializes updates without data races.