1. 1 CSCI/CMPE 4334 Operating Systems Review: Exam 2

2. Review Chapters 7 ~ 10 in your textbook Lecture slides In-class exercises (on the course website) Review slides 2

3. Review 5 questions (100 points) + 1 bonus question (20 points) Question types – Q/A 3

4. Time & Place & Event 2:35pm ~ 3:50am, April 21, Tuesday ENGR 1.272 Closed-book exam 4

5. Process Manager 5 Program Process Abstract Computing Environment File Manager Memory Manager Device Manager Protection Deadlock Synchronization Process Description Process Description CPU Other H/W Scheduler Resource Manager Resource Manager Resource Manager Resource Manager Resource Manager Resource Manager Memory Devices Process Mgr

6. Chapter 7: Scheduling Thread scheduling – Ready, running, and blocked states – Context switching Mechanism to call scheduler – Voluntary call yield function – Involuntary call Interval timer Scheduling methods (see lecture slides and exercises) – First-come, first served (FCFS) – Shorter jobs first (SJF) or Shortest job next (SJN) – Higher priority jobs first – Job with the closest deadline first 6

7. Thread Scheduler Organization 7 Ready List Ready List Scheduler CPU Resource Manager Resource Manager Resources Preemption or voluntary yield AllocateRequest Done New Thread job “Ready” “Running” “Blocked”

8. Context Switching 8 CPU New Thread Descriptor Old Thread Descriptor

9. Process Model and Metrics  P will be a set of processes, p 0, p 1,..., p n-1  S(p i ) is the state of p i {running, ready, blocked}  τ(p i ), the service time  The amount of time p i needs to be in the running state before it is completed  W (p i ), the waiting time  The time p i spends in the ready state before its first transition to the running state  T TRnd (p i ), turnaround time  The amount of time between the moment p i first enters the ready state and the moment the process exits the running state for the last time 9

10. Everyday scheduling methods First-come, first served (FCFS) Shorter jobs first (SJF) – or Shortest job next (SJN) Higher priority jobs first Job with the closest deadline first 10

11. Invoking the Scheduler Need a mechanism to call the scheduler Voluntary call – Process blocks itself – Calls the scheduler – Non-preemptive scheduling Involuntary call – External force (interrupt) blocks the process – Calls the scheduler – Preemptive scheduling 11

12. Chapter 8: Basic Synchronization Critical sections – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section, called mutual exclusion Requirements for Critical-Section Solutions – Mutual Exclusion – Progress – Bounded Waiting 12

