Now that I'm actually at this part of the assignment, am I right in saying
that II.C.1 should be changed from
10. When the (Arrival, teardown, 2.a) event eventually occurs
a. all requests being serviced, all requests that are queued, and all
pending events that are part of the call are removed from the
system, and
b. the ghost puts an Arrival event containing a connexion request
into the event set.
to
10. When the (Arrival, teardown, 2.a) event eventually occurs
a. the teardown request is enqueued at the CPU, and
b. the ghost puts an Arrival event containing a connexion request
into the event set.
11. When the teardown request (10.a) is dequeued,
a. a Departure event containing the teardown request is put into the
event-set
12. When the (Departure, teardown, 11.a) event occurs,
a. all requests being serviced, all requests that are queued, and all
pending events that are part of the call are removed from the
system
and the same with the application use case?
From Tom G
Post by Tom GaultCool, okay thanks.
From Tom G
Post by Stephen LewchukPost by Tom GaultEasy now, don't be rude. I agree with Tom J, it's still not totally clear.
II.C.1.10.a says,
"When the (Arrival, teardown, 2.a) event eventually occurs: all requests
being serviced, all requests that are queued, and all pending events
that are part of the call are removed from the system."
This suggests that special code is going through servers and queues like
an angel of death, wiping out selected requests. Professor Cowan's post
and the existance of the CPU parameters suggests that a call or an app
is stopped by instructing the CPU to do something, but what? Does the
CPU kill the requests in all of the queues and servers? Does it do it
when the event happens or when the request is dequeued? Does it just
stop forwarding that call/app on the next cycle?
From Tom G
Post by Stephen LewchukPost by TomPost by William CowanPost by TomIn the phone call description it has a teardown event going into the
event set (2a) and when it is eventually handled (10) it does not
mention a teardown request queuing at the CPU. However, number 2 in
the system parameters section asks for the mean and stddev of the
CPU servicing an arrival teardown request. When is that supposed to
happen?
The teardown request takes some time to execute, so it has service parameters. It
should set a departure event for the end of the time it occupies the
CPU so that the
next request will be unqueued and serviced.
Bill
So instead of being handled directly when the arrival event of a
teardown request occurs, the request should be enqueued at the CPU,
and then a departure event will be created with the teardown request
once that is finished from the CPU, and that is where the teardown is
actually handled.
I do not see any of this documented in the implementation section of
the assignment.
This is what Cowan told us and that is what he meant.
Stephen
Sorry if I came off as rude. I went and talked to him in person and was
trying to confirm that your interpretation is correct, teardown events
enqueue teardown requests which once serviced actually remove all the
other events from servers.
Stephen