> So reader/writer locks tend to rely on the additional concurrency, and on readers not blocking other readers. > software has a constant tendency to get slowe

> So reader/writer locks tend to rely on the additional concurrency, and on readers not blocking other readers. > software has a constant tendency to get slower, absent deliberate and careful efforts to hold the line, as developers add features and complexity. And if slower processes don’t immediately impact performance (because they only hold read locks), they’re more likely to go unnoticed. Thus, it’s not unlikely that over time read lock durations will creep upwards, mostly without effect, until one happens to coincide with an attempt to grab a write lock. For me, the takeaway here is to maintain discipline in software regarding locking behavior. It's almost always a bad idea to hold a lock (rw or not) for an extended period of time. Notably, this is how the Linux kernel developers responded to the case linked in the discussion of mmap_sem - the operation quadratic in number of threads was thrown out to avoid holding the rwsem for extended periods of time. Also, re "and the lock is held by readers for a significant length of time": I would imagine that Rusty Russell would consider a few microseconds a "significant length of time" and wonder if you were insane if your software held a lock for 60 seconds.