13. Chapter 8: Basic Synchronization (cont'd) Semaphore and its P() and V() functions – Definition – Usage Problems – Shared Account Balance Problem – Bounded Buffer Problem – Readers-Writers Problem – Sleepy Barber Problem – Dining-Philosophers Problem 13

14.  Structure of process P i repeat entry section critical section exit section remainder section until false ; 14

15. 15 shared double balance; Code for p 1 Code for p 2...... balance = balance + amount;balance = balance - amount;... balance+=amountbalance-=amount balance

16.  Mutual Exclusion.  If process P i is executing in its critical section, then no other processes can be executing in their critical sections.  Progress  If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely.  Bounded Waiting  A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted. 16

17.  Mutual Exclusion.  If process P i is executing in its critical section, then no other processes can be executing in their critical sections.  Progress  If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely.  Bounded Waiting  A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted. 17

18.  Disable interrupts  Software solution – locks  Transactions  FORK(), JOIN(), and QUIT() [Chapter 2]  Terminate processes with QUIT() to synchronize  Create processes whenever critical section is complete  … something new … 18

19.  A semaphore, s, is a nonnegative integer variable that can only be changed or tested by these two indivisible (atomic) functions: 19 V(s): [s = s + 1] P(s): [while(s == 0) {wait}; s = s - 1]

20. 20 Proc_0() {proc_1() { while(TRUE) { while(TRUE { <compute section>; P(mutex); P(mutex); <critical section>; V(mutex); V(mutex); }} semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

21. 21 Proc_0() {proc_1() {.../* Enter the CS */ P(mutex); P(mutex); balance += amount; balance -= amount; V(mutex); V(mutex);...} semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

22. 22 Producer Consumer Empty Pool Full Pool

23. 23 Readers Writers

24.  Barber can cut one person’s hair at a time  Other customers wait in a waiting room 24 Waiting Room Entrance to Waiting Room (sliding door) Entrance to Barber’s Room (sliding door) Shop Exit

25.  Shared data semaphore chopstick[5]; (=1 initially) 25 while(TRUE) { think(); eat(); }

26. Chapter 9: High-Level Synchronization Simultaneous semaphore  P simultaneous (S 1,...., S n ) Event – wait() – Signal() Monitor – What is condition? Its usage? – What are 3 functions of the condition? 26

27. Chapter 9: High-Level Synchronization (cont'd) – Examples Shared Balance Readers & Writers Synchronizing Traffic Dining Philosophers Interprocess Communication (IPC) 27

28.  As we have seen, relatively simple problems, such as the dining philosophers problem, can be very difficult to solve  Look for abstractions to simplify solutions  AND synchronization  Events  Monitors  … there are others... 28

29.  The orders of P operations on semaphores are critical  Otherwise deadlocks are possible  Simultaneous semaphores  P simultaneous (S 1,...., S n )  The process gets all the semaphores or none of them 29

30. 30 Dining Philosophers Problem philosopher(int i) { while(TRUE) { // Think // Eat P simultaneous (fork[i], fork [(i+1) mod 5]); eat(); V simultaneous (fork[i], fork [(i+1) mod 5]); } semaphore fork[5] = (1,1,1,1,1); fork(philosopher, 1, 0); fork(philosopher, 1, 1); fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher, 1, 4);

31.  Exact definition is specific to each OS  A process can wait on an event until another process signals the event  Have event descriptor (“event control block”)  Active approach  Multiple processes can wait on an event  Exactly one process is unblocked when a signal occurs  A signal with no waiting process is ignored  May have a queue function that returns number of processes waiting on the event 31

32.   Construct ensures that only one process can be active at a time in the monitor – no need to code the synchronization constraint explicitly  High-level synchronization construct that allows the safe sharing of an abstract data type among concurrent processes. class monitor { variable declarations semaphore mutex = 1; public P1 :(…) { P(mutex); V(mutex); };........ } 32

33.  To allow a process to wait within the monitor, a condition variable must be declared, as condition x, y;  Condition variable can only be used with the operations wait and signal.  The operation x.wait; means that the process invoking this operation is suspended until another process invokes x.signal ;  The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect. 33

34.  Essentially an event (as defined previously)  Occurs only inside a monitor  Operations to manipulate condition variable  wait : Suspend invoking process until another executes a signal  signal : Resume one process if any are suspended, otherwise do nothing  queue : Return TRUE if there is at least one process suspended on the condition variable 34

35. 35 Refined IPC Mechanism OS manages the mailbox space More secure message system Info to be shared Info to be shared Info copy Address Space for p 0 Address Space for p 1 Message Mailbox for p 1 send function receive function OS Interface send(… p 1, …);receive(…);

36. Chapter 10: Deadlock 4 necessary conditions of deadlock – Mutual exclusion – Hold and wait – No preemption – Circular wait How to deal with deadlock in OS – Prevention – Avoidance – Recovery 36

37. Chapter 10: Deadlock (cont'd) Prevention – Ensure that at least one of the necessary conditions is false at all times – How to? Hold and wait Circular Wait Avoidance – Safe state – Banker’s algorithm (see more examples in lecture slides) Safety algorithm to detect a safe sequence of process execution Resource-request algorithm to allocate more resources for a process Detection and recovery – Detection algorithm to detect deadlock Deadlock detection from graph – Reusable Resource Graphs (RRGs) – (CRGs) Consumable Resource Graphs 37

38.  Deadlock can arise if four conditions hold simultaneously  Mutual exclusion  Hold and wait:  No preemption  Circular wait 38

39.  Three ways  Prevention  place restrictions on resource requests to make deadlock impossible  Avoidance  plan ahead to avoid deadlock.  Recovery  Check for deadlock (periodically or sporadically) and recover from it  Manual intervention (the ad hoc approach)  Reboot the machine if it seems too slow 39

40.  Need to be sure a process does not hold one resource while requesting another  Approach 1: Force a process to request all resources it needs at one time  Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs 40

41.  Occurs when a set of n processes that hold units of a set of n different resources  Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration  Semaphore example  semaphores A and B, initialized to 1 P 0 P 1 wait (A);wait(A) wait (B);wait(B) 41

42.  Allow a process to time-out on a blocked request -- withdrawing the request if it fails  r = request resource  w = withdraw request  d = release or deallocate resource 42 SiSi ruru dvdv ruru SjSj SkSk wuwu No guarantee!

43.  Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state  Requires extra information, e.g., the maximum claim for each process  Allows resource manager to see the worst case that could happen, then to allow transitions based on that knowledge 43

44.  Best known of avoidance strategies  Modeled after lending policies used by banks  Each new process entering system declares the maximum use of resources it may need.  When a process requests a resource it may have to wait (until system in a safe state).  When a process gets all its resources it must return them in a finite amount of time. 44

45.  Available  Vector of length m. If available [j] = k, there are k instances of resource type R j available.  Max  n x m matrix. If Max [i,j] = k, then process P i may request at most k instances of resource type R j.  Allocation  n x m matrix. If Allocation[i,j] = k then P i is currently allocated k instances of R j.  Need  n x m matrix. If Need[i,j] = k, then P i may need k more instances of R j to complete its task.  Need [i,j] = Max[i,j] – Allocation [i,j] 45 Let n = number of processes, and m = number of resources types.

46. 1. Let Work and Finish be vectors of length m and n, respectively. Initialize: Work := Available Finish [ i ] = false for i - 1, 2, 3, …, n. 2.Find an i such that both: (a) Finish [ i ] = false (b) Need i  Work If no such i exists, go to step 4. 3. Work := Work + Allocation i Finish [ i ] := true go to step 2. 4.If Finish [ i ] = true for all i, then the system is in a safe state. 46

47. Request i = request vector for process P i. If Request i [ j ] = k then process P i wants k instances of resource type R j. 1.If Request i  Need i go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim. 2.If Request i  Available, go to step 3. Otherwise P i must wait, since resources are not available. 3.Pretend to allocate requested resources to P i by modifying the state as follows: Available := Available – Request i ; Allocation i := Allocation i + Request i ; Need i := Need i – Request i;;  If safe  the resources are allocated to P i.  If unsafe  P i must wait, and the old resource-allocation state is restored 47

48. 1. Let Work and Finish be vectors of length m and n, respectively Initialize: (a) Work := Available (b)For i = 1,2, …, n, if Allocation i  0, then Finish [i] := false;otherwise, Finish [i] := true. 2. Find an index i such that both: (a) Finish [ i ] = false (b) Request i  Work If no such i exists, go to step 4. 3. (a) Work := Work + Allocation i ; (b) Finish [ i ] := true; go to step 2. 4. If Finish [ i ] = false, for some i, 1  i  n, then the system is in deadlock state. Moreover, if Finish [ i ] = false, then P i is deadlocked. 48 Algorithm requires an order of m x n 2 operations to detect whether the system is in deadlocked state.

49. Good Luck! Q/A 49