Interesting perspective, thanks. I didn’t think about this before.

I removed a mention of ReadWriteLock from item 7.2 and added a new item 7.5 that says that ReadWriteLock might be beneficial as well as harmful.

I have no data but my gut feeling (although there is definitely some wishful thinking here) is that read/write lock (specifically j.u.c.l.ReentrantReadWriteLock) is not nearly as bad that it only starts to pay off when protected operations are as slow as I/O (millisecond range? or you meant SSD disk I/O?) I want to believe that it’s worthwhile to read/write lock operations that take 100–200 ns, maybe 1 us. I would really like to run some benchmarks to build some intuition. However, there are so many factors (reader threads count, writer threads count, lengths of read and write ops, spaces between read and write ops) that are all important that makes the idea of synthetic benchmarking both intimidating and questionably practical. I would entirely disregard the benchmarking results from the blog post that you linked because it’s so old, about .NET and the benchmarking methodology is not verifiable but looks quite suspicious on the surface.

ReentrantReadWriteLock might appear to be pretty slow, but there should be ways to improve its performance:

• Ditch ThreadLocal read count, see JDK-6625724
• Speculative read lock acquisition via addAndGet() (with “red zones” to protect against overflow/underflow), instead of read-check-CAS. A similar idea is used in this code.