modern-multithreading-c-java

class countingSemaphore3 extends monitor {

private int permits; // The value of permits is never negative. private conditionVariable permitAvailable = new conditionVariable();

public countingSemaphore3(int initialPermits) { permits = initialPermits;} public void P() {

if (permits == 0) permitAvailable.wait();

--permits;

}

public void V() { ++permits;

permitAvailable.signal(); // SU signal

}

}

Listing 4.19 Class countingSemaphore3 .

žT2 exits the monitor, which allows T3 to enter, decrement permits from 1 to 0, and exit the monitor.

žT1 resumes execution, executes the statement permits, and exits the monitor. The value of permits is −1.

This scenario shows that monitor countingSemaphore3 with SC signals is incorrect since a single V() operation has allowed the completion of two P() operations. The reason for this error is that when T1 resumes execution, the condition (permits > 0) is not true, but T1 completes method P() anyway. This error is fixed by replacing the if-statement in method P(),

if (permits == 0) permitAvailable.wait();

with the while-loop

while (permits == 0) permitAvailable.wait();

Now if condition (permits == 0) is not true when the wait() operation returns, the signaled thread will wait again. The resulting monitor is the same as countingSemaphore1 in Listing 4.4, but as we mentioned, it does not implement a FCFS semaphore.

Using a while-loop instead of an if-statement in an SC monitor requires an extra evaluation of condition (permits == 0) after a wait(). On the other hand, the execution of an SU monitor requires additional context switches for managing the signaler threads in the Reentry queue. Using signal-and-exit semantics for a signal operation that appears at the end of an SU method avoids the costs

of the extra condition evaluation and the extra context switches. Thus, we use signal-and-exit wherever possible.

4.6 USING SEMAPHORES TO IMPLEMENT MONITORS

Monitors can be implemented in the kernel [Andrews 2000]. In this section we show how to use semaphores to implement monitors with SC, SU, or SE signaling [Hoare 1974]. The implementation of USC signaling is left as an exercise. Semaphores provide mutual exclusion for threads inside the monitor and are used to implement wait() and signal() operations on condition variables.

If a language or API provides semaphores but not monitors, which is the case for Win32 and Pthreads, monitors can be simulated using this semaphore implementation. In Sections 4.7 and 4.8 we present Java and C++ monitor classes that use semaphores to simulate monitors. Then we extend these classes to support cyclical testing and debugging techniques for monitor-based programs. Even though Java provides built-in support for monitors, our custom Java monitor classes are still helpful since it is not easy to test and debug built-in Java monitors. Also, we can choose which type of monitor—SC, SU, SE, or USC—to use in our Java programs.

4.6.1 SC Signaling

The body of each public monitor method is implemented as

public returnType F(...) { mutex.P();

/* body of F */ mutex.V();

}

Semaphore mutex is initialized to 1. The calls to mutex.P() and mutex.V() ensure that monitor methods are executed with mutual exclusion.

Java class conditionVariable in Listing 4.20 implements condition variables with SC signals. Since it is not legal to overload final method wait() in Java, methods named waitC() and signalC() are used instead of wait() and signal(). A signalCall() operation, which behaves the same as Java’s notifyAll, is also implemented, along with operations empty() and length().

Each conditionVariable is implemented using a semaphore named threadQueue, which is initialized to 0. When a thread executes waitC(), it releases mutual exclusion and blocks itself using threadQueue.P(). Since signalC() operations must determine whether any threads are waiting on the condition variable, an integer variable named numWaitingThreads is used to count the waiting threads. The value of numWaitingThreads is incremented in waitC() and decremented in signalC() and signalCall(). The signalC() operation executes threadQueue.V() to

}

// returns true if the queue is empty

public boolean empty() { return (numWaitingThreads == 0); } // returns the length of the queue

public int length() { return numWaitingThreads; }

}

Listing 4.20 Java class conditionVariable.

signal one waiting thread. Operation signalCall() uses a while-loop to signal all the waiting threads one by one.

Notice that the implementation of method waitC() uses a VP() operation. Operation threadQueue.VP(mutex) prevents deadlocks that otherwise could occur if the mutex.V() and threadQueue.P() operations were issued separately (see Exercises 4.10 and 4.22). The VP() operation also guarantees that threads executing waitC() are blocked on semaphore threadQueue in the same order that they entered the monitor. Without VP(), context switches between the V() and P() operations would create a source of nondeterminism in the implementation of the monitor. We will see shortly how the VP() operation simplifies tracing and replay for monitor-based programs. (A monitor implementation that does not use VP() operations is considered in Exercise 4.23.)

4.6.2 SU Signaling

Java class conditionVariable in Listing 4.21 implements condition variables with SU signals. Threads that execute a signalC() operation must wait in the reentry

final class conditionVariable {

private countingSemaphore threadQueue = new countingSemaphore(0); private int numWaitingThreads = 0;

public void signalC() {

if (numWaitingThreads > 0) { ++reentryCount;

reentry.VP(threadQueue); // release exclusion and join reentry queue --reentryCount;

}

}

public void waitC() { numWaitingThreads++;

if (reentryCount > 0) threadQueue.VP(reentry); // the reentry queue has else threadQueue.VP(mutex); // priority over entry queue --numWaitingThreads;

}

public boolean empty() { return (numWaitingThreads == 0); } public int length() { return numWaitingThreads; }

}

Listing 4.21 Java class conditionVariable for SU monitors.

