Course Overview Principles of Operating Systems

1. Introduction Computer System Structures Operating System Structures Processes ProcessSynchronization Deadlocks CPU Scheduling Memory Management Virtual Memory File Management Security Networking Distributed Systems Case Studies Conclusions Course OverviewPrinciples of Operating Systems

2. Motivation Objectives Deadlock Principles Starvation Deadlock Conditions Mutual Exclusion Hold and Wait No Preemption Circular Wait Dealing with Deadlock Deadlock Prevention Deadlock Avoidance Deadlock Detection and Recovery Deadlock and Operating Systems Important Concepts and Terms Chapter Summary Chapter Overview Deadlock and Starvation

3. Motivation • there is the potential of conflicts for processes who cooperate or share resources • deadlock and starvation are the most severe conflicts, leading to the permanent halting of the processes affected • common practice is not satisfactory • ad hoc solutions • neglecting the problem

4. Objectives • recognize potential problems with the coordination of activities for several processes (cooperation or resource sharing) • understand the necessary conditions for a formal deadlock situation • distinguish deadlocks from other reasons for “frozen” systems • analyze the status of a system based on resource allocation graphs • apply deadlock prevention, avoidance, and detection principles and algorithms to sets of processes

5. “Deadlocked” Systems • the term “deadlock” is often used casually to indicate that the computer system doesn’t respond (it is “frozen”) • there are other reasons for a system to be in such a state • endless loop • waiting for an event that may never occur • synchronization between processes • deadlock needs to be defined carefully to distinguish it from these other reasons

6. Deadlock Principles • permanent mutual blocking of a set of resources that either compete for resources or cooperate on a task • deadlocked processes don’t make any progress, and never finish their execution • deadlocked processes may tie up system resources

7. Starvation • a process can’t proceed because other processes always have the resources it needs • the request of the process is never satisfied • in principle, it is possible to get the resource, but doesn’t happen because of • low priority of the process • timing of resource requests • ill-designed resource allocation or scheduling algorithm • different from deadlock

8. Examples Starvation • batch processes with low priority in a heavily used time-sharing system • crossing a very busy road • trying to call a very popular phone number • NJIT modem pool • radio station giveaways • getting into a very popular course with limited enrollment

9. Solution Starvation • fairness: each process gets its fair share of all resources it requests • how is fair defined? • how is it enforced? • aging • the priority of a request is increased the longer the process waits for it

10. Resource Types • reusable resources • can be used repeatedly by different processes • does not imply simultaneous use • OS examples: CPU, main memory, I/O devices, data structures • consumable resources • are produced by one entity, and consumed by another • reuse is not possible, or impractical • OS examples: messages

11. Example Reusable Resources • main memory allocation • two processes make successive requests for main memory • the overall memory size is 16 MByte Process A request 5 MBytes; request 8 MBytes; Process B request 7 MBytes; request 7 MBytes; • deadlock • no process can proceed unless one gives up some memory (preemption) • frequent solutions: preallocation, virtual memory

12. Example Consumable Resources • message passing • two processes wait for a message from each other, and then send one to each other • receive operation is blocking (process can’t continue) Process A receive (B); send (B); Process B receive (A); send(A); • deadlock • no process can proceed because it is waiting for a message from the other • no easy solution

13. Deadlock on Resources • usually based on design or programming errors • these errors may be difficult or impossible to avoid • interaction between different modules • interaction between independent programs • very difficult to detect • may not occur during testing • may occur very infrequently in the field

14. Resource Allocation Graphs • processes • hold, request and release resources • resources • resource types specify a class of resources • individual instances are identical from the process’ perspective • resource assignment • an instance of a resource is currently held by a process • indicated by an assignment edge • resource request • a process wants to acquire another instance of a resource • indicated by a request edge

15. R1 P1 P2 P3 P4 P5 R1 Resource Allocation Graphs R2 R3 Assignment Edge Request Edge R4 R6 R5 R7

16. R1 P1 P2 R3 R1 Resource Allocation Graph with Cycle • there is at least one cycle in the graph • processes and resources involved • e.g. P1 -> R1 -> P2 -> R1, P1 -> R1 -> P2 -> R3 -> P1 • is there a deadlock? • no, we have enough resources to satisfy all requests R2

