modern-multithreading-c-java

the results for two versions of BB and RW, one version using class monitorSU and one version using class monitorSC.

The results in Table 4.2 indicate that the choice of signaling discipline has a large effect on the number of M-sequences generated during reachability testing. SC monitors generate more M-sequences than SU monitors since SC monitors have races between signaled threads that are trying to reenter the monitor and calling threads that are trying to enter the monitor for the first time. SU monitors avoid these races by giving signaled threads priority over calling threads. These results help to quantify the difference between SU and SC monitors.

As we discussed in Section 3.10.5 regarding Table 3.2, the number of sequences exercised during reachability testing can be reduced by considering the symmetry of the threads in the programs. For the bounded-buffer program, reachability testing considers all the possible orders in which a group of producers can perform their deposit operations or a group of consumers can perform their withdraws. For example, the order in which Producer threads enter the monitor may be (Producer1, Producer2, Producer3), or (Producer2, Producer1, Producer3), or (Producer3, Producer2, Producer1), and so on. If you use the symmetry of the threads, the number of sequences exercised for the two bounded buffer programs drops from 720 and 12096 to 20 and 60, respectively.

4.11.5 Putting It All Together

Next we demonstrate how to use the monitor toolbox classes to trace, test, and replay Java and C++/Win32/Pthreads monitor-based programs.

Using Java Toolboxes Java program Buffer is shown in Listing 4.31. This program creates two pairs of Producer and Consumer threads and two SC boundedBuffer monitors, one for each Producer–Consumer pair. The Producer and

Consumer classes extend class TDThread instead of class Thread. This ensures that each thread receives a unique ID. We chose to supply names for the threads, monitors, and condition variables to make the traces more readable. These names can also be used in any test sequences that we generate by hand.

buffer = new int[capacity];

notFull = new conditionVariable("notFull"+num); notEmpty = new conditionVariable("notEmpty"+num);

}

public void deposit(int value) {

//the method name ‘‘deposit’’ is required for feasibility checking enterMonitor(‘‘deposit’’);

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

buffer[in] = value;

//generate communication event ‘‘deposit’’ for the Producer exerciseEvent(‘‘deposit’’);

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

}

public int withdraw() {

//the method name ‘‘withdraw’’ is required for feasibility checking enterMonitor(‘‘withdraw’’);

int value;

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

value = buffer[out];

//generate communication event ‘‘withdraw’’ for the Consumer exerciseEvent(‘‘withdraw’’);

out = (out + 1) % capacity; --fullSlots; notFull.signalC(); exitMonitor();

return value;

}

}

Listing 4.31 (continued )

When Buffer is executed, a property named mode specifies the function (tracing, replay, or testing) to be performed. An execution of Buffer is traced using the command

java –Dmode=trace Buffer

This creates three files. File monitor-replay.txt contains the simple M-sequence of the execution; file monitor-test.txt contains the M-sequence of the execution; and

file monitor-comm.txt contains the Communication-sequence of the execution. One control module is used to trace both monitors, so the simple M-sequence that is recorded is a totally ordered sequence containing events from both monitors. The same is true for the M-sequence and Communication-sequence that are recorded. Random delays can be executed during trace mode by setting property randomDelay to the value on.

java –Dmode=trace –DrandomDelay=on Buffer

When on is specified, random delays are executed before each (re)entry of a monitor. To turn random delays off, use off ; this is also the default value. The value of property randomDelay is ignored during replay and test modes. The deadlock detection method described in Section 3.8.4 has also been implemented in the monitor toolbox classes. To turn deadlock detection on during tracing or reachability testing, specify –DdeadlockDetection=on. To turn deadlock detection off, set property deadlockDetection to off ; this is also the default value.

If separate sequences are desired for each monitor, the controllers property can be used to create one controller per monitor. Valid values for this property are single, which is the default value, and multiple. For example,

java –Dmode=trace –DrandomDelay=on –Dcontrollers=multiple Buffer

creates multiple controllers, resulting in a separate simple M-sequence, complete M-sequence, and Communication-sequence for each monitor.

The simple M-sequence in file monitor-replay.txt is replayed using

java –Dmode=replay Buffer

As in Chapter 3, reachability testing is performed on Buffer by setting the mode property to rt and executing a driver process named RTDriver:

java –Dmode=rt –DdeadlockDetection=0n RTDriver Buffer

The feasibility of the M-sequence in file monitor-test.txt is determined using

java –Dmode=test Buffer

The feasibility of the Communication-sequence in file monitor-comm.txt is determined using

java –Dmode=commTest Buffer

The value used for property controllers during replay and testing must match the value that was used during tracing. If the mode is not specified, the default value for the mode property turns tracing, replay, and testing off. Specifying “–Dmode=none” has the same effect.