queue. Therefore, each SU monitor has a semaphore named reentry (initialized to 0), on which signaling threads block themselves. If signalC() is executed when threads are waiting on the condition variable, threadQueue.V() is executed to signal a waiting thread, and reentry.P() is executed to block the signaler in the reentry queue. These V() and P() operations are executed together as reentry.VP(threadQueue). As we mentioned above, this removes a possible source of deadlock and nondeterminism in the implementation of the monitor.

When a thread executes waitC(), the thread must determine whether any signaler threads are waiting in the reentry queue, since signaler threads in the reentry queue have priority over calling threads in the entry queue. If signalers are waiting, the thread releases a signaler by executing reentry.V(); otherwise, the thread releases mutual exclusion by executing mutex.V(). Integer reentryCount is used to count the number of threads waiting in reentry. Method signalC() increments and decrements reentryCount as threads enter and exit the reentry queue. Method waitC() uses the value of reentryCount to determine which V() operation to execute.

Threads exiting the monitor also use reentryCount to give signaler threads priority over new threads. The body of each public monitor method is implemented as

public returnType F(...) { mutex.P();

/* body of F */

Simulated monitors are not as easy to use or as efficient as real monitors, but they have some advantages:

žA monitor toolbox can be used to simulate monitors in languages that do not support monitors directly. For example, as we show below, a monitor toolbox allows monitors to be used in C++/Win32/Pthreads programs.

žDifferent versions of the toolbox can be created for different types of signals. Java’s built-in monitors use SC signaling. An SU toolbox can be used to allow SU signaling in Java.

žThe toolbox can be extended to support testing and debugging.

The last advantage is an important one. If a language provides monitors but does not provide any mechanism for coping with nondeterminism during testing and debugging, it may be better to use simulated monitors to avoid timeconsuming testing and debugging problems.

4.7.1 Toolbox for SC Signaling in Java

Listing 4.23 shows a monitor toolbox that uses semaphores to simulate monitors with SC signaling. Class conditionVariable is nested inside class monitor, which gives class conditionVariable access to member object mutex in the monitorSC class.

4.7.2 Toolbox for SU Signaling in Java

Listing 4.24 shows a Java monitor toolbox with SU signaling. The SU toolbox provides method signalC and exitMonitor(), which can be used when a

signal operation is the last statement in a method (other than a return statement). When this method is called, the signaler does not wait in the reentry queue. For example, method deposit() using signalC and exitMonitor() becomes

public void deposit(int value) { enterMonitor();

if (fullSlots == capacity) notFull.waitC();

buffer[in] = value;

in = (in + 1) % capacity; ++fullSlots;

notEmpty.signalC_and_exitMonitor();

}

public class monitorSU { // monitor toolbox with SU signaling private binarySemaphore mutex = new binarySemaphore(1); private binarySemaphore reentry = new binarySemaphore(0); private int reentryCount = 0;

proteced final class conditionVariable {

private countingSemaphore threadQueue = new countingSemaphore(0); private int numWaitingThreads = 0;

public void signalC() {

if (numWaitingThreads > 0) { ++reentryCount; reentry.VP(threadQueue); --reentryCount;

}

}

public void signalC_and_exitMonitor() { // does not execute reentry.P() if (numWaitingThreads > 0) threadQueue.V();

else if (reentryCount > 0) reentry.V(); else mutex.V();

}

public void waitC() { numWaitingThreads++;

if (reentryCount > 0) threadQueue.VP(reentry); else threadQueue.VP(mutex); --numWaitingThreads;

}

public boolean empty() { return (numWaitingThreads == 0); } public int length() { return numWaitingThreads; }

}

public void enterMonitor() { mutex.P(); } public void exitMonitor() {

if (reentryCount > 0) reentry.V(); else mutex.V();

}

}

Listing 4.24 Java monitor toolbox monitorSU with SU signaling.

Monitor methods are written just as they are in Java:

void boundedBuffer::deposit(int value) { enterMonitor();

while (fullSlots == capacity) notFull.waitC();

buffer[in] = value;

conditionVariable notFull; conditionVariable notEmpty;

public:

boundedBuffer(int bufferCapacity); ~boundedBuffer();

void deposit(int value, int ID); int withdraw(int ID);

};

Listing 4.25 Using the C++ monitorSC toolbox class.

in = (in + 1) % capacity; ++fullSlots; notEmpty.signalC(); exitMonitor();

}

4.8.1 Toolbox for SC Signaling in C++/Win32/Pthreads

Listing 4.26 shows a C++/Win32/Pthreads monitor toolbox with SC signaling. Class conditionVariable is a friend of class monitorSC. This gives conditionVariables access to private member mutex of class monitor. Class conditionVariable could be nested inside class monitorSC, as we did in the Java toolbox, but that would not give class conditionVariable direct access to member object mutex in class monitorSC. C++ and Java rules for nested classes are different. (This may change in a future version of C++.)

4.8.2 Toolbox for SU Signaling in C++/Win32/Pthreads

Listing 4.27 shows a C++/Win32/Pthreads monitor toolbox with SU signaling.

4.9 NESTED MONITOR CALLS

A thread T executing in a method of monitor M1 may call a method in another monitor M2. This is called a nested monitor call. If thread T releases mutual exclusion in M1 when it makes the nested call to M2, it is said to be an open call. If mutual exclusion is not released, it is a closed call. Closed calls do not