Download Keyboard Interrupts - Operating System - Exam and more Exams Operating Systems in PDF only on Docsity!
Computer Science 15-412: Operating Systems
Midterm Exam, Spring 2003
- This is a closed-book, closed-notes, in-class exam. You may not use any reference materials during the exam.
- You must complete the exam by the end of the class period.
- Answer all questions. The weight of each question is indicated on the exam.
- Please be concise in your answers. You will receive partial credit for partially correct answers, but truly extraneous remarks may count against your grade.
- Be sure to put your name and Andrew ID below and your Andrew ID at the top of each following page.
Andrew
Username
Full
Name
Question Max Points Grader
- Are keyboard interrupts really necessary? Outline an approach, suitable for a pre- emptively scheduled multi-user, multi-process operating system, for ensuring timely delivery of keypress events from the keyboard controller’s I/O port to waiting processes without the use of keyboard interrupts. Assume that a person pressing a key needs to see the response on the screen in 50-60 milliseconds, that reasonable scheduling quantum values range from 5 milliseconds to 20 milliseconds, and that your solution must work even if there are “many” (e.g., 100) processes running and all of them choose to call a blocking getchar() system call inside a tight loop.
(b) Here are graph nodes for three states a process can be in. Draw directed arcs (i.e., arrows) between the nodes to indicate all legal transitions. Label each arc with a 1-word summary term and then, below the figure, provide a brief explanation (1 or 2 sentences should suffice) of what you meant by each summary term. For any node pair (i,j) you do not need to draw more than a single arc from i to j, i.e., you do not need to draw more than six arcs (and you may need to draw fewer). Another way to say this is that, for each transition, you need provide us with only one explanation of why such a transition happens.
running
sleeping
runnable
(c) Imagine you and your programming partner are both logged in to UNIX3.ANDREW.CMU.EDU when you are seized by an impulse to disrupt your partner’s calm, cool demeanor. Your first idea is to write a C program which will write zeroes throughout the address space of your partner’s shell (command interpreter, i.e., bash, tcsh, etc.). To your sadness you discover that the operating system has placed an insurmountable hardware barrier in your path. Explain why you have no hope of accessing memory belonging to your partner’s processes.
struct mutex {
void mutex_init(struct mutex *mp) {
void mutex_lock(struct mutex *mp) {
void mutex_unlock(struct mutex *mp) {
- Imagine a multi-threaded version of the children’s card game “Concentration”. The game is played with a two-dimensional array of cards which are face-down. Players take turns selecting two cards and turning them face-up. If the cards match, the player captures the pair of cards; otherwise, the player must turn both cards face-down and another player takes a turn. The code below plays the game according to a very naive strategy, but that is not as significant as the fact that it will occasionally deadlock if multiple threads run play() simultaneously.
int cards[6][6]; mutex lock[6][6]; mutex pairs_lock; int pairs_left; int everybody_done;
void init(void) { ...shuffle 36-card deck into cards[ ][ ] ...mutex_init() all of lock[ ][ ]... mutex_init(&pairs_lock); pairs_left = 18; everybody_done = 0; }
int play() { int score = 0; while (!everybody_done) { int i1, j1, i2, j2, tmp1, tmp2, tmp3, tmp4;
i1 = generate_random(0, 5); j1 = generate_random(0, 5); i2 = generate_random(0, 5); j2 = generate_random(0, 5);
if ((i1 == i2) && (j1 == j2)) continue;
mutex_lock(lock[i1][j1]); mutex_lock(lock[i2][j2]);
if ((cards[i1][j1] == cards[i2][j2]) && (cards[i1][j1] != GONE)) { ++score; cards[i1][j1] = cards[i2][j2] = GONE; mutex_lock(pairs_lock); if (--pairs_left == 0) everybody_done = 1; mutex_unlock(pairs_lock); } mutex_unlock(lock[i1][j1]); mutex_unlock(lock[i2][j2]); } return (score); }
- Consider the following critical-section protocol:
boolean waiting[2] = { false, false }; int turn = 0;
- waiting[i] = true;
- while (turn != i) {
- while (waiting[j])
- /* do nothing */ ;
- turn = i; }
- ...critical section...
- waiting[i] = false;
- ...remainder section...
(This protocol is presented in the standard form, i.e., if process 0 is running this code, i == 0 and j == 1; if process 1 is running this code, i == 1 and j == 0.) There is a problem with this protocol. That is, it does not ensure that all three require- ments (mutual exclusion, progress, and bounded waiting) are always met. Identify a requirement which is not met and lay out a scenario which demonstrates your claim. Use the format presented in class, i.e., P0 P waiting[0] = false; turn = 0;
