Page 831 - Introduction to Programming with Java: A Problem Solving Approach

Figure A9.3 shows the class that describes Predator threads. It also extends the Thread class. It also has an instance variable that refers to the encounter relationship—a fox is certainly aware of its pleas- ant relationship with field mice. It also has a zero-parameter constructor, and it also has a setEncounter method.
Notice that Predator also declares an array of delay times. With appropriate cross referencing, we could have put this program’s time-delay information in any of the classes. But because the predator is the primary “cause” of encounters, we elected to put it in Predator’s definition and implement it in the Predator’s run method. This time-delay implementation makes Predator’s run method more com- plicated than Prey’s run method. We implement each delay by passing an integer number to the pre- written sleep method, which is in the Thread class in the always-available java.lang package:
public static void sleep(long millis)
throws InterruptedException
What does this sleep method do? It makes the currently executing thread cease its execution for a number of milliseconds equal to the parameter value. In our example, the first element in the DELAY array is 2347, so when you run the program, you will experience a pause of 2.347 seconds between the first and second screen outputs.
Notice that the sleep method can throw an InterruptedException. If you look up InterruptedException, you’ll find that it’s derived directly from the Exception class, so it is a checked exception. Therefore, the method call that might throw this exception must be in a try block, and that’s where we put it. Our program never does anything that might cause this exception to be thrown,3 so we use an empty catch block. For better debugging feedback, you could put something like e.printStackTrace(A)pinathegcoatchPblDocFk. Enhancer
Now let’s look at a first crude attempt to implement the Encounter class, which appears in Figure A9.4. In the lives of a single predator and a group of its prey (our chosen threads), encounters occur several times. We might have written our Encounter class so that each encounter object represented one discrete event, but it’s easier to keep track of time and space relationships if you group related events together. Thus, one of our encounter objects represents a complete sequence of encounters between our predator thread and our prey thread. In simulation programming, this kind of on-going relationship is usually called a process.
The instance variables in the encounter object keep track of the total number of events, the se- quence number of the current event, and references to the prey and predator threads. If you look back at Figure A9.1, you’ll see that we call the Encounter constructor after we call the Prey and Predator constructors. This calling sequence enables us to pass predator and prey references to the encounter object when we instantiate it. Then, in the Encounter constructor we reciprocate by sending an encounter reference to the to the predator and prey objects.
Now look at the beApart and beTogether methods. These represent the two phases of the ongoing encounter relationship. The beApart method describes a long quiescent period in which the predator rests and hunts. It’s called by the Prey class in Figure A9.2. The beTogether method describes a short violent period in which the predator finds prey, attacks, and eats part of the prey. It’s called by the Predator class in Figure A9.3.
As they appear in Figure A9.4, these two methods don’t do very much. The beApart method updates the cycle number. Then it prints the name of the thread that called it and the cycle number’s current value.
3 An InterruptedException is thrown when the current thread is sleeping and another thread prematurely wakes it by calling its interrupt method, but our program never uses the interrupt method.
Appendix 9 Multithreading 797