17. R1 P1 P2 R3 R1 Resource Allocation Graph with Deadlock • there must be at least one cycle in the graph • cycles are candidates for deadlock • is there a deadlock? • yes, there are not enough resources in R2 to satisfy all requests by P1 and P2 • processes and resources involved • P1 -> R2 -> P2 -> R2 R2

18. Cycles and Deadlocks • if there is a cycle in the resource allocation graph, there may be a deadlock • cycles without deadlock are possible • a deadlock can only occur if there is a cycle • no deadlock without a cycle

19. Safe States • a system is in a safe state if resources can be allocated to processes without getting into a deadlock • the order in which resources are allocated must be flexible • a sequence of processes is a safe sequence if the resources that a process may request are satisfiable by the currently available resources plus resources held by other processes • this must hold for all processes in the system • the process may have to wait until other processes are finished

20. Safe State Space • if a system is in a safe state there are no deadlocks • in an unsafe state, there is a possibility of deadlocks Deadlock unsafe safe

21. P0 R0 R4 P4 P1 R1 R3 P3 P2 R2 Dining Philosophers, Again var chopstick: array [0..4] of semaphore; repeat wait(chopstick[i]); wait(chopstick[i + 1 mod 5]); ... -- eat ... signal(chopstick[i]); signal(chopstick[i + 1 mod 5]); ... -- think ... until false;

22. Why Deadlock? • reasons for potential deadlock • mutual exclusion • two philosophers cannot use a chopstick simultaneously • use a protocol that prevents philosophers from • picking up their chopsticks simultaneously • picking up one chopstick if the other is not available • supervisor philosopher • an authority that can tell philosophers what to do • may use preemption of resources • seating arrangement • don’t seat philosophers around a round table • may require more n+1 chopsticks for n philosophers • several conditions must hold simultaneously

23. Conditions for Deadlock • all four conditions must hold simultaneously • mutual exclusion • hold and wait • no preemption • circular wait • the term deadlock is often used sloppily in situations that don’t constitute a formal deadlock as described above

24. Mutual Exclusion • only one process can hold a resource at one point • at least one resource may be used in a mutually exclusive way only • requests by other processes are delayed • usually determined by the needs of the resource, not under the control of the OS • examples: CPU, printer, write on files

25. Hold and Wait • one process holds a resource and waits to acquire other resources currently held by other processes • the processes doesn’t release its current resources • may be necessary, or a consequence of bad program design • examples: memory segments, I/O devices, chopsticks

26. No Preemption • a resource is released by a process only voluntarily • no intervention by the OS or other processes • examples: “cooperative multitasking” (MacOS)

27. Circular Wait • each process holds at least one resources needed by another process • the set of processes together with the request and hold links forms a cycle • there must be a set of processes P0, P1, ..., PN such that Pi is waiting on Pi+1 and PN is waiting on P0 • examples: dining philosophers, memory requests

28. Deadlock Examples • examples • studying students • traffic intersection • narrow tunnel • single-track railroad • airline reservation system • evaluation • four conditions: mutual exclusion, hold and wait, no preemption, circular wait

29. Student A get coursenotes get textbook study release textbook release coursenotes Student B get textbook get coursenotes study release coursenotes release textbook Studying Students • studying students: both students need the textbook and the course notes to study, but there is only one copy of each • consider the following situation:

30. Students Evaluation • mutual exclusion • books and course notes can be used only by one student • hold and wait • a student who has the book waits for the course notes, or vice versa • no preemption • there is no authority to take away book or course notes from a student • circular wait • student A waits for resources held by student B, who waits for resources held by A

31. Traffic Intersection • at a four-way intersection, four cars arrive simultaneously • if all proceed, they will be stuck in the middle

32. Traffic Evaluation • mutual exclusion • cars can’t pass each other in the intersection • hold and wait • vehicles proceed to the center, and wait for their path to be clear • no preemption • there is no authority to remove some vehicles • circular wait • vehicle 1 waits for vehicle 2 to move, which waits for 3, which waits for 4, which waits for 1

33. Narrow Tunnel • in a narrow tunnel, there is enough room for most vehicles to pass each other • if two large trucks arrive simultaneously, they won’t be able to pass each other

