modern-multithreading-c-java

calls to exerciseEvent() to generate communication events labeled “deposit” and “withdraw”:

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

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

buffer[in] = value;

exerciseEvent(‘‘deposit’’); // generate a ‘‘deposit’’ event in = (in + 1) % capacity; ++fullSlots;

notEmpty.signalC();

exitMonitor();

}

public int withdraw() { enterMonitor(); int value;

while (fullSlots == 0) notEmpty.waitC();

value = buffer[out];

exerciseEvent(‘‘withdraw’’); // generate a ‘‘withdraw’’ event out = (out + 1) % capacity; --fullSlots;

notFull.signalC();

exitMonitor(); return value;

}

The M-sequence shown above with communication events “deposit” and “withdraw” added is

For each communication event, we record its label and the ID of the thread that executed the event.

A sequence of communication events is useful for understanding what happened, that is, the communication that occurred among the threads, without any details about how the threads were synchronized to achieve that communication:

It is easy to imagine several different monitors that are equivalent in the sense that they allow the same set of communication sequences, even if some of the monitors are SC monitors and some are SU monitors.

If all shared variables are accessed inside monitors, the result of an execution of a monitor-based program can be determined by the program, the input, and the M-sequence of this execution. Notice that this same statement holds when we substitute “simple M-sequence” for “M-sequence,” which is why we can use simple M-sequences for replay. (Again, we are assuming that monitor entry is the only source of nondeterminism in the program.)

M-sequences contain more information than a simple M-sequence because they are used to solve a different problem. When we modify a program to correct a fault, we want an answer to the following question: If we execute the program with the same the input that detected the fault, can the same path be exercised and the same output be produced? An M-sequence partially identifies the path exercised by a program and helps us answer this question.

Consider the following monitor method:

public void F() { enterMonitor(); if (...) {

condition.waitC();

}

if (...) {

/* true-part*/

}

else {

/* false-part */

}

condition.signalC();

exitMonitor();

}

An M-sequence for an execution of a program containing method F () indicates the order in which threads entered F () and whether or not the wait() operation in F () was executed. (The signal() operation is always executed.) This tells us a lot about the path through F () that each thread executed. However, an M-sequence,

by itself, does not indicate whether the threads executed the true or the false part of the second if-statement in F (). A path consists of more than just an M-sequence.

Whenever we determine the feasibility of an M-sequence, we will also check the output that is produced during the execution. The output of an execution involving method F () is likely to indicate whether the true or the false part was executed. Thus, the M-sequence and the output of an execution, together, describe the execution very well.

Despite the fact that M-sequences offer only a partial characterization of the path of an execution, they still tell us a lot about what happened. We can often examine an M-sequence and determine whether there is a fault in the program without looking at the output or any additional information that was recorded about the execution. In fact, some executions can produce outputs that mask faults. So even though an execution produces correct outputs, an examination of the M-sequence may show that a fault is present.

This discussion raises the question of how to define a path of a concurrent program. Many path-based testing techniques have been developed for sequential programs. In a sequential program, where there is a single thread of control, a path is simply the sequence of statements exercised during an execution. But in a concurrent program, each thread executes its own sequence of statements. Furthermore, even if the threads in a program execute the same sequence of statements during two different executions, it is possible that these two executions produce different results. Thus, the sequence of statements executed by each thread does not provide sufficient information to characterize the path that was executed. (You may already have guessed that the SYN-sequence of an execution provides the missing information about the path.) This issue is resolved in Chapter 7.

4.11.2 Determining the Feasibility of an M-Sequence

The feasibility of an M-sequence is determined using the same technique that was used for replay. Before a thread can perform a monitor operation, it requests permission from a control module. The control module is responsible for reading an M-sequence and forcing the execution to proceed according to this sequence. If the M-sequence is determined to be infeasible, the control module displays a message and terminates the program.

Modifying Monitor Operations Each monitor operation is modified by adding one or more calls to the controller. Below we describe the modifications made to the SC monitor operations. The modifications for the SU monitor operations are very similar.

Method enterMonitor() contains calls to control.requestMPermit() and control.releaseMPermit() to control entry into the monitor during testMode. The call to control.trace(. . .) is made during traceMode to record the necessary information about each monitor entry.

public final void enterMonitor(String methodName) { if (testMode)

control.requestMPermit(ENTRY,threadID,methodName,’’NA’’);

mutex.P();

if (testMode) control.releaseMPermit();

else if (traceMode) control.trace(ENTRY,threadID,methodName,’’NA’’);

}

The arguments for the call to control.requestMPermit() are

