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
As we saw in Chapter 13 , explicit Lock s can be useful in some situations where intrinsic
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.
Search WWH ::




Custom Search