Query regarding read-write locks

Question

I am delving on the java concurrent APIs and trying to understand the usefulness of read-write locks. The javadoc says that a readwrite block maintains a pair of locks, one for read and the other for write operations. While the write lock is exclusive access by a thread, multiple threads can acquire the read lock. So if in the read section all we are doing is read operations and we are anyways providing multiple threads access, what is the need to have the readlock in the first place ? Is there a scenario when the readwrite lock is actually useful?

Answer 1

If you're reading the data in many threads you're likely not to see the latest changes to the data due to visibility issues. There are many layers where data can be cached on per-thread basis: diffent layers of CPU cache, RAM access buffers and so on. Havling read lock in place you may be sure, that you're always observing the latest state.

Write locks are even stronger, providing an atomicity of access along with the visibility of the latest changes.

The main reason to have different kind of locks here is to have an ability to obtain sufficient level of synchronization without introducing too much overhead and locks for other threads.

Is there a scenario when the readwrite lock is actually useful?

It's highly useful when you have some in-memory data (Array, Collection or whatever), which is queried a lot by different threads, but the updates of this data happens quite rarely. In this case having separate locks (read lock for queries and write lock for updates) may give you a significant performace benefit.

Answer 2

.... what is the need to have the readlock in the first place

While reading, you need to prevent a writer acquiring the lock ... until all readers have finished. But it is OK for another reader to acquire the lock.

While writing, you need to prevent a reader acquiring the lock ... until the writer has finished.

(In other words, there can be one writer, OR multiple readers holding locks ... but not both.)

For the purposes of describing this, it is helpful to describe the behaviour as being two locks. What actually happens under the hood ... is implementation specific.

---

Is there a scenario when the readwrite lock is actually useful?

Well yea. In any scenario where you can distinguish between threads that require shared read-only access and those that require exclusive read-write (or write-only), a ReadWrite lock allows more concurrency than a simple Lock or a primitive mutex.

Answer 3

The reason for having a read-only lock is that if some other thread has an object locked for writing, that object's state may be inconsistent, and so you don't want to start reading it with no lock at all. Obtaining a read lock ensures that (1) the object is in a consistent state while you're looking at it because no other thread is modifying it and (2) no other thread can start modifying it until you're through looking at it. We have the read lock as a separate type because if it's usual for lots of threads to read but to have few updates, then the readers can all be looking at the same time.