The M-sequence recorded during a program’s execution can be used to replay the execution. If the program is not modified after the M-sequence is recorded, the M-sequence remains feasible, and checking the feasibility of this feasible M- sequence (using –Dmode=test) amounts to replaying the execution. This means that we never actually have to use replay mode, since test mode can be used for replay, albeit with more overhead.

In trace mode, with random delays on, it is likely that nondeterministic testing will exercise several different M-sequences of the boundedBuffer monitor. This monitor is expected to have a capacity of 3. Even if we never see a trace with four consecutive deposit operations during nondeterministic testing, it is possible that boundedBuffer contains a fault that allows a deposit into a full buffer. Similarly, it is possible that a withdrawal is allowed from an empty buffer. To test these cases, we can specify two Communication-sequences and check their feasibility. A sequence that checks for an invalid withdrawal is

(comm, consumer,withdraw, NA) // withdraw from an empty buffer

The following invalid sequence contains four consecutive deposits:

(comm, producer, deposit, NA), (comm, producer, deposit, NA), (comm, producer, deposit, NA),

(comm, producer, deposit, NA). // deposit into a full buffer

If either of these Communication-sequences is feasible, a fault is detected in boundedBuffer. Alternatively, we can use reachability testing to check the feasibility of these sequences indirectly. That is, if neither of these sequences is exercised during reachability testing, they are infeasible.

Selecting sequences and checking their feasibility is part of a general testing technique called deterministic testing. In general, valid sequences are expected to be feasible and invalid sequences are expected to be infeasible. In Chapter 5 we describe deterministic testing and compare it to nondeterministic testing. In Chapter 7 the sets of valid and feasible sequences are used to provide a general definition of correctness for concurrent programs.

Using C++/Win32/Pthreads Toolboxes C++ program Buffer is shown in Listing 4.32. The mode of execution is specified using the environment variable MODE. The possible values for MODE are TRACE, REPLAY, TEST, RT (for Reachability T esting), COMMTEST (to determine the feasibility of a Communication-sequence), and NONE. For example, an execution of Buffer is traced in Windows by executing the command

and then executing program Buffer. In trace mode, random delays are controlled by variable RANDOMDELAY, just as we did for semaphores in Chapter 3:

Similarly, deadlock detection is controlled by variable DEADLOCKDETECTION:

set DEADLOCKDETECTION=ON

// Unix: setenv DEADLOCKDETECTION ON

An execution in TRACE mode creates trace files that contain the simple M- sequence, the M-sequence, and the Communication-sequence of the execution. (The files names are the same as those created by the Java trace mode.) The value of environment variable CONTROLLERS determines how many sequence files are created:

set CONTROLLERS=MULTIPLE // one simple M-sequence and M-sequence

//per monitor

//Unix: setenv CONTROLLERS MULTIPLE

The default value for CONTROLLERS is SINGLE.

As in Chapter 3, reachability testing is performed on Buffer by setting the MODE to RT and customizing the driver process in file RTDriver.cpp, which is part of the synchronization library. Directions for customizing the driver process are in the file.

Some development environments have powerful debuggers that make it possible to stop threads, examine the call stacks and variables of threads, suspend and resume threads, and more. Working with these debuggers may be frustrating, however, since stopping one thread may not stop the others, depending on the debugger. These debuggers are easier to use with a monitor toolbox. In replay mode you can set a breakpoint inside the control monitor at the point where a thread receives permission to execute the next event:

if (ID != nextEvent.getThreadID()) {

// nextEvent does not involve the requesting thread threads[ID].waitC(); // wait for permission

//get nextEvent again since it may have changed during the wait nextEvent = (monitorEvent)MSequence.elementAt(index);

}

// set breakpoint here; a thread has received permission to execute the next event.

With this breakpoint in place, it is possible to step through the execution and replay monitor events one at a time. Additional breakpoints can be set in the

run() methods of the threads to watch what each thread does between events, without disturbing the replay. The Win32 OutputDebugString() function can be used to send text messages to the debugger while the program is running. (In the Visual C++ environment, these messages appear in the tabbed window labeled “Debug.”) Of course, this entire process would be improved if tracing, testing, and replay were implemented as native functions of the development environment. In that case, the monitor toolbox classes can serve as portable, high-level designs for these implementations.

FURTHER READING

Per Brinch Hansen [2002] has written a personal account of how the monitor concept was invented. Hoare’s [1974] monitor paper presented the SU monitor construct and showed how to implement monitors using semaphores. The concept of a monitor toolbox is from Boddy [1983]. Brinch Hansen’s [1978] paper on reproducible testing of monitors is the earliest paper we know of on testing and replaying concurrent programs. Brinch Hansen [1973] also wrote an earlier paper on reproducible testing for operating systems. The monitor replay techniques presented in this chapter are from [Carver 1985; Carver and Tai 1991].

