modern-multithreading-c-java

SEMAPHORE-BASED SOLUTIONS TO CONCURRENT PROGRAMMING PROBLEMS 107

/* read x */

mutex.lock(); --activeReaders;

if (activeReaders == 0)

writers_r_que.V(); // allow waiting writers, if any, to write mutex.unlock();

for writers r que; thus, the lead reader will have to wait for these writers to finish writing.

This solution is interesting because it violates the exit-before-wait pattern described earlier. As a rule, a thread will exit a critical section before blocking itself on a P() operation. However, lead readers violate this rule when they execute writers r que.P() without first executing mutex.V() to exit the critical section. This is a key part of the solution. Only a lead reader (i.e., when activeReaders == 1) can enter the queue for writers r que since any other readers are blocked by mutex.P() at the beginning of the read operation. When the lead reader is released by writers r que.V(), the lead reader allows the other waiting readers to enter the critical section by signaling mutex.V(). These other readers will not execute writers r que.P() since (activeReaders == 1) is true only for the lead reader. (Note that the name of the semaphore writers r que indicates that multiple writers but only one reader may be blocked on the semaphore.)

R<W.2 This strategy allows concurrent reading and generally gives writers a higher priority than readers. Readers have priority in the following situation: When a writer requests to write, if it is a lead writer (i.e., no other writer is writing or waiting), it waits until all readers that arrived earlier have finished reading. This strategy and strategy R>W.2 are symmetrical. The solution in Listing 3.13 for R<W.2 differs from the solution in Listing 3.12 for R>W.2 as follows:

žSemaphore readers w que is used to allow a lead writer to block readers. Only one writer (a lead writer) can be blocked in this queue.

žSemaphore writers r que is renamed writers que, since readers are never blocked in this queue. (When a reader executes writers que.P() in its entrysection, it will never block; why? See Exercise 3.3.)

žVariable waitingOrWritingWriters is used to count the number of waiting or writing writers. At the end of a write operation, readers are permitted to read only if there are no waiting or writing writers.

When a writer W executes Write():

žIf one or more other writers are waiting for readers to finish, W is blocked on mutex w.

žIf no writer is writing or waiting, W is a lead writer, so W executes readers w que.P(). (If a writer is writing, waitingOrWritingWriters will be greater than 1 after it is incremented by W, so W will not execute

readers w que.P().) If a reader is reading, W will be blocked on readers w que behind any waiting readers; otherwise, W can start writing, and readers will be blocked when they execute readers w que.P().

žW can be followed by a stream of writers. When the last of these writers finishes, it executes readers w que.V() to signal waiting readers. If a finishing writer always finds that another writer is waiting, readers will starve.

The use of readers w que ensures that readers that arrive before a lead writer have a higher priority. This is because readers and lead writers both call readers w que.P(), and they are served in FCFS order. When a reader blocked in readers w que is given permission to read, it executes readers w que.V() to signal the next waiting reader, who executes readers w que.V() to signal the next waiting reader, and so on. This cascaded wakeup continues until there are no more waiting readers or until the readers w que.V() operation wakes up a lead writer. The lead writer executes writers que.P() to block itself until the readers have finished. The last reader executes writers que.V() to signal the lead writer that readers have finished.

3.5.5 Simulating Counting Semaphores

Suppose that a system provides binary semaphores but not counting semaphores. Listing 3.14 shows how to use binary semaphores to implement the P() and

class countingSemaphore { private int permits = 0;

// provides mutual exclusion for permits

private binarySemaphore mutex = new binarySemaphore(1); // condition queue for threads blocked in P

private binarySemaphore delayQ = new binarySemaphore(0); public void P() {

mutex.P(); --permits;

if (permits < 0){ mutex.V(); delayQ.P();

}

else mutex.V();

}

public void V() { mutex.P(); ++permits;

if (permits <= 0) delayQ.V();

mutex.V();

}

}

Listing 3.14 Implementing counting semaphores by using P() and V() operations on binary semaphores.

V() operations in a countingSemaphore class. Here is a possible execution scenario for four threads T1, T2, T3, and T4 that are using a countingSemaphore s initialized to 0:

1.T1 executes s.P (): T1 decrements permits to −1 and has a context switch immediately after completing the mutex.V() operation but before it executes delayQ.P().

2.T2 executes s.P (): T2 decrements permits to −2 and has a context switch immediately after completing the mutex.V() operation but before it executes delayQ.P().

3.T3 executes s.V(): T3 increments permits to −1 and executes delayQ.V().

4.T4 executes s.V(): T4 increments permits to 0 and executes delayQ.V(). Since T3 just previously completed an s.V () operation in which the value of delayQ was incremented to 1, T4 is blocked at delayQ.V().

5.T1 resumes execution, completes delayQ.P(), and then completes its s.P() operation.

6. T4 resumes execution and completes its delayQ.V() operation.

7. T2 resumes execution, completes delayQ.P(), and then completes its s.P () operation.

