Download Sample Midterm Exam 1 - Computer Design and Assembly Language Programming | CPE 229 and more Exams Electrical and Electronics Engineering in PDF only on Docsity!
University of California, Berkeley College of Engineering Computer Science Division ļ¾ EECS Fall 2009 John Kubiatowicz
Midterm I October 19th, 2009 CS162: Operating Systems and Systems Programming
Your Name:
SID Number: Circle the letters of CS Login
First: a b c d e f g h I j k l m n o p q r s t u v w x y z Second: a b c d e f g h I j k l m n o p q r s t u v w x y z
Discussion Section:
General Information: This is a closed book exam. You are allowed 2 pages of notes (both sides). You may use a calculator. You have 3 hours to complete as much of the exam as possible. Make sure to read all of the questions first, as some of the questions are substantially more time consuming.
Write all of your answers directly on this paper. Make your answers as concise as possible. On programming questions, we will be looking for performance as well as correctness, so think through your answers carefully. If there is something about the questions that you believe is open to interpretation, please ask us about it!
Problem Possible Score
1 20
2 18
3 24
4 20
5 18
Total 100
[ This page left for ļ° ]
Problem 1f[2pts]: If the banker's algorithm finds that it's safe to allocate a resource to an existing thread, then all threads will eventually complete.
True / False
Explain:
Problem 1g[2pts]: The Nachos operating system uses Mesa-style condition variables for all synchronization.
True / False
Explain:
Problem 1h[2pts]: The lottery scheduler prevents CPU starvation by assigning at least one ticket to each scheduled thread.
True / False
Explain:
Problem 1i[2pts]: Multicore chips (i.e. processor chips with more than one CPU on them) are only here for the short term (next few years) until the transistor feature size reaches 10nm.
True / False
Explain:
Problem 1j[2pts]: Thread pools are a useful tool to help prevent the āSlashdotā effect from crashing Web servers.
True / False
Explain:
Problem 2: Synchronization [18 pts]
Problem 2a[3pts]: Consider a Hash table with the following interface:
- public class HashTable {
- public void Put(int Key, int Value) {}
- public int Get(int Key) {} // Return 0 if no previous Put() on Key
- public void Remove(int Key) {} // No-op if no previous Put() on Key
- }
Assume that Get() must return the valid Value for any Key that has been written by previous Put() methods. If a Put() method on a given Key is happening at the same time as a Get() method, then the Get() method may return an earlier Value. In our attempt to make the HashTable threadsafe (i.e. usable by multiple threads at the same time), we might decided to make all three methods āsynchronizedā methods (e.g. Java synchronized statements). Would this have negative performance implications? Explain carefully (fully justify your answer; if the answer is āyesā, explain why you think you could get better threadsafe performance. If the answer is ānoā, explain why this is the best threadsafe performance you could expect):
Problem 2b[2pts]: Explain the difference in behavior between Semaphore.V() and CondVar.signal() when no threads are waiting in the corresponding semaphore or condition variable:
Problem 2c[3pts]: Explain how Nachos is able to implement the correct semantics for CondVar.signal() using Semaphore.V(). Be explicit and make sure to explain why the different of (2b) is not an issue here.
Problem 2d[2pts]: Give two reasons why this is a bad implementation for a lock:
lock.acquire() { disable interrupts; } lock.release() { enable interrupts; }
[ This page intentionally left blank ]
Problem 3: Deadlock and the Cephalopod Banquet [24pts]
Problem 3a[4pts]: Name and explain the four conditions for deadlock :
Problem 3b[2pts]: Suppose that we utilize the Bankerās algorithm to determine whether or not to grant resource requests to threads. The job of the Bankerās algorithm is to keep the system in a āSAFEā state. It denies resource requests by putting the requesting thread to sleep if granting the request would cause the system to enter an āUNSAFEā state, waking it only when the request could be granted safely. What is a SAFE state?
Problem 3c[3pts]: Explain how the Bankerās algorithm prevents deadlock by removing one or more of the conditions of deadlock from (3a). Be explicit.
The Cephalopod Diners Problem: Consider a large table with identical multi-even-armed cephalopods (e.g. octopuses). In the center is a pile of forks and knives. Before eating, each diner must have an equal number of forks and knives, one in each arm (e.g. if octopuses are eating, they would each need four forks and four knives). The creatures are so busy talking that they can only grab one utensil at a time. They also grab utensils in a random order until they have enough utensils to eat. After they finish eating, they return all of their utensils at once. Diners are implemented as threads that ask for utensils and return them when finished. Consider the following sketch for a CephTable class to implement the Cephalopod Diners problem using monitor synchronization:
- class DinerUtensils {
- public int forks,knives; // utensils held by creature
- } // clearly forks+Knives <= NumArms
- public class CephTable {
- Lock lock = new Lock(); // acquire(), release()
- CondVar CV = new CondVar(lock);//wait(),signal(),broadcast();
- public DinerUtensil[] Diners; // Accounting: utensils for each diner
- int NumArms; // Number of arms for every diner
- int IdleForks, IdleKnives; // Number of forks/knives on table
- public CephTable(int NumDiners, int NumArms, int Forks, int Knives){
- Diners = new DinerUtensils[NumDiners]; // info about each Diner
- This.NumArms = NumArms; // Number of arms per Diner
- This.IdleForks = Forks; // Number Forks on table initially
- This.IdleKnives = Knives; // Number Knives on table initially
- }
- public void GrabUtensil(int CephalopodID, boolean WantFork) {
- /* Try to grab a utensil from table */
- }
- public void DoneEating(int CephalopodID) {
- /* Return all chopsticks to pile */
- lock.acquire();
- IdleForks += Diners[CephalopodID].forks;
- IdleKnives += Diners[CephalopodID].knives;
- Diners[CephalopodID].forks = 0;
- Diners[CephalopodID].knives = 0;
- CV.broadcast();
- lock.release();
- }
- boolean CephCheck(int CephalopodID, int numforks, int numknives) {
- /* See if ok to give dinner numforks forks and numknives knives. */
- }
- }
Problem 3e[3pts]: In its general form, the Bankerās algorithm makes a decision about whether or not to allow an allocation request by making multiple passes through the set of resource holders (threads). See, for instance, the fact that there are two loops in (3d) to determine safety. Explain why a Bankerās algorithm dedicated to the Cephalopod Diners problem, namely the CephCheck() routine, could operate with a single pass through the resources holders:
Problem 3f[4pts]: Implement the CephCheck method of the CephTable Object, namely fill in code for line 31 above. This method should implement the Bankerās algorithm: return true if the given Cephalopod can be granted ānumforksā forks and ānumknivesā knives without taking the system out of a SAFE state. Do not blindly implement the Bankerās algorithm: this method only needs to have the same external behavior as the Bankerās algorithm for this application. Note that this method is part of the CephTable Object and thus has access to local variables of that object. This code should not permanently alter the local variables of the CephTable Object (although it can do so temporarily). Do not worry about making this routing threadsafe; it will be called with a lock held. We will give full credit for a solution that takes a single pass through the diners, partial credit for a working solution, and no credit for a solution with more than 15 lines. Hint: it is easier to first check the requesting Cephalopod, then the rest.
Code for Line 31:
Problem 3g[4pts]: Implement the code for the GrabUtensil() routine, namely fill in code for line 18 above. Its behavior is that it should check to whether or not it is ok to grant the requested type of utensil to the caller and if not, sleep until it is ok. This code should call the CephCheck() routine as a subroutine and should be threadsafe namely, it should be able to deal with multiple threads accessing the state simultaneously. You should implement this routine as a monitor and assume Mesa scheduling. It is up to the Cephalopod to eat and subsequently call DoneEating(); you should not do that in GrabUtensil(). This routine can be written in 8 lines, but you can use up to 12:
Code for Line 18:
Problem 4: Virtual Memory [20 pts]
Consider a multi-level memory management scheme with the following format for virtual addresses: Virtual Page # (10 bits)
Virtual Page # (10 bits)
Offset (12 bits)
Virtual addresses are translated into physical addresses of the following form:
Physical Page # (20 bits)
Offset (12 bits)
Page table entries (PTE) are 32 bits in the following format, stored in big-endian form in memory (i.e. the MSB is first byte in memory):
Physical Page # (20 bits)
OS Defined (3 bits)
0 PageLargeDirty
AccessedNocache ThroughWriteUser Writeable Valid
Here, āValidā means that a translation is valid, āWriteableā means that the page is writeable, āUserā means that the page is accessible by the User (rather than only by the Kernel). Note: the phrase āpage tableā in the following questions means the multi-level data structure that maps virtual addresses to physical addresses.
Problem 4a[2pts]: How big is a page? Explain.
Problem 4b[2pts]: Suppose that we want an address space with one physical page at the top of the address space and one physical page at the bottom of the address space. How big would the page table be (in bytes)? Explain.
Problem 4c[2pts]: What is the maximum size of a page table (in bytes) for this scheme? Explain.
Problem 4d[2pts]: How big would each entry of a fully-associative TLB be for this management scheme? Explain.
Problem 4e[2pts]: Sketch the format of the page-table for the multi-level virtual memory management scheme of (4a). Illustrate the process of resolving an address as well as possible.
Problem 4f[10pts]: Assume the memory translation scheme from (4a). Use the Physical Memory table given on the next page to predict what will happen with the following load/store instructions. Assume that the base table pointer for the current user level process is 0x00200000.
Addresses are virtual. The return value for a load is an 8-bit data value or an error, while the return value for a store is either ā ok ā or an error. Possible errors are: invalid, read-only, kernel-only. Hint: Donāt forget that Hexidecimal digits contain 4 bits!
Instruction Result Instruction Result Load [0x00001047] 0x^
Store [0x02001345] Store [0x00C07665] ok^
Load [0xFF80078F] Store [0x00C005FF]
ERROR: read-only
Load [0xFFFFF005] Load [0x00003012]
Test-And-Set [0xFFFFF006]
Problem 5: Scheduling [18pts]
Problem 5a[2pts]: Give two ways in which to predict runtime in order to approximate SRTF:
Problem 5b[2pts]: What scheduling problem did the original Mars rover experience? What were the consequences of this problem?
Problem 5c[3pts]: Five jobs are waiting to be run. Their expected running times are 10, 8, 3, 1, and X. In what order should they be run to minimize average completion time? State the scheduling algorithm that should be used AND the order in which the jobs should be run. HINT: Your answer will explicitly depend on X.
Problem 5d[5pts]: Here is a table of processes and their associated arrival and running times.
Process ID Arrival Time CPU RunningTime Process 1 0 2 Process 2 1 6 Process 3 4 1 Process 4 7 4 Process 5 8 3
Show the scheduling order for these processes under 3 policies: First Come First Serve (FCFS), Shortest-Remaining-Time-First (SRTF), Round-Robin (RR) with timeslice quantum = 1. Assume that context switch overhead is 0 and that new RR processes are added to the head of the queue and new FCFS processes are added to the tail of the queue.
Time Slot FCFS SRTF RR 0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15
[Scratch Page: Do not put answers here!]
[Scratch Page: Do not put answers here!]