(ENTRY, ID, methodName, ’’NA’’),

which correspond to the type of event (ENTRY), the identifier (ID) of the entering thread, the method name, and the name of the associated conditionVariable. Since the name of a conditionVariable is not applicable on monitor entries, “NA” is used.

For the method name to be available inside the toolbox, it must be passed by the user as an argument to enterMonitor():

public void deposit(char value) { enterMonitor(’’deposit’’);

...

}

The methodName passed to enterMonitor() is saved locally in the monitor so that it can be used by any waitC(), signalC(), signalCall(), or exitMonitor() operations that appear in the same monitor method.

Method waitC() in the SC toolbox has a call to control.requestMPermit() with event type WAIT. This call occurs before the VP() operation that implements the wait. There is also a call to control.requestMPermit() with event type REENTRY. This call appears immediately before the mutex.P() operation that guards reentry. The value of methodName is the name that was saved in enterMonitor(), and the value of conditionName is the name of the conditionVariable.

public void waitC() { if (testMode)

control.requestMPermit(WAIT,threadID,methodName,conditionName); else if (traceMode)

control.trace(WAIT,threadID,methodName,conditionName);

numWaitingThreads++;

threadQueue.VP(mutex);

if (testMode) control.requestMPermit(REENTRY,threadID,methodName,’’NA’’);

mutex.P();

if (testMode) control.releaseMPermit();

else if (traceMode) control.trace(REENTRY,threadID,methodName,’’NA’’);

}

A conditionVariable’s name is generated automatically when the conditionVariable is constructed. This internal name is generated using the same technique that is used to generate thread names (see Section 1.7.2). Alternatively, a more descriptive name can be specified when the conditionVariable is constructed, but each name must be unique:

