Java ReentrantReadWriteLocks – how to safely acquire write lock when in a read lock?

by

This is an old question, but here’s both a solution to the problem, and some background information.

As others have pointed out, a classic readers-writer lock (like the JDK ReentrantReadWriteLock) inherently does not support upgrading a read lock to a write lock, because doing so is susceptible to deadlock.

If you need to safely acquire a write lock without first releasing a read lock, there is a however a better alternative: take a look at a read-write-update lock instead.

I’ve written a ReentrantReadWrite_Update_Lock, and released it as open source under an Apache 2.0 license here. I also posted details of the approach to the JSR166 concurrency-interest mailing list, and the approach survived some back and forth scrutiny by members on that list.

The approach is pretty simple, and as I mentioned on concurrency-interest, the idea is not entirely new as it was discussed on the Linux kernel mailing list at least as far back as the year 2000. Also the .Net platform’s ReaderWriterLockSlim supports lock upgrade also. So effectively this concept had simply not been implemented on Java (AFAICT) until now.

The idea is to provide an update lock in addition to the read lock and the write lock. An update lock is an intermediate type of lock between a read lock and a write lock. Like the write lock, only one thread can acquire an update lock at a time. But like a read lock, it allows read access to the thread which holds it, and concurrently to other threads which hold regular read locks. The key feature is that the update lock can be upgraded from its read-only status, to a write lock, and this is not susceptible to deadlock because only one thread can hold an update lock and be in a position to upgrade at a time.

This supports lock upgrade, and furthermore it is more efficient than a conventional readers-writer lock in applications with read-before-write access patterns, because it blocks reading threads for shorter periods of time.

Example usage is provided on the site. The library has 100% test coverage and is in Maven central.

More Related Contents:

  1. ConcurrentModificationException for ArrayList [duplicate]
  2. Why is creating a Thread said to be expensive?
  3. Why is i++ not atomic?
  4. Synchronization vs Lock
  5. Java Wait and Notify: IllegalMonitorStateException
  6. Are static variables shared between threads?
  7. Prime numbers by Eratosthenes quicker sequential than concurrently?
  8. Is iterating ConcurrentHashMap values thread safe?
  9. How to asynchronously call a method in Java
  10. How to solve the “Double-Checked Locking is Broken” Declaration in Java?
  11. Executors.newCachedThreadPool() versus Executors.newFixedThreadPool()
  12. Is it safe to get values from a java.util.HashMap from multiple threads (no modification)?
  13. Concurrent threads adding to ArrayList at same time – what happens?
  14. What is mutex and semaphore in Java ? What is the main difference?
  15. CountDownLatch vs. Semaphore
  16. Parallel execution of directed acyclic graph of tasks
  17. Javafx: Difference between javafx.concurent and Platform.runLater?
  18. RxJava instead of AsyncTask?
  19. What’s the difference between a Future and a Promise?
  20. Programmatic deadlock detection in java
  21. When should we use Java’s Thread over Executor?
  22. Run Java Threads sequentially
  23. WAITING at sun.misc.Unsafe.park(Native Method)
  24. ThreadPoolExecutor Block When its Queue Is Full?
  25. Java : Does wait() release lock from synchronized block
  26. How Threadpool re-use Threads and how it works
  27. AtomicInteger lazySet vs. set
  28. Not thread-safe Object publishing
  29. notifyAll() throws IllegalMonitorStateException
  30. Will a chain of method calls (CompletableFuture API) execute asynchronously if the first method in a chain is asynchronous?

Leave a Comment