This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: file:///C|/Documents%20and%20Settings/Jason%20Raftery/My%20Doc...e%20162%20-%20Spring%201997%20-%20Harvey%20-%20Midterm%201.txt CS 162 Spring 1997 Midterm 1 solutions 1. Why turn off ints in project 2 but not project 1? In project 1, the shared data that might need protection are used *only* in system calls, and one system call can't be preempted to run another one. In project 2, the shared data are used both by system calls and by events initiated by interrupts (such as scheduling initiated by clock interrupts, but also I/O device interrupts). The interesting case is when a setrunqueue() interrupts a setrunqueue() in progress. For example, suppose that someone blocks reading from the disk. Then a call to setrunqueue() is initiated by the scheduler because of a clock tick. When the disk transfer is complete, an asynchronous device interrupt wants to wake up the process sleeping on the data buffer, so it makes a second call to setrunqueue(), interrupting the first in progress. We gave one point for an answer that explained one project but not the other. We also gave one point for an answer saying that the clock-level events must be protected against system-call events; it's actually the other way around (and also one interrupt against another). The worst zero-point answer, which we saw far too often, was "project 1 implements semaphores, and semaphores provide synchronization, so we don't also need to turn off interrupts." Semaphores are an abstraction that provide synchronization *to the users of the semaphores* but the *implementation* of semaphores does have to worry about making sure that's the case! Specifically, if the semaphore mechanism we invented was to be used by the kernel itself as well as by user programs, we would indeed have to turn off interrupts there. Other zero-point answers were "system calls are atomic" and "system calls can't be interrupted." System calls can't be *preempted by another user process* but they can, and often are, interrupted by bottom-half activities such as I/O interrupts. 2. How to fix the CTSS scheduler? The answer I was expecting is this: Increase the priority of a process when the user completes a line *and the process was blocked waiting for keyboard input*. This solution is closest in spirit to the original file:///C|/Documents%20and%20Settings/Jason%20Raft...20Spring%201997%20-%20Harvey%20-%20Midterm%201.txt (1 of 8)1/27/2007 4:01:28 PM file:///C|/Documents%20and%20Settings/Jason%20Raftery/My%20Doc...e%20162%20-%20Spring%201997%20-%20Harvey%20-%20Midterm%201.txt CTSS scheduler's approach. Since it doesn't matter what priority a process has while it's blocked, we can, without changing the behavior of the scheduler, increase the priority as soon as the process blocks for keyboard input, without waiting for the user to type something. This, too, is a fine two-point answer....
View Full Document
This note was uploaded on 05/17/2009 for the course CS 162 taught by Professor Kubiatowicz during the Spring '02 term at Berkeley.
- Spring '02
- Computer Science