Download Starvation - Operating System - Exam and more Exams Operating Systems in PDF only on Docsity!
Computer Science 15-410: Operating Systems
Mid-Term Exam (A), Spring 2007
1. Please read the entire exam before starting to write. This should help you
avoid getting bogged down on one problem.
- Be sure to put your name and Andrew ID below and also put your Andrew ID at the top of each following page.
- This is a closed-book in-class exam. You may not use any reference materials during the exam.
- If you have a clarification question, please write it down on the card we have provided. Please don’t ask us questions of the form “If I answered like this, would it be ok?” or “Are you looking for ...?”
- The weight of each question is indicated on the exam. Weights of question parts are estimates which may be revised during the grading process and are for your guidance only.
- Please be concise in your answers. You will receive partial credit for partially correct answers, but truly extraneous remarks may count against your grade.
7. Write legibly even if you must slow down to do so! If you spend some time to
think clearly about a problem, you will probably have time to write your answer legibly.
Andrew
Username
Full
Name
Question Max Points Grader
I will not discuss the contents of this 15-410 midterm with anybody, whether or not in this class, whether or not present in this exam session with me, before 19:30 Friday, March 2nd.
Signature: Date
Please note that there are system-call and thread-
library “cheat sheets” at the end of the exam.
Please note that there are system-call and thread-
library “cheat sheets” at the end of the exam.
- 15 points Process model.
During the “long” weekend between finishing up the thread library project and beginning the kernel project, you wondered if you could crash the reference kernel by violating the boundaries of your task’s address space. You decided to write three very short tests, each one probing whether some part of your address space could be read from or written to. In order to avoid messy test program crashes, you decided to use system calls instead of pointer accesses. Finally, you imposed diversity requirements on yourself.
- Each test would probe a different region/segment/area of the address space.
- At least one test would probe readability, and at least one would probe writability.
- At least one test should be “positive” (the read or write should be legal and should occur) and at least one test should be “negative” (the read or write should be illegal and should be rejected by the kernel).
You should be able to write each probe program in under 15 lines of code. Each should print the string “PASS” or “FAIL”, indicating whether the kernel’s response to your system call was correct or incorrect.
(a) 5 points This test probes the region/segment/area for readability / writability (circle one), which the kernel should allow / disallow (circle one).
(b) 5 points This test probes the region/segment/area for readability / writability (circle one), which the kernel should allow / disallow (circle one).
(c) 5 points This test probes the region/segment/area for readability / writability (circle one), which the kernel should allow / disallow (circle one).
(b) 15 points Now please write your test code. The suggested structure is one to three small helper functions and a main() function. Note that, as an interface-compliant test program, you cannot inspect or modify the internals of any thread-library data objects.
You may use this page as extra space for your “one-two test” solution if you wish.
What should be the result of running this program?
- Should it complete, hang, or crash?
- Should the kernel or the shell print any diagnostics? If so, what?
- If there are multiple alternative outcomes, briefly outline them.
Be sure to briefly but convincingly support your claims. Note that it is neither necessary nor desirable to provide a blow-by-blow description of the effect of each instruction on every register— your answer should focus on the questions listed above as well as describing significant other effects.
You may use this page as extra space if you wish.
Primary backup system
The primary backup system, developed by zero cool, serves to make daily backups of user file data and administrative configuration information (the per-machine user account list, software package configuration, log files, etc.) from each machine in the club’s server farm (as described above).
The primary backup system is executed as a daily cron (batch) job, starting at 03:00, and the entire session typically takes about two hours. The resource allocation procedure for this backup system is as follows.
Lock Tape Robot.
For each machine m ... Randomly pick a tape drive t to lock. Lock tape drive t.
Lock machine m. Dump the data on machine m to tape drive t. Unlock machine m.
Unlock tape drive t. ... repeat for all machines.
Unlock Tape Robot.
Note that primary backups are made to a random tape drive to avoid uneven wear.
Even though the resource allocation protocol involving multiple machines in a distributed environ- ment is complicated, it turns out that the locking semantics can be modeled by mutexes similar to those used in the Project 2 thread library.
This space intentionally left nearly blank.
(a) 2 points Add code to the following template to allocate resources and initiate backups as described by the primary backup procedure above. #define NUM_MACHINES 5
typedef enum {TAPE_DRIVE_A, TAPE_DRIVE_B} tape_drive_t;
/* Available functions (none of these can fail). / void backup_machine(int machine, tape_drive_t tape_drive); tape_drive_t choose_random_tape_drive(void); / Returns TAPE_DRIVE_A or TAPE_DRIVE_B. */ void mutex_lock(mutex_t *mp); void mutex_unlock(mutex_t *mp);
/* Available global variables. */ mutex_t machine[NUM_MACHINES]; / Includes mutexes for all machines. */ mutex_t *tape_drive_a, *tape_drive_b; mutex_t *tape_robot;
/* The primary backup system. / void primary_backup(void) { / Fill in code here. */
}
(c) 2 points Add code to the following template to allocate resources and initiate backups as described by the database backup procedure above. #define NUM_MACHINES 5 #define DB_MACHINE 2 /* cadmium, from table */
typedef enum {TAPE_DRIVE_A, TAPE_DRIVE_B} tape_drive_t;
/* Available functions (none of these can fail). */ void database_backup(tape_drive_t tape_drive); void mutex_lock(mutex_t *mp); void mutex_unlock(mutex_t *mp);
/* Available global variables. */ mutex_t machine[NUM_MACHINES]; / Includes mutexes for all machines. */ mutex_t *tape_drive_a, *tape_drive_b; mutex_t *tape_robot;
/* The database backup system. / void database_backup(void) { / Fill in code here. */
}
(d) 3 points Draw a process/resource graph illustrating the state of the system when a database dump is being written to tape drive B.
The plot thickens
One day, a Computer Club user sends mail stating that he accidentally trashed his home directory and needs it restored from backup. Computer Club operator zero cool fetches the most recent backup tape and discovers that the most recent backup was made five months ago! Performing a cursory equipment scan, zero cool determines that Tape Drive A has a tape loaded in it and all the equipment appears to be functioning correctly. However, neither primary backups nor database backups have been performed, for some unknown reason, for the past five months. Of course, zero cool assumes that the problem must be due to a bug in crash override’s database backup script that caused the tape robot to malfunction. Meanwhile, crash override also discovers the backup failure, and assumes the problem must be due to a bug in zero cool’s primary backup script. They begin an argument with each other and defend their respective code bases by showing their process/resource graphs to prove that each one’s code contains no bug that could have resulted in this condition.
(g) 5 points What is the simplest change you could suggest making to the system as a whole which would eliminate this problem?
System-Call Cheat-Sheet
/* Life cycle */ int fork(void); int exec(char *execname, char *argvec[]); void set_status(int status); void vanish(void) NORETURN; int wait(int *status_ptr); void task_vanish(int status) NORETURN;
/* Thread management / int thread_fork(void); / Prototype for exam reference, not for C calling!!! */ int gettid(void); int yield(int pid); int cas_runflag(int tid, int *oldp, int *expectp, int newp); int get_ticks(); int sleep(int ticks); / 100 ticks/sec */
/* Memory management */ int new_pages(void * addr, int len); int remove_pages(void * addr);
/* Console I/O */ char getchar(void); int readline(int size, char *buf); int print(int size, char *buf); int set_term_color(int color); int set_cursor_pos(int row, int col); int get_cursor_pos(int *row, int *col);
/* Miscellaneous */ void halt(); int ls(int size, char *buf);
/* "Special" */ void misbehave(int mode);
