{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Computer Science 162 - Spring 1997 - Harvey - Midterm 1

Computer Science 162 - Spring 1997 - Harvey - Midterm 1 -...

Info icon This preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
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
Image of page 1

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
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. We also accepted "Increase the priority when a process blocks," but that isn't really quite right. A process can block for many reasons other than interacting with the user. Something like compiling a large program is likely to be I/O-bound much of the time, but that doesn't mean it should have the same priority as something like a text editor.
Image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}