Package com.semedy.reasoner.core.locks

Class ReentrantReadWriteUpdateLock

java.lang.Object
com.semedy.reasoner.core.locks.ReentrantReadWriteUpdateLock
All Implemented Interfaces:
ReadWriteUpdateLock, ReadWriteLock
public class ReentrantReadWriteUpdateLock extends Object implements ReadWriteUpdateLock
An implementation of ReadWriteUpdateLock, extending the functionality of the JDK ReentrantReadWriteLock with an update lock in addition to the read and write lock, supporting upgrade from read-only operation to writing status, and downgrade again.

Background - JDK ReentrantReadWriteLock

The ReentrantReadWriteLock in the JDK classifies threads as needing to read-without-write, write-without-read, or write-before-read. Threads can obtain the read lock, or the write lock, and if they have the write lock, they can downgrade it to a read lock. But the key limitation is that it does not support read-before-write: threads which hold a read lock cannot upgrade it to a write lock. Imagine a data structure, let's say a cache, where most requests are to read data, but also there is a maintenance thread responsible for periodically traversing the data structure to find and update stale entries. The maintenance thread thus would mostly read entries while traversing the data structure, and periodically it might encounter entries which need to be updated. If a classic ReentrantReadWriteLock is used to control access, the write-before-read support afforded by that lock would be insufficient, because if at any point the thread updated an entry and then downgraded its write lock to a read lock, it would not be able to upgrade it again to a write lock if it found other stale entries. So the maintenance thread would need to hold the write lock for its entire traversal of the data structure, preventing read access for that entire duration.

ReentrantReadWriteUpdateLock Overview

The third type of lock provided, an update lock, is like a super read lock. It behaves like a read lock, in that it allows read access to the thread which holds it, and it concurrently "plays nice" with other threads which hold regular read locks, allowing those threads concurrent read access. The key difference is that the update lock can be upgraded from its read-only status, to a write lock. Thus it supports read-before-write usage. Also the write lock can be downgraded again to an update lock, write-before-read usage. A restriction however is that, similar to the write lock, only one thread may acquire the update lock at a time. This is sufficient in situations like the example above, to allow read-mostly, write-occasionally threads to operate on the data structure without blocking access to read-only threads most of the time: upgrading to the write lock only for the short periods in which they need it, before downgrading to the update lock again. As such it can reduce the latency for read-only requests, and increase concurrency in applications which otherwise would use a read-write lock. * An IllegalStateException will be thrown if a thread holding a regular read lock tries to acquire the update or write lock, or if a thread holding the update or write lock tries to acquire a regular read lock.
Author:
Niall Gallagher

  • Constructor Details

    • ReentrantReadWriteUpdateLock

      public ReentrantReadWriteUpdateLock()

  • Method Details

    • updateLock

      public Lock updateLock()
      Description copied from interface: ReadWriteUpdateLock
      Returns a lock which allows reading and which may also be upgraded to a lock allowing writing.
      Specified by:
      updateLock in interface ReadWriteUpdateLock
      Returns:
      a lock which allows reading and which may also be upgraded to a lock allowing writing.

    • readLock

      public Lock readLock()
      Specified by:
      readLock in interface ReadWriteLock

    • writeLock

      public Lock writeLock()
      Specified by:
      writeLock in interface ReadWriteLock