Java Reference
In-Depth Information
blocked one or more waiting threads. This explicit API requirement makes it harder to “for-
get” to notify on some state transitions.
14.3. Explicit Condition Objects
locks are too inflexible. Just as
Lock
is a generalization of intrinsic locks,
Condition
(see
Listing 14.10
)
is a generalization of intrinsic condition queues.
Intrinsic condition queues have several drawbacks. Each intrinsic lock can have only one
associated condition queue, which means that in classes like
BoundedBuffer
multiple
threads might wait on the same condition queue for different condition predicates, and the
most common pattern for locking involves exposing the condition queue object. Both of these
factors make it impossible to enforce the uniform waiter requirement for using
notifyAll
.
If you want to write a concurrent object with multiple condition predicates, or you want to ex-
ercise more control over the visibility of the condition queue, the explicit
Lock
and
Condi-
tion
classes offer a more flexible alternative to intrinsic locks and condition queues.
A
Condition
is associated with a single
Lock
, just as a condition queue is associated with
a single intrinsic lock; to create a
Condition
, call
Lock.newCondition
on the associ-
ated lock. And just as
Lock
offers a richer feature set than intrinsic locking,
Condition
offers a richer feature set than intrinsic condition queues: multiple wait sets per lock, inter-
ruptible and uninterruptible condition waits, deadline-based waiting, and a choice of fair or
nonfair queueing.
Listing 14.10.
Condition
Interface.