Java Reference
In-Depth Information
FutureTask
uses the AQS synchronization state to hold the task status—running, com-
pleted, or cancelled. It also maintains additional state variables to hold the result of the com-
putation or the exception it threw. It further maintains a reference to the thread that is running
the computation (if it is currently in the running state), so that it can be interrupted if the task
is cancelled.
14.6.4. ReentrantReadWriteLock
The interface for
ReadWriteLock
suggests there are two locks—a reader lock and a writer
lock—but in the AQS-based implementation of
ReentrantReadWriteLock
, a single
AQS subclass manages both read and write locking.
ReentrantRead-WriteLock
uses
16 bits of the state for the write-lock count, and the other 16 bits for the read-lock count.
Operations on the read lock use the shared acquire and release methods; operations on the
write lock use the exclusive acquire and release methods.
Internally, AQS maintains a queue of waiting threads, keeping track of whether a thread has
requested exclusive or shared access. In
ReentrantRead-WriteLock
, when the lock
becomes available, if the thread at the head of the queue was looking for write access it will
get it, and if the thread at the head of the queue was looking for read access, all queued
threads up to the first writer will get it.
[15]
Summary
If you need to implement a state-dependent class—one whose methods must block if a state-
based precondition does not hold—the best strategy is usually to build upon an existing
library class such as
Semaphore
,
BlockingQueue
, or
CountDownLatch
, as in
ValueLatch
on page
187
. However, sometimes existing library classes do not provide a
sufficient foundation; in these cases, you can build your own synchronizers using intrinsic
condition queues, explicit
Condition
objects, or
AbstractQueuedSynchronizer
.
Intrinsic condition queues are tightly bound to intrinsic locking, since the mechanism for
managing state dependence is necessarily tied to the mechanism for ensuring state consisten-
cy. Similarly, explicit
Condition
s are tightly bound to explicit
Lock
s, and offer an exten-
ded feature set compared to intrinsic condition queues, including multiple wait sets per lock,
interruptible or uninterruptible condition waits, fair or nonfair queuing, and deadline-based
waiting.