34. Tunnel Evaluation • mutual exclusion • trucks can’t pass each other in the tunnel • hold and wait • trucks occupy part of the tunnel and wait for their path to become clear • no preemption • there is no authority to remove the trucks • circular wait • truck 1 waits for truck 2 to move, which waits for 1

35. Single-Track Railroad • two trains arrive from different directions on a single-track section • railroad evaluation • mutual exclusion • trains can’t pass each other on the single track • hold and wait • trains occupy part of the track and wait for their path to become clear • no preemption • there is no authority to remove the trains • circular wait • train 1 waits for train 2 to move, which waits for 1

36. Airline Reservation System • two agents book flights in from EWR to FRA to MUC • agent A books flights EWR to FRA first • agent B books FRA to MUC first • flight records are locked during booking Agent A lock EWR-FRA lock FRA-MUC -- finalize booking release FRA-MUC release EWR-FRA Agent B lock FRA-MUC lock EWR-FRA -- finalize booking release EWR-FRA release FRA-MUC

37. Reservation Evaluation • mutual exclusion • flight records are locked • hold and wait • one agent locks one segment and waits for the other to become available • no preemption • there is no authority to remove the locks held by an agent • circular wait • agent A waits for agent B to unlock a segment, who waits for A

38. Dealing with Deadlocks • protocol • have strict rules that prevent a deadlock from occurring • recover • allow the system to enter a deadlock • there must be a way to recover from the deadlock situation • ignoring the deadlock • frequently used in operating systems • Windows, MacOS, Unix, ...

39. Dealing with Deadlocks • deadlock prevention • based on protocols • deadlock avoidance • check for safe state • deadlock detection and recovery • run into a deadlock, detect it, and recover

40. Deadlock Prevention • set of rules ensures that at least one of the four necessary conditions for deadlock doesn’t hold • mutual exclusion • hold and wait • no preemption • circular wait • may result in low resource utilization, reduced system throughput • example: traffic lights, no trucks in the narrow tunnel

41. Denying Mutual Exclusion • if all resources were sharable there would not be any deadlock • some resources can be made sharable • for example, spooling printer output • some resources are intrinsically non-sharable • e.g. CPU (at the instruction time scale)

42. Denying Hold And Wait • prevent processes that hold resources from waiting for more resources • processes request and are allocated all their resources before they start executing • low resource utilization rate • processes can request resources only if they have none • indefinite postponement

43. Denying No Preemption • means that processes may be preempted by the OS • should only done when necessary • resources of a process trying to acquire another unavailable resource may be preempted • preempt resources of processes waiting for additional resources, and give some to the requesting process • possible only for some types of resources • state must be easily restorable • e.g. CPU, memory • frequently used when applicable

44. Denying Circular Wait • break the cycle of waiting processes • impose a total ordering of all resource types • resources may only requested in increasing order of enumeration • no process can request a resource with a lower number than what it is already holding • ordering should take typical order of usage into account

45. Safe Philosophers • solution based on monitors • deadlock prevention is used by designing the program with certain restrictions • basic idea • a philosopher picks up a chopstick only if the other one is available as well • philosophers inform each other when they are done

46. Philosophers with Monitors type dining-philosophers = monitor var state: array [0..4] of (thinking, hungry, eating); var self: array [0..4] of condition; procedure entry pickup(i: 0..4); begin state[i] := hungry; test(i); if state[i] <> eating then self[i].wait; end; procedure entry putdown(i: 0..4); begin state[i] := thinking; test(i-1 mod 5); test(i+1 mod 5); end; [Silberschatz & Galvin, 1998]

47. Philosophers with Monitors (cont.) procedure test(k: 0..4); begin if (state[k-1] mod 5 <> eating and state[k] = hungry and state[k+1] mod 5 <> eating) then begin state[k] := eating; self[k].signal; end; end; begin for i := 0 to 4 do state[i] := thinking; end; [Silberschatz & Galvin, 1998]

48. Deadlock Avoidance • makes sure the system stays in a safe state if a request is satisfied • prevents circular waits • requires additional information at the beginning of the execution of a process • maximum number of instances per resource type for each process

49. Safe State • A system is in a safe state when given the current allocation the system is able to handle any number of requests, in some order, without getting into a deadlock.

50. BANK $10 A B C $5 $7 $3 Maximum Allocation Example • Bank gives loans to customers • maximum allocation = credit limit