notFull = new conditionVariable("notFull’’);

The call to releaseMPermit() after the mutex.P() operation notifies the controller that reentry has occurred and that the next monitor event can be permitted.

There is no call to releaseMPermit() after a WAIT event since such a call is not necessary. The same thing is true for events of types SIGNAL and EXIT (see below). This is because wait, signal, and exit operations all occur within critical sections. Thus, once permission is received to perform one of these operations, the operation is guaranteed to occur before the next operation in the sequence (for the same monitor). This guarantee is based on the fact that mutual exclusion is not released until after the wait, signal or exit operation is performed, so no other operation can possibly barge ahead.

For ENTRY and REENTRY events, the controller must confirm that the current ENTRY or REENTRY event has occurred before it allows the next event to occur. To see why, assume that thread T1 is required to enter the monitor before thread T2. T1 will receive permission to enter the monitor first; however, a context switch may occur after T1 receives permission but before T1 enters the monitor. Now T2 can receive permission to enter the monitor and barge ahead of T1. To prevent this from happening, the controller will wait for T1 to enter the monitor and call releaseMPermit() before the controller will give T2 permission to enter. Thread T2 may try to enter the monitor before T1 exits, but T2 will not be able to enter until T1 releases mutual exclusion by executing exitMonitor() or waitC().

Threads executing signalC() or exitMonitor() in an SC monitor must request permission before executing a SIGNAL or EXIT event:

public void signalC() { if (testMode)

control.requestMPermit(SIGNAL,threadID,methodName,conditionName); else if (traceMode)

control.trace(SIGNAL,threadID,methodName,conditionName); if (numWaitingThreads > 0) {

numWaitingThreads--; threadQueue.V();

}

}

public void exitMonitor() { if (testMode)

control.requestMPermit(EXIT,threadID,methodName,’’NA’’); else if (traceMode)

control.trace(EXIT,threadID,methodName,’’NA’’);

mutex.V();

}

If a monitor contains calls to exerciseEvent(), threads executing exerciseEvent() must request permission before executing a communication (COMM) event:

public void exerciseEvent(String eventLabel) { if (testMode)

control.requestMPermit(COMM,threadID,eventlabel,’’NA’’); else if (traceMode)

control.trace(COMM,threadID,eventLabel,’’NA’’);

}

Controller The function of the controller is very similar to that of the controller used for replay. It attempts to force a deterministic execution of the program according to the M-sequence that it inputs. The M-sequence is feasible if and only if the M-sequence is exercised completely. We would like the controller to display a message if it finds that an M-sequence definitely cannot be exercised. However, the problem of determining whether a concurrent program terminates for a given input and SYN-sequence is, in general, undecidable. (This problem can be reduced to the halting problem [Hamburger and Richards 2002], which is undecidable.)

A practical way to deal with this undecidable problem is to specify a maximum time interval that is allowed between two consecutive events. In other words, this timeout value represents the maximum amount of time that the controller is willing to wait for the next event to occur. If a timeout occurs, the sequence

is assumed to be infeasible. It is always possible that some larger timeout value would give the next event enough time to occur and allow the sequence to complete. However, the timeout value can be made large enough so that a timeout always indicates that a real problem exits: Either the event cannot occur, or possibly it can occur but something else is wrong and is holding up the event.

The controller is implemented in two parts. The first part is the control monitor shown in Listing 4.29. The control monitor inputs an M-sequence and then forces the execution to proceed according to the order of events in the M-sequence. The event in Msequence[index] is the next event to be exercised. Threads call requestMPermit() to request permission to perform a monitor operation. If a requesting thread with identifier ID attempts to perform its operation out of sequence, the thread is delayed on condition variable threads[ID]. When the ID of the requesting thread matches the ID for the next event, the controller verifies that the requested event’s type and method name match the expected values for the next event. For WAIT and SIGNAL events, the condition name is also checked. If a mismatch is detected, a diagnostic is issued and the program is terminated.

For ENTRY and REENTRY events, the controller waits for a call to releaseMPermit() before incrementing index to allow the next event to be issued. For WAIT, SIGNAL, COMM and EXIT events, no releaseMPermit() calls will be made, so index is incremented when permission is granted in requestMPermit(). At any point in the sequence, if an expected request does not arrive within the timeout interval, a diagnostic is issued and the program is terminated. This timeout function of the controller is handled by a watchdog thread that monitors the value of index to make sure that progress is being made. If the value of index does not change within the timeout interval, the M-sequence is assumed to be infeasible.

final class watchDog extends Thread { public void run() {

while (index < MSequence.size()) { int saveIndex = index;

try { Thread.sleep(2000); } // 2-second timeout interval catch (InterruptedException e) {}

if (saveIndex == index) {

/* issue diagnostic and exit program */

}

}

}

}

Splitting the controller into a monitor and a watchdog thread is one way to implement the dual functions of the controller, which are ordering monitor events and handling timeouts. In Chapter 5 we show how both functions can be handled by a single thread.

4.11.3 Determining the Feasibility of a Communication-Sequence

A Communication-sequence is a sequence of communication events. A set of Communication-sequences can be generated to test a monitor without knowing the details about the synchronization events in the monitor. The details that are abstracted away include calls to methods waitC() and signalC() and the names of the condition variables and monitor methods.

The feasibility of a Communication-sequence is determined just like that of an M-sequence, except that only the thread IDs and event labels of communicationevents are checked. Monitor (re)entry events do not appear in a Communicationsequence and thus they need not be checked, but they must be controlled. The rule for controlling monitor (re)entry is as follows: If Threadi is expected to execute the next communication-event (inside the monitor), only Threadi is permitted to (re)enter the monitor.

Threads that wish to (re)enter a monitor must request permission from the controller first. The controller grants permission for Threadi to enter the monitor only if Threadi is the thread expected to execute the next communication event in the sequence. In other words, the order in which threads execute communication events must match the order in which they (re)enter the monitor. If this is not possible, the Communication-sequence is not feasible. Monitor events of types EXIT and SIGNAL do not require any permission from the controller, so no calls to the controller are made in methods exitMonitor() and signalC(). Threads in method waitC() of an SC monitor must call the controller before they reenter the monitor. Section 4.10.5 shows an example of how to use Communicationsequences to test a program.

4.11.4 Reachability Testing for Monitors

In Section 3.8.5 we described reachability testing and showed how to use reachability testing to test programs that use semaphores and locks. Reachability testing can also be used to derive and exercise automatically every (partially ordered) M-sequence of a monitor-based program. Reachability testing identifies race conditions in an execution trace and uses the race conditions to generate race variants. Recall from Chapter 3 that a race variant represents an alternative execution behavior that definitely could have happened, but didn’t, due to the way that race conditions were arbitrarily resolved during execution. Replaying a race variant ensures that different behavior is observed during the next execution.

Figure 4.30a shows an execution trace of a bounded buffer program with two producers (P1 and P2), two consumers (C1 and C2), and an SC monitor M. A solid arrow from a producer or consumer thread to monitor M indicates that the thread called and entered monitor M. In this execution, the producer and consumer threads enter the monitor in the order (C1, P1, C1, P2, C2). Note that the second entry by C1 occurs when C1 reenters the monitor after being signaled by P1.

Informally, there is a race between two monitor calls in an execution trace if the entries for these calls could occur in a different order during another execution. In Fig. 4.30a we have identified the racing threads, called the race