Anatomy of a Synchronizer

The interfaces of ReentrantLock and Semaphore have a lot in common. Both classes act as a "gate", allowing only a limited number of threads to pass at a time; threads arrive at the gate and are allowed through (lock or acquire returns successfully), are made to wait (lock or acquire blocks), or are turned away (tryLock or tryAcquire returns false, indicating that the lock or permit did not become available in the time allowed). Further, both allow interruptible, uninterruptible, and timed acquisition attempts, and both allow a choice of fair or nonfair queueing of waiting threads.

Given this commonality, you might think that Semaphore was implemented on top of ReentrantLock, or perhaps ReentrantLock was implemented as a Semaphore with one permit. This would be entirely practical; it is a common exercise to prove that a counting semaphore can be implemented using a lock (as in SemaphoreOnLock in Listing 14.12) and that a lock can be implemented using a counting semaphore.

In actuality, they are both implemented using a common base class, Abstract-QueuedSynchronizer (AQS)as are many other synchronizers. AQS is a framework for building locks and synchronizers, and a surprisingly broad range of synchronizers can be built easily and efficiently using it. Not only are ReentrantLock and Semaphore built using AQS, but so are CountDownLatch, ReentrantReadWriteLock, SynchronousQueue,[12] and FutureTask.

[12] Java6 replaces the AQS-based SynchronousQueue with a (more scalable) nonblocking version.

Listing 14.11. Bounded Buffer Using Explicit Condition Variables.

@ThreadSafe
public class ConditionBoundedBuffer {
 protected final Lock lock = new ReentrantLock();
 // CONDITION PREDICATE: notFull (count < items.length)
 private final Condition notFull = lock.newCondition();
 // CONDITION PREDICATE: notEmpty (count > 0)
 private final Condition notEmpty = lock.newCondition();
 @GuardedBy("lock")
 private final T[] items = (T[]) new Object[BUFFER_SIZE];
 @GuardedBy("lock") private int tail, head, count;

 // BLOCKS-UNTIL: notFull
 public void put(T x) throws InterruptedException {
 lock.lock();
 try {
 while (count == items.length)
 notFull.await();
 items[tail] = x;
 if (++tail == items.length)
 tail = 0;
 ++count;
 notEmpty.signal();
 } finally {
 lock.unlock();
 }
 }

 // BLOCKS-UNTIL: notEmpty
 public T take() throws InterruptedException {
 lock.lock();
 try {
 while (count == 0)
 notEmpty.await();
 T x = items[head];
 items[head] = null;
 if (++head == items.length)
 head = 0;
 --count;
 notFull.signal();
 return x;
 } finally {
 lock.unlock();
 }
 }
}

Listing 14.12. Counting Semaphore Implemented Using Lock.

// Not really how java.util.concurrent.Semaphore is implemented
@ThreadSafe
public class SemaphoreOnLock {
 private final Lock lock = new ReentrantLock();
 // CONDITION PREDICATE: permitsAvailable (permits > 0)
 private final Condition permitsAvailable = lock.newCondition();
 @GuardedBy("lock") private int permits;

 SemaphoreOnLock(int initialPermits) {
 lock.lock();
 try {
 permits = initialPermits;
 } finally {
 lock.unlock();
 }
 }

 // BLOCKS-UNTIL: permitsAvailable
 public void acquire() throws InterruptedException {
 lock.lock();
 try {
 while (permits <= 0)
 permitsAvailable.await();
 --permits;
 } finally {
 lock.unlock();
 }
 }

 public void release() {
 lock.lock();
 try {
 ++permits;
 permitsAvailable.signal();
 } finally {
 lock.unlock();
 }
 }
}

AQS handles many of the details of implementing a synchronizer, such as FIFO queuing of waiting threads. Individual synchronizers can define flexible criteria for whether a thread should be allowed to pass or be required to wait.

Using AQS to build synchronizers offers several benefits. Not only does it substantially reduce the implementation effort, but you also needn't pay for multiple points of contention, as you would when constructing one synchronizer on top of another. In SemaphoreOnLock, acquiring a permit has two places where it might blockonce at the lock guarding the semaphore state, and then again if a permit is not available. Synchronizers built with AQS have only one point where they might block, reducing context-switch overhead and improving throughput. AQS was designed for scalability, and all the synchronizers in java.util.concurrent that are built with AQS benefit from this.


Introduction

Part I: Fundamentals

Thread Safety

Sharing Objects

Composing Objects

Building Blocks

Part II: Structuring Concurrent Applications

Task Execution

Cancellation and Shutdown

Applying Thread Pools

GUI Applications

Part III: Liveness, Performance, and Testing

Avoiding Liveness Hazards

Performance and Scalability

Testing Concurrent Programs

Part IV: Advanced Topics

Explicit Locks

Building Custom Synchronizers

Atomic Variables and Nonblocking Synchronization

The Java Memory Model



Java Concurrency in Practice
Java Concurrency in Practice
ISBN: 0321349601
EAN: 2147483647
Year: 2004
Pages: 141

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net