9.1 Golf Club Program

9.1 Golf Club Program

A golf club has a limited number of golf balls available for hire. Players can hire golf balls for their game from the club and return them to the club after use. Expert players, who tend not to lose any of their golf balls, only hire one or two. Novice players hire more balls, so that they have spares during the game in case of loss. However, they are required to buy replacements for lost balls so that they return the same number that they originally hired. To simulate the golf club as a Java program, we create a new thread for each player arriving at the golf club and use a monitor to control the hiring of golf balls to players. The display for the program is shown in Figure 9.1.

Figure 9.1: Golf Club applet display.

New players, with their golf ball requirements indicated in parentheses, are created by clicking the buttons at the bottom of the display. Each newly created player is given a name consisting of a letter, allocated consecutively in alphabetic order, and the number of golf balls the player requires. A newly created player appears briefly in the “new” window and then appears in the “wait golf balls” window if there are not enough golf balls available for the player to start playing. When the player acquires golf balls and starts playing, its identity appears in the “playing” window. When finished playing, the player’s identity appears briefly in the “end” window. The “SimpleAllocator” window displays the state of the monitor controlling golf ball allocation. The maximum number of golf balls available is set to five.

Figure 9.1 depicts the situation in which there are currently no golf balls available for hire since all five are in use by players c2, f1, e1 and g1. The novice player d4 who requires four golf balls to start playing is thus waiting. Note that the expert players e1, f1 and g1 were created after d4. They have started playing before d4 since at the time they requested golf balls, there were enough to satisfy their requirements but not enough to satisfy d4. In fact, if we keep creating new expert golfers that only require one or two golf balls, then the novice d4 will continue waiting. A continuous stream of expert players arriving at the golf club can cause novices to wait forever. In other words, the program has a liveness problem in which novice players may experience starvation. Before examining this problem in more detail using a model, we describe the program that drives the display of Figure 9.1. The classes involved are depicted in the UML class diagram of Figure 9.2.

Figure 9.2: Golf Club class diagram.

We are going to develop a number of implementations of the golf ball allocator. To allow us to substitute these implementations without modifying the rest of the program, we define the Java interface Allocator as listed in Program 9.1. The DisplayAllocator class implements this interface and delegates calls to get and put golf balls to SimpleAllocator which actually implements the allocation monitor. In addition, DisplayAllocator displays the state of the monitor using the StringCanvas class we have used in previous chapters. The code for the SimpleAllocator monitor is also listed in Program 9.1.

Program 9.1: Allocator interface and SimpleAllocator class.

 public interface Allocator {   //get n golf balls   public void get(int n) throws InterruptedException;   //put back n golfballs   public void put(int n); } public class SimpleAllocator implements Allocator {   private int available;   public SimpleAllocator(int n)     { available = n; }   synchronized public void get(int n)            throws InterruptedException {     while (n>available) wait();     available -= n;   }   synchronized public void put(int n) {     available += n;     notifyAll();   } }

From Program 9.1, it can be seen that a call to get n golf balls will block a calling thread until enough balls become available. When a thread returns golf balls, all blocked threads are awakened so that they can see if there are now sufficient for them to proceed. Notice that this allows a thread trying to get a large number of golf balls to remain blocked while a thread requiring fewer can proceed.

The PlayerArrival class creates new Player threads in response to button presses. Each newly created thread is passed a reference to the applet class GolfClub. The thread needs this reference since it calls the golf ball allocator monitor indirectly via the GolfClub methods getGolfBalls() and relGolfBalls(). The program has been organized this way to avoid passing all the display objects to every newly created thread. The code for the Player class is listed in Program 9.2.

Program 9.2: Player class.

 class Player extends Thread {   private GolfClub gc;   private String name;   private int nballs;   Player(GolfClub g, int n, String s) {      gc = g; name = s; nballs =n;   }   public void run() {     try {       gc.getGolfBalls(nballs,name);       Thread.sleep(gc.playTime);       gc.relGolfBalls(nballs,name);     } catch (InterruptedException e){}   } }

Notice that, in contrast to the threads we have defined in previous chapters, the run() method of the Player class does not involve a loop. After it has been started, the player gets the golf balls it requires by calling getGolfBalls(), sleeps for a period of time to simulate playing and then releases the golf balls using relGolfBalls(). The run() method then terminates. Rather than listing the entire code for the class GolfClub, since it is rather lengthy, we have listed below the two methods used by Player:

 void getGolfBalls(int n, String name)          throws InterruptedException {   String s = name+n;   starting.enter(s);   Thread.sleep(500);   starting.leave(s);   waiting.enter(s);   alloc.get(n);   waiting.leave(s);   playing.enter(s); } void relGolfBalls(int n, String name)           throws InterruptedException {   String s = name+n;   alloc.put(n);   playing.leave(s);   ending.enter(s);   Thread.sleep(500);   ending.leave(s); }

These methods access the allocator monitor using alloc which references the DisplayAllocator object which in turn calls SimpleAllocator as previously explained. The references starting, waiting, playing and ending refer to instances of the SlotCanvas class. This is the first time we have used this display class. An outline of the methods it provides is listed in Program 9.3.

Program 9.3: SlotCanvas class.

 public class SlotCanvas extends Canvas {   ...   //create display with slots boxes   public SlotCanvas     (String title, Color c, int slots) {...}   //enter the string name in an empty box   public synchronized void enter(String name){...}   //clear the box containing name   public synchronized void leave(String name) {...}   ... }

This completes the description of the golf club program. As discussed previously, it has the problem that novices can wait forever to play while they are continuously overtaken by expert players. In the next section, we investigate a solution to this liveness problem by modeling the golf club.