Java Reference
In-Depth Information
Let us summarize how the various events are processed. If the event is a
hang-up, we increment availableOperators at line 19 and print a message at
lines 20 and 21. If the event is a dial-in, we generate a partial line of output that
records the attempt, and then, if any operators are available, we connect the
user. To do so, we decrement availableOperators at line 29, generate a connec-
tion time (using a Poisson distribution rather than a uniform distribution) at line
30, print the rest of the output at lines 31-32, and add a hang-up to the event set
(lines 33-35). Otherwise, no operators are available, and we give the busy sig-
nal message. Either way, an additional dial-in event is generated. Figure 13.10
shows the state of the priority queue after each deleteMin for the early stages of
the sample output shown in Figure 13.4. The time at which each event occurs is
shown in boldface, and the number of free operators (if any) are shown to the
right of the priority queue. (Note that the call length is not actually stored in
an Event object; we include it, when appropriate, to make the figure more self-
contained. A '?' for the call length signifies a dial-in event that eventually will
result in a busy signal; however, that outcome is not known at the time the event is
added to the priority queue.) The sequence of priority queue steps is as follows.
A hang-up increases
avaliableOpera-
tors . A dial-in
checks on whether
an operator is avail-
able and if so
decreases avail-
ableOperators .
1.
The first DIAL_IN request is inserted.
2.
After DIAL_IN is removed, the request is connected, thereby resulting
in a HANG_UP and a replacement DIAL_IN request.
3.
A HANG_UP request is processed.
4.
A DIAL_IN request is processed resulting in a connect. Thus both a
HANG_UP event and a DIAL_IN event are added (three times).
5.
A DIAL_IN request fails; a replacement DIAL_IN is generated (three
times).
6.
A HANG_UP request is processed (twice).
7.
A DIAL_IN request succeeds, and HANG_UP and DIAL_IN are added.
Again, if Event were an abstract base class, we would expect a procedure
doEvent to be defined through the Event hierarchy; then we would not need
long chains of if/else statements. However to access the priority queue,
which is in the simulation class, we would need Event to store a reference to
the simulation CallSim class as a data member. We would insert it at construc-
tion time.
A minimal (in the truest sense) main routine is shown for completeness in
Figure 13.11. Note that using a Poisson distribution to model connect time is not
appropriate. A better choice would be to use a negative exponential distribution
The simulation uses
a poor model. Neg-
ative exponential
distributions would
more accurately
model the time
between dial-in
attempts and total
connect time.
 
Search WWH ::




Custom Search