Java util concurrent locks reentrantreadwritelock readlock

Java util concurrent locks reentrantreadwritelock readlock

Acquires the read lock. Acquires the read lock if the write lock is not held by another thread and returns immediately. If the write lock is held by another thread then the current thread becomes disabled for thread scheduling purposes and lies dormant until the read lock has been acquired.

lockInterruptibly

• The read lock is acquired by the current thread; or
• Some other thread interrupts the current thread.

• has its interrupted status set on entry to this method; or
• is interrupted while acquiring the read lock,

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock.

tryLock

Acquires the read lock only if the write lock is not held by another thread at the time of invocation. Acquires the read lock if the write lock is not held by another thread and returns immediately with the value true . Even when this lock has been set to use a fair ordering policy, a call to tryLock() will immediately acquire the read lock if it is available, whether or not other threads are currently waiting for the read lock. This «barging» behavior can be useful in certain circumstances, even though it breaks fairness. If you want to honor the fairness setting for this lock, then use tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption). If the write lock is held by another thread then this method will return immediately with the value false .

tryLock

public boolean tryLock​(long timeout, TimeUnit unit) throws InterruptedException

Acquires the read lock if the write lock is not held by another thread within the given waiting time and the current thread has not been interrupted. Acquires the read lock if the write lock is not held by another thread and returns immediately with the value true . If this lock has been set to use a fair ordering policy then an available lock will not be acquired if any other threads are waiting for the lock. This is in contrast to the tryLock() method. If you want a timed tryLock that does permit barging on a fair lock then combine the timed and un-timed forms together:

 if (lock.tryLock() || lock.tryLock(timeout, unit))

• The read lock is acquired by the current thread; or
• Some other thread interrupts the current thread; or
• The specified waiting time elapses.

If the read lock is acquired then the value true is returned.

• has its interrupted status set on entry to this method; or
• is interrupted while acquiring the read lock,

If the specified waiting time elapses then the value false is returned. If the time is less than or equal to zero, the method will not wait at all.

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock, and over reporting the elapse of the waiting time.

unlock

Attempts to release this lock. If the number of readers is now zero then the lock is made available for write lock attempts. If the current thread does not hold this lock then IllegalMonitorStateException is thrown.

newCondition

toString

Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2023, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.

Источник

Java util concurrent locks reentrantreadwritelock readlock

Lock implementations provide more extensive locking operations than can be obtained using synchronized methods and statements. They allow more flexible structuring, may have quite different properties, and may support multiple associated Condition objects. A lock is a tool for controlling access to a shared resource by multiple threads. Commonly, a lock provides exclusive access to a shared resource: only one thread at a time can acquire the lock and all access to the shared resource requires that the lock be acquired first. However, some locks may allow concurrent access to a shared resource, such as the read lock of a ReadWriteLock . The use of synchronized methods or statements provides access to the implicit monitor lock associated with every object, but forces all lock acquisition and release to occur in a block-structured way: when multiple locks are acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in which they were acquired. While the scoping mechanism for synchronized methods and statements makes it much easier to program with monitor locks, and helps avoid many common programming errors involving locks, there are occasions where you need to work with locks in a more flexible way. For example, some algorithms for traversing concurrently accessed data structures require the use of «hand-over-hand» or «chain locking»: you acquire the lock of node A, then node B, then release A and acquire C, then release B and acquire D and so on. Implementations of the Lock interface enable the use of such techniques by allowing a lock to be acquired and released in different scopes, and allowing multiple locks to be acquired and released in any order. With this increased flexibility comes additional responsibility. The absence of block-structured locking removes the automatic release of locks that occurs with synchronized methods and statements. In most cases, the following idiom should be used:

 Lock l = . ; l.lock(); try < // access the resource protected by this lock >finally

