# Reader/reader blocking in reader/writer locks

DevFeed: [Reader/reader blocking in reader/writer locks](<https://devfeed.tech/articles/reader-reader-blocking-in-reader-writer-locks-21963.md>)

Original publisher: [Read original article](<https://blog.nelhage.com/post/rwlock-contention/>)

Author: Nelson Elhage

Published: 2019-05-07T15:00:00Z

Content type: article

Language: en

Sources: [Nelson Elhage](<https://devfeed.tech/sources/nelson-elhage.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [blocking](<https://devfeed.tech/tags/blocking.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [locks](<https://devfeed.tech/tags/locks.md>), [systems](<https://devfeed.tech/tags/systems.md>), [thread](<https://devfeed.tech/tags/thread.md>), [threads](<https://devfeed.tech/tags/threads.md>)

## AI overview

The article explains how writer-priority reader/writer locks can cause readers to block behind other readers. When a writer is waiting, new readers cannot acquire the lock until that writer completes, so a long-running reader can trigger severe pauses and throughput loss even under a small write load.

## Source excerpt

Abstract In writer-priority reader/writer locks, as soon as a single writer enters the acquisition queue, all future accesses block behind any in-flight reads. Thus, if any readers hold the lock for extended periods of time, this can lead to extreme pauses and loss of throughput given even a very small number of writers. This phenomenon is well-known in certain systems engineering communities (e.g. among some kernel or database developers), but is often surprising when first encountered, and has important implications for the design of such systems.