Greg Andrews [1991] shows how to prove the correctness of a monitor. Magee and Kramer’s book [1999] shows how to use labeled transition systems (LTS) to model monitor-based programs. They also show how to verify mechanically that a model satisfies specified correctness properties. Steven Robbins [2001] has developed a simulator for monitor solutions to the dining philosopher problem. This simulator can be used to explore how these solutions might behave in practice.

REFERENCES

Anderson, T. E., E. D. Lazowska, and Henry M. Levy (1989). The performance implications of thread management alternatives for shared-memory multiprocessors. IEEE Transactions on Computers, Vol. 38. No. 12, pp. 1631–1644.

Andrews, Gregory, R. (1991). Concurrent Programming: Principles and Practice. Redwood City, CA: Benjamin-Cummings.

Andrews, Gregory, R. (2000). Foundations of Multithreaded, Parallel, and Distributed Programming. Reading, MA: Addison-Wesley.

Boddy, D. E. (1983). Implementing data abstractions and monitors in UCSD Pascal. SIGPLAN Notices, Vol. 18, No. 5 (May), pp. 15–24.

Brinch Hansen, P. (1973). Testing a multiprogramming system. Software: Practice and Experience, Vol. 3, No. 2 (February), pp. 145–150.

Brinch Hansen, P. (1975). The programming language concurrent Pascal. IEEE Transactions on Software Engineering, Vol. 1, No. 2 (February), pp. 199–207.

Brinch Hansen, P. (1978). Reproducible testing of monitors. Software: Practice and Experience, Vol. 8, No. 6, pp. 721–729.

Brinch Hansen, P. (2002). The Origin of Concurrent Programming: From Semaphores to Remote Procedure Calls. New York: Springer-Verlag.

Butenhof, David R. (1997). Programming with POSIX Threads. Reading, MA: AddisonWesley.

Carver, R. H. (1985). Reproducible testing of concurrent programs based on shared variables. Master’s thesis, Computer Science Department, North Carolina State University, Raleigh, NC, 1985.

Carver, R. H., and K. C. Tai (1986). Reproducible testing of concurrent programs based on shared variables. Proc. 6th International Conference on Distributed Computing Systems, pp. 428–433.

Carver R. H., and K. C. Tai (1991). Replay and testing for concurrent programs. IEEE Software, Vol. 8. No. 2, pp. 66–74.

Choi, J., and H. Srinivasan (1998). Deterministic replay of Java multithreaded applications. Proc. ACM Sigmetrics Symposium on Parallel and Distributed Tools, pp. 48–59.

Dahl, Ole-Johan (2000). A note on monitor versions. In Jim Davies, A. W. Roscoe, and Jim Woodcock (Eds.), Millennial Perspectives in Computer Science: Proceedings of the 1999 Oxford–Microsoft Symposium in Honour of Sir Tony Hoare. Upper Saddle River, NJ: Prentice Hall.

Dahl, Ole-Johan, B. Myhrhaug, and K. Nygaard (1970). The SIMULA 67 Common Base Language. Technical Report, Publication S-22. Oslo, Norway: Norwegian Computing Center.

Hamburger, Henry, and Dana Richards (2002). Logic and Language Models for Computer Science. Upper Saddle River, NJ: Prentice Hall.

Hartley, Steven J. (1999). Alfonse, wait here for my signal! Proc. SIGCSE’99, pp. 58–62.

Hoare, C. A. R. (1974). Monitors: an operating system structure concept. Communication of the ACM, Vol. 17, No. 10 (October), pp. 549–557.

Howard, John H. (1976). Proving monitors, Communications of the ACM, Vol. 19, No. 5 (May), pp. 273–279.

JSR-133 (2004). Java memory model and thread specification. http://www.jcp.org/ aboutJava/communityprocess/review/jsr133/.

Lampson, Butler W., and David D. Redell (1980). Experience with processes and monitors in Mesa. Communications of the ACM, Vol. 23, No. 2 (February), pp. 105–117.

Lea, Doug (1999) Personal communication from Doug Lea to Steven J. Hartley in Hartley [1999].

Magee, Jeff, and Jeff Kramer (1999). Concurrency: State Models and Java Programs. New York: Wiley.

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, Vol. 15, No. 12 (December), pp. 1053–1058.

Robbins, Steven (2001). Starving philosophers: experimentation with monitor synchronization. Proc. 32nd SIGCSE Technical Symposium on Computer Science Education, pp. 317–321.

Turski, W. M. (1991). On starvation and some related issues. Information Processing Letters, Vol. 37, pp. 171–174.