Interfaces and classes providing a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors.
See: Description
Interface Summary | |
---|---|
Condition |
{@code Condition} factors out the {@code Object} monitor
methods (Object#wait() wait , Object#notify notify
and Object#notifyAll notifyAll ) into distinct objects to
give the effect of having multiple wait-sets per object, by
combining them with the use of arbitrary Lock implementations.
|
Lock | {@code Lock} implementations provide more extensive locking operations than can be obtained using {@code synchronized} methods and statements. |
ReadWriteLock |
A ReadWriteLock maintains a pair of associated locks , one for read-only operations and one for writing.
|
Class Summary | |
---|---|
ReentrantLock | A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using {@code synchronized} methods and statements, but with extended capabilities. |
ReentrantReadWriteLock | An implementation of ReadWriteLock supporting similar semantics to ReentrantLock. |
ReentrantReadWriteLock.ReadLock | The lock returned by method ReentrantReadWriteLock. |
ReentrantReadWriteLock.WriteLock | The lock returned by method ReentrantReadWriteLock. |
The Lock interface supports locking disciplines that differ in semantics (reentrant, fair, etc), and that can be used in non-block-structured contexts including hand-over-hand and lock reordering algorithms. The main implementation is ReentrantLock.
The ReadWriteLock interface similarly defines locks that may be shared among readers but are exclusive to writers. Only a single implementation, ReentrantReadWriteLock, is provided, since it covers most standard usage contexts. But programmers may create their own implementations to cover nonstandard requirements.
The Condition interface describes condition variables that may be associated with Locks. These are similar in usage to the implicit monitors accessed using Object.wait, but offer extended capabilities. In particular, multiple Condition objects may be associated with a single Lock. To avoid compatibility issues, the names of Condition methods are different than the corresponding Object versions.
Since: 1.5