CS 537 - Sample Quiz #7

	UNIVERSITY OF WISCONSIN-MADISON Computer Sciences Department
CS 537 Fall 2007		A. Arpaci-Dusseau
	Sample Quiz #7 -- Deadlock and Scheduling

Problem 1: Conditions for Deadlock (35 points)

There are four conditions that are necessary for deadlock to occur: mutual exclusion, hold and wait, no preemption, and circular wait. With deadlock prevention, the system ensures that deadlock does not occur by preventing one of these conditions from holding. Match each of the following techniques with the one deadlock condition that it prevents.


a.  Mutual exclusion
b.  Hold and wait
c.  No preemption
d.  Circular wait

_d_ Impose a total ordering (or ranking) on how resources are acquired

_c_ When a process requests a resource that is already held, 
      force the process holding the resource to release it

_b_ Only allow a process to request a resource when the process has none

_a_ Allow all processes to access the resource simultaneously

_b_ Require each process to grab all desired resources at once

Problem 2: Existance of Deadlock (45 points)

Can running each of the following code segments lead to deadlock of process 0 and process 1? Simply answer "yes" or "no".

Code Sample 1 Process 0: Process 1: lock1.acquire(); lock1.acquire(); lock2.acquire(); lock2.acquire(); lock1.release(); lock1.release(); lock2.release(); lock2.release();
No deadlock possible, because there is no circularity of requests. Both processes grab the locks in the same order.

Code Sample 2 Process 0: Process 1: lock1.acquire(); lock2.acquire(); lock2.acquire(); lock1.acquire(); lock1.release(); lock1.release(); lock2.release(); lock2.release();
Deadlock is possible, because there is circularity. If process 0 acquires lock1 and then process 1 acquires lock2, both will be stuck holding one lock while waiting for the other.

Code Sample 3 Process 0: Process 1: lock1.acquire(); lock2.acquire(); lock2.acquire(); lock2.release(); lock1.release(); lock1.acquire(); lock2.release(); lock1.release();
No deadlock possible, because process 1 does not hold and wait. Even if process 0 acquires lock1 and process 1 acquires lock2, eventually process 1 will release lock2, at which point process 0 will be able to acquire lock 2.

Problem 3: Resource-Allocation Graph (20 points)

Running which of the above code samples could lead to the situation shown in the following resource-allocation graph? Indicate all of the possible code samples that apply.

Possible with Code Sample 1 given the following execution:

Process 0: Process 1: lock1.acquire(); lock2.acquire(); lock1.acquire(); // waits!

Not possible with Code Sample 2; if Process 1 is waiting for lock1, it must hold lock2, which isn't shown in the figure.

Possible with Code Sample 3 given the following execution:

Process 0: Process 1: lock2.acquire(); lock2.release(); lock1.acquire(); lock2.acquire(); lock1.acquire(); // waits!

Problem 4: General Scheduling

a) Consider a workload with 5 jobs that each compute for an identical amount of time, x, and that perform no I/O. To minimize the average waiting time of the jobs, should a FCFS scheduler or a RR scheduler be used?


FCFS (first-come-first-served) minimizes the average waiting time better
than RR (round-robin) whenever the computatation times of jobs in a
workload is identical.

b) Assume that job A is running on the CPU. Describe two circumstances in which a SJF scheduler will keep job A running, but a STCF scheduler will pick a different job.


SCTF (Shortest-completion-time-first) is a preemptive version of SJF
(Shortest-job-first).  Therefore, with STCF if a job with a shorter CPU
burst than the currently running job becomes READY, the READY job will be
scheduled over the currently running job; SJF will not schedule the ready
job.

As shown in Figure 4.1 in the textbook, there are two cases in which a
process enters the READY state.

1.  A new job enters the system.

2.  An I/O event completes for a job.

Problem 5: Solaris Dispatch Table

To answer this problem, use the dispatch table that is appended at the end of the quiz (it is identical to the default dispatch table in Solaris).

a) Consider a process that is at priority 49.

How long is the time-slice of this process?
40ms
When the process consumes its time-slice, what will its new priority be?
39
If the process is sleeping when the 1 second update timer expires, what will its new priority be?
58

b) Consider a workload containing only a single process. Assume that this process is completely CPU-bound. Draw a timeline showing the priority of that process for the first 600ms of its lifetime. In all of your timelines, clearly show both the priority of the job and the time at which the priority of the process changes. Assume that the 1 second update timer does not run in this interval. (Hint: Processes start at priority 29.)


Timeline is not drawn to scale. 

Pri:     29           19            9             0
    |-----------|------------|-------------|----------|
    0           120ms       280ms          480        600

c) Consider a new workload containing a single process; this process repeatedly computes for 20ms and then sleeps for 1000ms. Draw a timeline showing the priority of this process for 3 iterations of its compute/sleep cycle. You can assume that the 1 second update timer begins its cycle at the same time the process enters the system (i.e., the timer expires 1 second after the process begins executing).


Timeline is not drawn to scale. 

Pri: 29      sleep               52    sleep           58   sleep
    |----|---------------------|----|----------------|----|-------------|
    0    20ms                  1020 1040             2040 2060          3060

When the update timer runs at 1000ms and 2000ms, it increments the dispwait 
variable of the job to 1.  When the job wakes, it sees that 
dispwait > maxwait (0), so the priority of the job is raised to that 
specified by slpret and dispwait is set back to 0.