When locking and unlocking occur in different scopes, care must be taken to ensure that all code that is executed while the lock is held is protected by try-finally or try-catch to ensure that the lock is released when necessary. Lock implementations provide additional functionality over the use of synchronized methods and statements by providing a non-blocking attempt to acquire a lock ( tryLock() ), an attempt to acquire the lock that can be interrupted ( lockInterruptibly() , and an attempt to acquire the lock that can timeout ( tryLock(long, TimeUnit) ). A Lock class can also provide behavior and semantics that is quite different from that of the implicit monitor lock, such as guaranteed ordering, non-reentrant usage, or deadlock detection. If an implementation provides such specialized semantics then the implementation must document those semantics. Note that Lock instances are just normal objects and can themselves be used as the target in a synchronized statement. Acquiring the monitor lock of a Lock instance has no specified relationship with invoking any of the lock() methods of that instance. It is recommended that to avoid confusion you never use Lock instances in this way, except within their own implementation. Except where noted, passing a null value for any parameter will result in a NullPointerException being thrown.

Memory Synchronization

• A successful lock operation has the same memory synchronization effects as a successful Lock action.
• A successful unlock operation has the same memory synchronization effects as a successful Unlock action.

Implementation Considerations

The three forms of lock acquisition (interruptible, non-interruptible, and timed) may differ in their performance characteristics, ordering guarantees, or other implementation qualities. Further, the ability to interrupt the ongoing acquisition of a lock may not be available in a given Lock class. Consequently, an implementation is not required to define exactly the same guarantees or semantics for all three forms of lock acquisition, nor is it required to support interruption of an ongoing lock acquisition. An implementation is required to clearly document the semantics and guarantees provided by each of the locking methods. It must also obey the interruption semantics as defined in this interface, to the extent that interruption of lock acquisition is supported: which is either totally, or only on method entry. As interruption generally implies cancellation, and checks for interruption are often infrequent, an implementation can favor responding to an interrupt over normal method return. This is true even if it can be shown that the interrupt occurred after another action may have unblocked the thread. An implementation should document this behavior.

Method Summary

Источник

Class ReentrantReadWriteLock.ReadLock

Acquires the read lock only if the write lock is not held by another thread at the time of invocation.

Acquires the read lock if the write lock is not held by another thread within the given waiting time and the current thread has not been interrupted.

Methods declared in class java.lang.Object

Constructor Details

ReadLock

Method Details

lock

Acquires the read lock. Acquires the read lock if the write lock is not held by another thread and returns immediately. If the write lock is held by another thread then the current thread becomes disabled for thread scheduling purposes and lies dormant until the read lock has been acquired.

lockInterruptibly

• The read lock is acquired by the current thread; or
• Some other thread interrupts the current thread.

• has its interrupted status set on entry to this method; or
• is interrupted while acquiring the read lock,

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock.

tryLock

Acquires the read lock only if the write lock is not held by another thread at the time of invocation. Acquires the read lock if the write lock is not held by another thread and returns immediately with the value true . Even when this lock has been set to use a fair ordering policy, a call to tryLock() will immediately acquire the read lock if it is available, whether or not other threads are currently waiting for the read lock. This «barging» behavior can be useful in certain circumstances, even though it breaks fairness. If you want to honor the fairness setting for this lock, then use tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption). If the write lock is held by another thread then this method will return immediately with the value false .

tryLock

Acquires the read lock if the write lock is not held by another thread within the given waiting time and the current thread has not been interrupted. Acquires the read lock if the write lock is not held by another thread and returns immediately with the value true . If this lock has been set to use a fair ordering policy then an available lock will not be acquired if any other threads are waiting for the lock. This is in contrast to the tryLock() method. If you want a timed tryLock that does permit barging on a fair lock then combine the timed and un-timed forms together:

 if (lock.tryLock() || lock.tryLock(timeout, unit))

• The read lock is acquired by the current thread; or
• Some other thread interrupts the current thread; or
• The specified waiting time elapses.

If the read lock is acquired then the value true is returned.

• has its interrupted status set on entry to this method; or
• is interrupted while acquiring the read lock,

If the specified waiting time elapses then the value false is returned. If the time is less than or equal to zero, the method will not wait at all.

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock, and over reporting the elapse of the waiting time.

unlock

Attempts to release this lock. If the number of readers is now zero then the lock is made available for write lock attempts. If the current thread does not hold this lock then IllegalMonitorStateException is thrown.

newCondition

toString

Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples. Other versions.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2023, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.

Источник