This is the 21st day of my participation in Gwen Challenge

Read-write lock

Read/write locks are composed of read locks and write locks. Read locks are used to read only shared resources, and write locks are used to modify shared resources. Therefore, read/write locks are suitable for scenarios where read and write operations can be clearly distinguished.

How read/write locks work:

  • When a write lock is not held by a thread, multiple threads can concurrently hold the read lock, which greatly improves the access efficiency of shared resources. Because the read lock is used to read shared resources, multiple threads holding the read lock at the same time do not damage the data of shared resources.
  • However, once the write lock is held by a thread, the read-lock operation of the reader thread is blocked, and the read-lock operation of other writer threads is blocked.
  • Therefore, a write lock is an exclusive lock because only one thread can hold a write lock at any time, similar to mutex and spin locks, while a read lock is a shared lock because a read lock can be held by multiple threads at the same time.
  • Based on the operation principle of read-write lock, we can find that read-write lock can play an advantage in the scenario of reading more and writing less.

Read the first lock

The read-first lock is expected to be held by more threads to improve read-thread concurrency. It works like this: when reader thread A first holds the read lock, writer thread B blocks when acquiring the write lock. During the blocking process, subsequent reader thread C can still acquire the read lock successfully. Finally, writer thread B can obtain the read lock successfully until reader thread A and C release the read lock. The diagram below:

Write first lock

A write-first lock is a priority service writer thread and works like this: When read the threads to hold the first read lock, A writer thread B at the time of access to write locks, will be blocked, and in the process of blocking, subsequent to read threads to obtain C lock when they fail, then read the thread will be blocked in C read lock operation, such as long as read the thread to release A read lock, write thread B read lock can get success. The diagram below:

Thread hunger caused by read – and write-first locks

  • Thread hunger: A condition in which a thread cannot execute because it cannot access the resources it needs.

Read-first locks are better for read-thread concurrency, but not without problems. Let’s imagine that if a reader thread holds the read lock all the time, the writer thread will never hold the write lock, which leads to writer thread hunger. A write-first lock ensures that a writer thread will not starve to death, but if a writer thread keeps holding the write lock, the reader thread will starve to death.

Since either the read-write lock or the read-write lock is likely to starve to death, let’s not take sides and have a fair read-write lock. A fairly simple way to do this is to queue up the thread that acquires the lock. Both the writer thread and the reader thread are locked on a first-in, first-out basis, so that the reader thread can still be concurrent and will not be hungry.

ReentrantReadWriteLock

Java implements read/write locks through the ReentrantReadWriteLock class. The mutually exclusive mechanism of read and write locks is controlled by the JVM. The following is a simple use of the ReentrantReadWriteLock class.

/** * create a read-write lock * it is a read-write lock, when used, need to convert */
private ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();

// Get read lock
rwLock.readLock().lock();

// Release the read lock
rwLock.readLock().unlock();

// Create a write lock
rwLock.writeLock().lock();

// Write lock is released
rwLock.writeLock().unlock();
Copy the code