In step 4, T4 executes s.V () and is blocked by the delayQ.V() operation. If V () operations for binary semaphores are redefined so that they never block the calling thread, this scenario would not execute correctly (see Exercise 3.5).

3.6 SEMAPHORES AND LOCKS IN JAVA

The Java language does not provide a semaphore construct, but Java’s builtin synchronization constructs can be used to simulate counting and binary semaphores. First, we describe how to create user-level semaphore and lock classes. Later, we extend them with the functions that are needed for testing and debugging. J2SE 5.0 (Java 2 Platform, Standard Edition 5.0) introduces package java.util.concurrent, which contains a collection of synchronization classes, including classes Semaphore and ReentrantLock. We also describe how to use these classes.

Following is an abstract class named semaphore:

public abstract class semaphore { protected abstract void P(); protected abstract void V();

protected semaphore(int initialPermits) {permits = initialPermits;} protected int permits;

}

Next we show a Java countingSemaphore class that extends class semaphore and provides implementations for methods P() and V().

3.6.1 Class countingSemaphore

The implementations of methods P() and V() in class countingSemaphore are based on Implementation 2 in Listing 3.3, which is reproduced here:

//Implementation 2 uses a queue of blocked threads. The value of permits may be

//negative.

P(): permits = permits - 1;

if (permits < 0) wait on a queue of blocked threads

V(): permits = permits + 1;

if (permits <= 0) notify one waiting thread;

To complete this implementation, we need to provide mutual exclusion for accessing shared variable permits and implementations for the wait and notify

operations. Java’s built-in synchronization constructs, which include operations wait and notify, make this easy to do.

Each Java object is associated with a built-in lock. If a thread calls a method on an object, and the method is declared with the synchronized modifier, the calling thread must wait until it acquires the object’s lock. Here are the declarations of synchronized methods P() and V() in class countingSemaphore:

public synchronized void P() {...}; public synchronized void V() {...};

Only one thread at a time can execute in the synchronized methods of an object. Java’s implementation of a synchronized method ensures that the object’s lock is properly acquired and released. If an object’s data members are only accessed in synchronized methods, the thread that owns the object’s lock has exclusive access to the object’s data members.

We can use Java’s wait operation to complete the implementation of P(). A thread must hold an object’s lock before it can execute a wait operation. (The use of synchronized ensures that this restriction is satisfied.) When a thread executes wait, it releases the object’s lock and waits in a wait set that is associated with the object. The thread waits until it is notified or interrupted. (A thread T is interrupted when another thread calls T.interrupt().) Here is the implementation of method P():

by throwing InterruptedException. This is why wait usually appears in a trycatch block. Since none of our programs use interrupts, we have elected to catch InterruptedException with an empty catch block instead of adding the clause “throws InterruptedException” to the header of method P(). Threads that call P() are thus not required to handle InterruptedException, which is convenient, but unsafe if interrupts are possible. We discuss interrupts again in Chapter 4.

A notify operation notifies one of the waiting threads, but not necessarily the one that has been waiting the longest or the one with the highest priority. If no threads are waiting, a notify operation does nothing. Here is method V() using Java’s notify operation:

public final class countingSemaphore extends semaphore {

public countingSemaphore(int initialPermits) {super(initialPermits);} synchronized public void P() {

permits--;

if (permits<0)

try { wait(); } catch (InterruptedException e) {}

}

synchronized public void V() { ++permits;

if (permits <=0) notify();

}

}

Listing 3.15 Java class countingSemaphore.

A notified thread must reacquire the lock before it can begin executing in the method. Furthermore, notified threads that are trying to reacquire an object’s lock compete with threads that have called a method of the object and are trying to acquire the lock for the first time. The order in which these notified and calling threads obtain the lock is unpredictable.

The complete implementation of class countingSemaphore is shown in Listing 3.15. Notice that this implementation does not allow threads that call P() to barge ahead of waiting threads and “steal” permits. When a waiting thread is notified, it may compete with other threads for the object’s lock, but when it eventually reacquires the lock, it will not execute wait again. Instead, it will start executing in P() after the wait operation, which means that it will definitely be allowed to complete its P() operation.

This Java implementation of countingSemaphore does not guarantee a FCFS notification policy among waiting threads. That is, the order in which threads are notified is not necessarily the same order in which the threads waited. In Chapter 4 we discuss more details about Java’s wait and notify operations and present semaphore implementations that guarantee a FCFS notification policy for waiting threads. These implementations are needed to build the testing and debugging tools described later.

We should also point out that Java implementations are permitted to perform spurious wakeups (i.e., wakeup threads without there having been any explicit Java instructions to do so). If spurious wakeups occur, class countingSemaphore may fail (see Exercise 3.18). A countingSemaphore implementation that deals with spurious wakeups and interrupts is given in Chapter 4.

3.6.2 Class mutexLock

Listing 3.16 shows Java class mutexlock. Class mutexlock is more flexible than the built-in Java locks obtained through the synchronized keyword. A