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