Download Assignment 5 - Operating Systems - Fall 2007 | CS 4414 and more Assignments Operating Systems in PDF only on Docsity!
CS 414: Operating Systems
Fall 2007
Assignment
Due Tuesday Nov 20, 11am
WORTH DOUBLE POINTS!!!
Part 1. (worth 25%). Short Answer (Answer all 12 questions by yourself).
- Suppose threads T0 and T1 require access to variable V2, threads T1 and T2 require access to variable V0, and threads T2 and T3 require access to variable V1. a. Show the code for how the threads can use enableInterrupts() and disableInterrupts() to coordinate access to V0, V1, and V2 so that the requirements of the critical section problem are satisfied b. Show the code for how the threads can use semaphores to coordinate access to V0, V1, and V2 so that the requirements of the critical section problem are satisfied. Make sure to give initial values for the semaphores. c. Show the code for how the threads can use monitor(s) to coordinate access to V0, V1, and V2 so that the requirements of the critical section problem are satisfied.
- Dijkstra posed each of the following solutions as a possible software solution to the critical section problem and then explained why they failed [Dijkstra, 1968]. Explain why they failed. (That is, each of these show the code for a process that – when executed – creates two threads, each of which executes a routine. Assume the two threads are concurrently executing the code and explain precisely how the code fails.)
(a) int turn; /* shared */
void MyThreadFunc (int i) { while (TRUE) { compute(); while (turn != i) // do nothing ; execute_code_in_critical_section(); turn = (i + 1) mod 2; } } turn = 1; CreateThread(MyThreadFunc, 0); // pass “0” as the argument to “MyThreadFunc” CreateThread(MyThreadFunc, 1);
(b) boolean flag[2]; /* shared */
void MyThreadFunc (int i) { while (TRUE) { compute(); while (flag[(i+1) mod 2]) // do nothing ; flag[i] = TRUE; execute_code_in_critical_section(); flag[i] = FALSE; }
flag[0] = flag[1] = FALSE; CreateThread(MyThreadFunc, 0); CreateThread(MyThreadFunc, 1);
(c) boolean flag[2]; /* shared */
void MyThreadFunc (int i) { while (TRUE) { compute(); flag[i] = TRUE; while (flag[(i+1) mod 2]) // do nothing ; execute_code_in_critical section(); flag[i] = FALSE; } } flag[0] = flag[1] = FALSE; CreateThread(MyThreadFunc, 0); CreateThread(MyThreadFunc, 1);
- (Question 7.11 from 7th^ edition) Consider the following snapshot of a system: Answer the following questions using the banker’s algorithm:
Allocation Max Available A B C D A B C D A B C D P0 0 0 1 2 0 0 1 2 1 5 2 0 P1 1 0 0 0 1 7 5 0 P2 1 3 5 4 2 3 5 6 P3 0 6 3 2 0 6 5 2 P4 0 0 1 4 0 6 5 6
a. What is the content of the matrix Need? b. Is the system in a safe state? c. If a request from process P1 arrives for (0,4,2,0), can the request be granted immediately?
- In the banker’s algorithm, the fact that a state is unsafe does not necessarily imply that the system will deadlock. Explain why this is true.
- Why did demand fetching endure as the conventional wisdom for so long? Why are anticipatory fetch strategies receiving so much more attention today than they did decades ago?
- As a systems programmer in a large computer installation using a fixed-partition multiprogramming system, you have the task of determining if the current partitioning of the system should be altered. a. What information would you need to help you make your decision? b. If you had this information readily available, how would you determine the ideal partitioning? c. What are the consequences of repartitioning such a system?
- A variable-partition multiprogramming system uses a free memory list to track available memory. The current list contains entries of 150KB, 360KB, 400KB, 625KB, and 200KB. The system receives requests for 215KB, 171KB, 86KB, and 481KB, in that order. Describe the final contents of the free memory list if the system used each of the following memory placement strategies. a. best-fit b. first-fit
- On one of the problems, you must use Java version 1.6 and a monitor.
- On one of the problems, you must use pthreads and a monitor on cygwin/Windows (C or C++). These can be tricky problems, so you must be able to explain your work to each other so that both team members can contribute to the design and debug.
Problem Statement #1 (“Emmet Street Rope Bridge”): President Casteen is considering adding a rope bridge across Emmet Street to give students another option for moving between parts of the campus. The rope can hold up to 7 people at one time. Furthermore, all people on the bridge must be moving in the same direction. Design a simulation (one thread per person), such that once a person begins crossing the bridge is guaranteed to make it across. Furthermore, a continuous stream of students crossing in one direction should not “starve” the people attempting to cross in the other direction. (President Casteen will take your simulation and vary the arrival rate of students attempting to cross in each direction, and measure the effectiveness of the potential bridge).
Problem Statement #2 (“coolness”): Students in the dining hall invoke dine and then leave. After invoking dine and before invoking leave a student is considered “ready to leave”. The synchronization constraint that applies to students is that, in order to maintain the illusion of social suave, a student may never sit at a table alone. A student is considered to be sitting alone if everyone else who has invoked dine invokes leave before she has finished dine.
Problem Statement #3 ("Dorm Problem"): Given a set of dorm rooms, twice as many students to fill them, and a survey of interests by the students, find an assignment of pairs of roommates that minimizes the disharmony (measure of how divergent the interests of roommates are) between the total set of students.
Some information that you might find helpful :
- Write your solution down on paper in pseudo-code and convince yourself it works before implementing it.
- Think carefully about the number of condition variables you will use. There is a balance here: too many condition variables makes the analysis/debugging too difficult (and the code too complex); too few condition variables causes the same problems. In creating your design, it is often valuable to create a table of condition variables, noting what the condition variable is named, who waits for it, and who signals it (and how -- either signal or broadcast ). It is also sometimes valuable to think of your concurrent system as a collection of independent "agents" that are asynchronously transitioning from state to state.
- You cannot have any race conditions in your code. Another way of stating this is that I should be able to insert arbitrary "pauses" in your code and your code should still work.
- A goal is to achieve maximum potential concurrency.
- Remember that while semaphores maintain a count for you and accumulate signals (have history), condition variables do not, so you might use separate counters to keep track of state.
- In each procedure in the monitor, always acquire the lock in the beginning and release at the end.
- As a general rule, the amount of time spent in the monitor should be minimized. In addition, no thread should busy-wait for any event to occur.
- If you're using C/C++, use getopt() to parse the commandline (see http://www.gnu.org/software/libc/manual/html_node/Getopt.html ).
- Use plenty of debugging statements in your code as you’re developing your code. Also, if you're using C/C++, consider using the "assert" operation in many places in your code ("man assert").
- You might want to create a separate thread called the "integrity checker" that continually checks the state of the system for errors.
- A great tutorial on Java threads can be found at: http://java.sun.com/docs/books/tutorial/essential/threads/. Note that in Java prior to version 1.5, a monitor in Java only had ONE condition variable. Java version 1. introduced separate condition variables
- A great tutorial for pthreads can be found at: http://www.llnl.gov/computing/tutorials/pthreads/
- As always, the most important aspect of your written document is to give the reader insight into the design of the code and the design of the tests.
Grading Policy for Part A of the Programming Assignment
Each program must be properly and reasonably designed, documented, implemented, and tested/evaluated. The grading for this part of the assignment will be:
- 75%: The quality of the code itself. This includes: the readability of the code, the correctness of the code, the efficiency of the code, etc. (Do not have debugging statements execute in the final version of your program).
- 25%: A separate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly. Discuss the design of the test cases and show direct output of test cases. This should be 1-3 pages (including figures).
What to hand in AND email
You must both hand-in your solutions to these questions at the beginning of class on Tuesday Nov 20 AND email an electronic copy of your solutions to [email protected] by 11:00am on Tuesday Nov 20. Make sure that both documents clearly contain your name. Each person should submit his/her answers to part 1 individually, and then a team should submit one solution for part 2.
