modern-multithreading-c-java

require any extra effort to implement, since they do not affect the monitor in which the call is made. Closed calls, however, are prone to create deadlocks. Consider the following monitor classes:

Suppose that we create an instance of the first monitor:

First M1;

and that this instance is used by two threads:

Thread A Thread B

M1.A1(); M1.B1();

Assume that Thread A enters method A1() of monitor M1 first and makes a closed monitor call to M2.A2(). Assume that Thread A is then blocked on the wait statement in method A2(). Thread B intends to signal Thread A by calling method M1.B1, which issues a nested call to M2.B2(), where the signal is performed. But this is impossible since Thread A retains mutual exclusion for monitor M1 while Thread A is blocked on the wait statement in monitor M2. Thus, Thread B is unable to enter M1 and a deadlock occurs.

Open monitor calls are implemented by having the calling thread release mutual exclusion when the call is made and reacquire mutual exclusion when the call returns. The monitor toolboxes described in Section 4.8 make this easy to do. For example, method A1() above becomes

public void A1() {

enterMonitor(); // acquire mutual exclusion

...

exitMonitor(); // release mutual exclusion

This gives equal priority to the threads returning from a nested call and the threads trying to enter the monitor for the first time, since both groups of threads call enterMonitor(). Alternatively, the monitor toolboxes can be modified to give returning threads higher priority so that they will reenter the monitor first (see Exercise 4.3).

Open calls can create a problem if shared variables in monitor M1 are used as arguments and passed by reference on nested calls to M2. This allows shared variables of M1 to be accessed concurrently by a thread in M1 and a thread in M2, violating the requirement for mutual exclusion.

4.10 TRACING AND REPLAY FOR MONITORS

In this section we present techniques for tracing, replaying, and testing monitorbased programs. We first define a simple M-sequence of a monitor-based program. Then we show how to trace and replay simple M-sequences during debugging and how to modify the SC and SU monitor toolboxes to support our tracing and replay techniques. After that, we define a complete M-sequence and present a technique for using complete M-sequences to test monitor-based programs. Finally, we show how to apply reachability testing to monitor-based programs.

4.10.1 Simple M-Sequences

In Sections 4.6 and 4.7 we described monitor toolboxes for SC and SU monitors. Let M be a monitor that is implemented using one of these implementations. An execution of a program that uses M can be viewed as a sequence of P() and V() operations on the semaphores in the implementation of M. (Recall that each monitor is implemented using one semaphore for mutual exclusion and one semaphore for each of the condition variables in the monitor. SU monitors also use a semaphore to implement the reentry queue.) Hence, a simple SYNsequence for M is the collection of simple PV-sequences for the semaphores in the implementation of M.

We can replay an execution of a program that uses M by applying the replay method that was presented in Chapter 3 for replaying PV-sequences of semaphore-based programs. However, special properties of the monitor toolboxes allow us to simplify this replay method. These monitor toolboxes use semaphores with FCFS notifications and VP() operations, both of which place extra constraints on the behavior of threads once they (re)enter a monitor:

žThe execution of threads inside an SU monitor is determined completely by the order in which the threads enter the monitor via monitor calls and the values of the parameters on these calls.

žThe execution of threads inside an SC monitor is determined completely by the order in which the threads enter the monitor via monitor calls, the values of the parameters on these calls, and the order in which signaled threads reenter the monitor.

Thus, the only nondeterminism that is present in these SU and SC monitors is the order in which threads (re)enter the monitor. We refer to this as entry-based execution: The execution of threads in a monitor having entry-based execution is determined completely by the order in which the threads (re)enter the monitor and the values of the parameters on the calls to the monitor.

This observation about entry-based execution leads to the following definition of a simple SYN-sequence for a monitor-based program. Let CP be a concurrent program that uses monitors. The synchronization objects in CP are its monitors. The synchronization events in a simple SYN-sequence of CP depend on the type of monitors being used:

1.SC monitors: A simple SYN-sequence for an SC monitor is a sequence of events of the following types:

žEntry into the monitor by a calling thread

žReentry into the monitor by a signaled thread

2.SU monitors: A simple SYN-sequence for an SU monitor is a sequence of events of the following type:

žEntry into the monitor by a calling thread

Simple SYN-sequences of monitors are called simple M-sequences. An event in a simple M-sequence is denoted by the identifier (ID) of the thread that executed the event. The simple M-sequence of a program CP is a collection of simple M-sequences for the monitors in CP. We can replay an execution of CP by replaying the simple M-sequence for each monitor.

To illustrate these definitions, consider the SC bounded buffer monitor in Listing 4.3. A possible simple M-sequence of boundedBuffer for a single Producer thread (with ID 1) and a single Consumer thread (with ID 2) is

(2, 1, 2, 1, 1, 2, 2).

This sequence is generated when the Consumer enters the monitor first and executes notEmpty.wait(). The Producer then enters the monitor, deposits an item, and signals the Consumer. The Consumer then reenters the monitor and consumes an item. Thus, this sequence begins with 2, 1, 2 since the Consumer generates one event when it enters the monitor (the first 2) and one event when it reenters the monitor (the second 2). If the same scenario were to occur when boundedBuffer was an SU monitor, the simple M-sequence of boundedBuffer would be

(2, 1, 1, 1, 2, 2).

In this sequence, the Consumer does not generate an event when it reenters the monitor, since boundedBuffer is an SU monitor. Thus, the sequence begins with 2, 1 and is followed by a second entry event for the Producer (the second 1) and not a reentry event for the Consumer.

We are making several important assumptions in our definition of simple M-sequences:

1.All shared variables are accessed inside a monitor, and monitor (re)entry is the only source of nondeterminism in the program.

2.Semaphores with FCFS notifications are used in the implementation of condition variables. If notifications wake up waiting threads in an unpredictable order, nondeterminism is introduced in the implementation of the monitor.

3. VP() operations are used in the semaphore implementation of a monitor. Without VP() or some other mechanism (see Exercise 4.23), context switches can occur between V() and P() operations, which introduces nondeterminism in the implementation of the monitor.

Assumptions 2 and 3 are necessary for entry-based execution. If assumption 1 does not hold, replaying the simple M-sequences of an execution may not replay the execution.

4.10.2 Tracing and Replaying Simple M-Sequences

We now show how to modify the monitor toolboxes so that they can trace and replay simple M-sequences. In the SU toolbox, semaphore mutex controls entry into the monitor. During execution, the identifier of a thread that completes a mutex.P() operation is recorded and saved to a trace file. Toolbox method enterMonitor() is easily modified (see below) to send monitor entry events to a control monitor that records and saves them.

Tracing for SC monitors is almost as easy. In the SC toolbox, semaphore mutex controls entry into the monitor for threads calling the monitor, and reentry into the monitor for signaled threads. As with SU monitors, the identifier of the thread that completes a mutex.P() operation is recorded and saved to a trace file. This requires modifications to methods enterMonitor() in class monitor and method waitC() in class conditionVariable.

To replay a simple M-sequence, we use the same basic technique that we used with semaphores. Before each mutex.P() operation, a thread calls control.requestEntryPermit(ID) to request permission to enter the monitor. After completing mutex.P(), the thread calls control.releaseEntryPermit() to allow the next thread in the simple M-sequence to enter the monitor. Method enterMonitor() in the SU and SC toolboxes becomes

public final void enterMonitor() { if (replayMode)

control.requestEntryPermit(ID);

mutex.P();

if (replayMode) control.releaseEntryPermit();

else if (traceMode) control.traceMonitorEntry(ID);

}

Method waitC() in the SC toolbox becomes

public void waitC() { numWaitingThreads++; threadQueue.VP(mutex);

if (replayMode) control.requestEntryPermit(ID);

mutex.P();

if (replayMode) control.releaseEntryPermit();

else if (traceMode) control.traceMonitorReEntry(ID);

}

Java monitor class monitorTracingAndReplay in Listing 4.28 is very similar to the control object in Listing 3.32 that was used for replaying simple PVsequences. Threads that try to enter the monitor out of turn are delayed in method requestEntryPermit() on a separate conditionVariable in the threads array. A thread uses its ID to determine which conditionVariable in the threads array to wait on.

Method releaseEntryPermit() increments index to allow the next (re)entry operation in the simpleMSequence to occur. Suppose that thread T is expected to execute the next (re)entry operation. Since thread T may already have been delayed by a waitC() operation when T called method requestEntryPermit(), method releaseEntryPermit() performs a signalC and exitMonitor() operation. If thread T is blocked on the waitC() operation in requestEntryPermit(), it will be awakened by this signal. Otherwise, when thread T eventually calls requestEntryPermit(), it will not call waitC() (since T’s ID will match the next ID in the simpleMSequence), and thus thread T will not be blocked.

4.10.3 Other Approaches to Program Replay

Another approach to replaying an execution of a multithreaded Java program is to trace and replay the scheduling events of the operating system. A thread schedule

class monitorTracingAndReplay extends monitorSU { monitorTracingAndReplay () {

/* input sequence of Integer IDs into vector simpleMSequence and initialize the threads array */

}

public requestEntryPermit(int ID) { enterMonitor();

if (ID != ((Integer)simpleMSequence.elementAt(index)).intValue())

}

public releaseEntryPermit() { enterMonitor();

if (index < simpleMSequence.size()-1) { ++index;

//if the next thread in the simpleMSequence was delayed in

//requestEntryPermit(), wake it up. threads[((Integer)simpleMSequence.elementAt(index)).intValue()].

signalC_and_exitMonitor(); return;

}

exitMonitor();

}

//record integer ID of entering thread in trace file public void traceMonitorEntry(int ID) { ... }

//record integer ID of reentering thread in trace file public void traceMonitorReEntry(int ID) { ... }

//simple M-sequence traced during a previous execution. private vector simpleMSequence;

//out of order threads are delayed on condition variables. private conditionVariable[] threads;

//index of the next event in simpleMSequence to be replayed. private int index = 1;

}

Listing 4.28 Java monitor monitorTracingAndReplay for tracing and replaying simple M-sequences.

is a sequence of time slices, where a time slice is the interval of time between two context switches. A thread schedule of an execution can be replayed by forcing context switches to occur at the exact same points during the execution. Since detailed scheduling information is not always available from the operating system, a logical thread schedule can be used instead. A logical thread schedule of an execution is a record of the number of critical operations that the threads executed during their time slices. Critical operations are read and write operations on shared

variables, entering and exiting synchronized methods and blocks, and wait and notify operations. A logical thread schedule can be replayed my modifying the Java Virtual Machine (JVM) to count critical operations. For example, assume that Thread1 executes 50 critical operations during its time quantum. This can be represented by recording an event such as (1, 20, 69) to represent the fact that Thread1 executed the (50) operations numbered 20 through 69. (A similar representation was also discussed in Section 2.5.2.) Using this scheme, a time slice consisting of thousands of critical operations can be encoded very efficiently by a single event. The DejaVu system [Choi and Srinivasan 1998] uses logical thread schedules to replay multithreaded Java programs. Java applications can be traced and replayed in DejaVu without any modifications to the source code.

4.11 TESTING MONITOR-BASED PROGRAMS

In this section we present a technique for testing monitor-based programs. A complete M-sequence can be used during (regression) testing to determine whether a particular behavior is allowed by a program. We also show how to modify the SC and SU monitor toolboxes to support this testing technique.

4.11.1 M-Sequences

Simple M-sequences help us carry out an important part of a typical debugging session. Debugging begins after a program is executed and a failure is observed. The simple M-sequence of the execution is replayed, perhaps several times, to locate the fault that caused the failure. When the fault is located, the program is modified and replay stops. However, this is not the end of the process. The modification must be tested to make sure that the fault has been corrected and that no new faults were introduced by the modification. This is commonly known as regression testing.

For a concurrent program, regression testing requires that we determine whether or not a particular SYN-sequence is feasible. (A feasible SYN-sequence is a sequence that can be exercised by the program.) The SYN-sequence may represent an illegal (or invalid ) behavior that was observed when the program failed. For example, a sequence of three consecutive deposits into a bounded buffer with only two slots is an invalid sequence. In this case, we hope that the modification has corrected the program by making this invalid SYN-sequence infeasible. If, on the other hand, a SYN-sequence represents a legal (or valid ) behavior that was exhibited previously, this valid sequence should remain feasible after the modifications.

Determining the feasibility of a SYN-sequence is a problem that is subtly different from the replay problem. Replaying a SYN-sequence involves repeating a sequence that is known to be feasible since, presumably, the sequence was just exercised and the program has not been modified. The feasibility of a sequence is not in question during replay.

or an SU signal operation. We omit these events since their occurrence can be inferred by the occurrence of events of types 1 through 4. However, it may still be desirable to trace these events to aid in understanding executions.

A sequence of events of types 1 through 4 is called a complete M-sequence. In the remainder of the book, the term M-sequence always refers to a complete M-sequence. We will continue to use the term simple M-sequence to refer to the simpler format that is used for replay. The format of an M-sequence for a monitor is

((Type1,Thread1,Method1,ConditionVariable1), (Type2,Thread2,Method2, ConditionVariable2), ...)

where (Typei, Threadi, Methodi, ConditionVariable1) denotes the ith, i > 0, event in the M-sequence. The fields in an event are:

žType: the type of this event

žThread: the ID of the thread executing this event

žMethod: the monitor method of this event, qualified with the monitor name if there are multiple monitors

žConditionVariable: the name of the condition variable if this event is a wait, signal, signalAndExit, or signalAll event; and “NA” otherwise.

The M-sequence of a program CP is a collection of M-sequences for the monitors in CP. As an example, a possible M-sequence of the SC bounded buffer monitor in Listing 4.3 is

To make this sequence more readable, we’ve used the names of the producer and consumer threads in place of their IDs.

Another way to make an M-sequence clearer is to allow user-level events to appear in the sequence. These events label the (atomic) communication actions that occur inside the monitor. A call to method exerciseEvent(“event”) generates a communication event labeled “event” and records it in the M-sequence. For example, in the following SC bounded buffer monitor, we have inserted