Writer-Priority Solution Using Dual Lightswitches

Key Insight
Writer-priority ensures that once a writer arrives, no new readers can enter until all waiting writers have finished. Useful when writes are time-critical.
Dual Lightswitch Pattern
Reader LightswitchnoReaders.wait() // blocked by writerreadSwitch.lock(noWriters)noReaders.signal()// read // readSwitch.unlock()Writer LightswitchwriteSwitch.lock(noReaders)noWriters.wait() // wait for readers// write //noWriters.signal() unlock(noReaders)
How Writer Priority Works
Two lightswitches: readSwitch for readers, writeSwitch for writers. First writer locks noReaders, blocking all new readers. Writers can then queue on noWriters. Only after all writers finish does noReaders unlock.
Why Two Lightswitches
writeSwitch: First writer arriving locks out new readers. Last writer leaving unlocks.
readSwitch: First reader entering (when no writers) locks out writers. Last reader leaving unlocks.
Trade-offs
Pros: Writers get priority. Critical updates happen faster. Fewer readers see stale data.
Cons: Readers can starve if writers are frequent. More complex code with two lightswitches.
Real-World Use
Database locks often use reader-writer locks with writer priority. Security patches, price updates, and configuration changes should not wait behind thousands of reads.
Warning: Writer priority can starve readers under heavy write load. Choose the priority scheme that matches your workload.

💡 Key Takeaways

✓Writer-priority ensures no new readers enter while any writer is waiting; useful for time-critical updates like security patches or price changes where stale reads are costly

✓Dual lightswitch structure: readSwitch coordinates readers holding noWriters, writeSwitch coordinates writers holding noReaders; groups block each other via crossed semaphores

✓Reader: noReaders.wait(), readSwitch.lock(noWriters), noReaders.signal(), critical section, readSwitch.unlock(noWriters); reader releases noReaders immediately after locking lightswitch

✓Writer: writeSwitch.lock(noReaders), noWriters.wait(), critical section, noWriters.signal(), writeSwitch.unlock(noReaders); first writer blocks readers, all writers share that block

✓Can cause reader starvation under continuous writer arrivals; production systems use hybrid policies with maximum reader wait time or fair mode (Java ReentrantReadWriteLock)

📌 Examples

1Stock trading: price update writers have priority over quote readers; stale price reads could cause arbitrage losses, so readers wait until price writer completes even if many readers are queued

2Dual lightswitch: 3 writers W1, W2, W3 arrive; W1 calls writeSwitch.lock which acquires noReaders; W2, W3 increment writeSwitch counter but do not block (first already holds noReaders); all 3 share the reader block

3Reader starvation prevention: set 100ms maximum reader wait; if writer queue is non-empty for >100ms, temporarily release noReaders to let 10 readers through, then re-acquire for writers

← Back to Readers-Writers Problem Overview