first commit
This commit is contained in:
45
CS4210/Homework 2/hw2_gtg184g_answers.txt
Normal file
45
CS4210/Homework 2/hw2_gtg184g_answers.txt
Normal file
@@ -0,0 +1,45 @@
|
||||
Question 1:
|
||||
-----------
|
||||
|
||||
Task 1: CPU bound
|
||||
Task 2-11: I/O bound tasks
|
||||
CS: context switch
|
||||
|
||||
Assumptions:
|
||||
1) Queue is in above order
|
||||
2) Scheduler is not preemptive (will not switch out tasks waiting on I/O)
|
||||
3) Executes next "ready" thread in FCFS order
|
||||
|
||||
a) 1, CS, 2, CS, 3, CS, 4, CS, 5, CS, 6, CS, 7, CS, 8, CS, 9, CS, 10, CS, 11, CS, 1, CS, 2, CS, 3, CS, 4, ...
|
||||
|
||||
In this case, the quanta is 1 ms, so the I/O bound threads will not be wasting CPU time by using a 10ms quanta when only using 1ms of CPU time. The .1 ms of context switch time becomes the real drawback here. In this case, the CPU will ALWAYS be utilized (discounting context switch time). The utilization will be 100% (assuming the context switch counts as CPU utilization). It will be 1/(quanta+context Switch time) utilization = 1/1.1 ~= 90.9%
|
||||
|
||||
b) 1, CS, 2, CS, 3, CS, 4, CS, 5, CS, 6, CS, 7, CS, 8, CS, 9, CS, 10, CS, 11, CS, 1, CS, 2, CS, 3, CS, 4, ...
|
||||
|
||||
In this case, the CPU will be under-utilized. Tasks 2-11 will use a single millisecond of CPU time and then sit there, idle. Because of this, 9ms out of 10ms will be wasted for the 10 I/O bound tasks and the CPU bound task will use its full 10ms on the CPU. If the RR scheduler is fully preemptive, as in Windows NT4+ and Linux 2.6+, the I/O threads will be switched out as soon as they finish their CPU usage and make the I/O request. If this is the case, then the CPU usage will be 100% (assuming the context switch counts as CPU utilization) or (10+10)/(11*.1 + 10 + 10) ~= 94.7% if the context switch does not count as CPU util. If the former is the case, then for 10 of the 11 tasks, 9ms will be wasted CPU time. In this case, the utilization will be (10+10)/(110+11*.1) ~= 18% (context switches count as wasted time).
|
||||
|
||||
c) If the scheduler is scheduling to increase CPU utilization with parameters such as in case b, the I/O bound tasks will get starved. However, if it schedules to increase I/O device utilization, the CPU will be wasted. In case a, the quanta is short enough with these specific tasks, that both are being utilized fully. However, the context switch time will become a drawback.
|
||||
|
||||
Question 2:
|
||||
-----------
|
||||
a) Deadlock.
|
||||
|
||||
b) No Deadlock.
|
||||
|
||||
c) No Deadlock.
|
||||
|
||||
d) Deadlock.
|
||||
|
||||
e) Deadlock.
|
||||
|
||||
Question 3:
|
||||
-----------
|
||||
|
||||
"In Solaris, one side-effect of preemption is that if the target thread is blocked in the kernel executing a system call, it will be interrupted by SIGLWP, and the system call will be re-started when the thread resumes execution after the preemption. This is only a problem if the system call should not be re-started."
|
||||
Basically, the process will be switched, and the system call will be restarted when the process gets processor time again.
|
||||
|
||||
In Psyche, the system call mechanism is the "protected procedure call" mechanism. When a thread makes a blocking system call that can be completed in a single quanta, it will get a "reply from PPC" and continue execution. However, if it is preempted to be switched while waiting on the call, it will be switched and as soon as it gets scheduled again, it will get a "blocked in the kernel" interrupt and an "unblocked in kernel" interrupt when the call completes and it can continue executing.
|
||||
In short, the system call does not need to be restarted.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user