2. 1 CSE 513 Introduction to Operating Systems Class 4 - IPC & Synchronization (2) Deadlock Jonathan Walpole Dept. of Comp. Sci. and Eng. Oregon Health and Science University

3. 2 Counting semaphores  A binary semaphore can only take on the values of [0, 1].  Class exercise: create a counting semaphore (generalized semaphore that we discussed previously) using just a binary semaphore!!

4. 3 Administrivia  Assignments 0 & 1  Next week  midterm exam  project review & discussion (Chris Chambers)  Following week  Memory Management (Wuchi Feng)

5. 4 Possible solution Semaphore S1, S2, S3; // BINARY!! int C = N; // N is # locks down_c(sem){ downB(S3); downB(S1); C = C – 1; if (C<0) { upB(S1); downB(S2); } else { upB(S1); } upB(S3); } up_c(sem){ downB(S1); C = C + 1; if (C<=0) { upB(S2); } upB(S1); }

6. 5 Monitors  It is difficult to produce correct programs using semaphores  correct ordering of up and down is tricky!  avoiding deadlock is tricky!  boundary conditions are tricky!  Can we get the compiler to generate the correct semaphore code for us?  what are suitable higher level abstractions for synchronization?

7. 6 Monitors  Collect related shared objects together in a monitor  Characteristics  Local data variables are accessible only via the monitor’s procedures (encapsulation)  Processes enter the monitor by invoking one of its procedures  Only one process may execute within the monitor at a given time (mutual exclusion)  Condition variables (cv)  Wait(cv) – process blocked (queued) until condition holds  Signal(cv) – signals the condition and unblocks (dequeues) a process

8. 7 Monitor structures initialization code monitor operations y x shared data condition queues monitor entry queue

9. 8 Monitor example for mutual exclusion process Producer begin loop BoundedBuffer.deposit(c) end loop end Producer process Consumer begin loop BoundedBuffer.remove(c) end loop end Consumer monitor: BoundedBuffer var buffer :...; nextIn, nextOut :... ; entry deposit(c: char) begin... end entry remove(var c: char) begin... end end BoundedBuffer

10. 9 Monitor example with condition variables monitor : BoundedBuffer var buffer : array[0..n-1] of char nextIn,nextOut : 0..n-1 := 0 fullCount : 0..n := 0 notEmpty, notFull : condition entry deposit(c:char) entry remove(var c: char) begin begin if (fullCount = n) then if (fullCount = n) then wait(notFull) wait(notEmpty) end if end if buffer[nextIn] := c c := buffer[nextOut] nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n fullCount := fullCount+1 fullCount := fullCount-1 signal(notEmpty) signal(notFull) end deposit end remove end BoundedBuffer

11. 10 Monitor design choices  Condition variables introduce a problem for mutual exclusion  only one process active in the monitor at a time, so what to do when a process is unblocked on signal?  must not block holding the mutex, so what to do when a process blocks on wait?  Should signals be stored/remembered?  signals are not stored  if signal occurs before wait, signal is lost!  Should signals count?

12. 11 Monitor design choices  Choices when A signals a condition that unblocks B  A waits for B to exit the monitor or blocks again  B waits for A to exit the monitor or block  Signal causes A to immediately exit the monitor or block (on what condition?)  Choices when A signals a condition that unblocks B & C  B is unblocked, but C remains blocked  C is unblocked, but B remains blocked  Choices when A calls wait and blocks  a new external process is allowed to enter  but which one?

13. 12 Common monitor semantics  Hoare semantics  On signal, allow signaled process to run; upon its exit from the monitor, signaler process continues  Brinch Hansen semantics  signaler must immediately exit following signal

14. 13 Message Passing  Interprocess communication  via shared memory  across machine boundaries  Message passing can be used locally or remotely for synchronization or general communication  processes use send and receive primitives  receive can block like wait  send unblocks a process blocked on receive (like signal unblocking a waiting process)

15. 14 Producer consumer with message passing

16. 15 Design Choices for Message Passing  Mailboxes  system maintains a buffer of sent, but not yet received, messages  Rendezvous  sender and receiver must be active at the same time  receive must be blocked before send occurs  kernel does no buffering

17. 16 Barriers  Use of a barrier  processes approaching a barrier  all processes but one blocked at barrier  last process arrives, all are let through

18. 17 Deadlock

19. 18 Resources and Deadlocks  Processes need access to resources in order to make progress  Examples of computer resources  printers  tape drives  kernel data structures (process & file table entries …)  locks/semaphores to protect critical sections  Suppose a process holds resource A and requests resource B  at same time another process holds B and requests A  both are blocked and remain so … this is deadlock

20. 19 Resource Usage Model  Sequence of events required to use a resource  request the resource (like acquiring a mutex lock)  use the resource  release the resource (like releasing a mutex lock)  Must wait if request is denied  block  busy wait  fail with error code

21. 20 Preemptable vs Nonpreemptable Resources  Preemptable resources  can be taken away from a process with no ill effects  Nonpreemptable resources  will cause the process to fail if taken away  Deadlocks occur when processes are granted exclusive access to non-preemptable resources

22. 21 Definition of Deadlock A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause  Usually the event is the release of a currently held resource  None of the processes can …  be awakened  run  release resources

23. 22 Deadlock conditions  A deadlock situation can occur if and only if the following conditions hold simultaneously  Mutual exclusion condition – resource assigned to one process  Hold and wait condition – processes can get more than one resource  No preemption condition  Circular wait condition – chain of two or more processes (must be waiting for resource from next one in chain)

24. 23 Resource acquisition scenarios down (resource_1); use resource_1; up (resource_1); down (resource_1); down (resource_2); use both resources; up (resource_2); up (resource_1); down (resource_2); use resource_2; up (resource_2); down (resource_1); down (resource_2); use both resources; up (resource_2); up (resource_1);

25. 24 Resource acquisition scenarios down (resource_1); down (resource_2); use resources; up (resource_2); up (resource_1); down (resource_2); down (resource_1); use resources; up (resource_1); up (resource_2); down (resource_1); use resource; up (resource_1); down (resource_2); use resource; up (resource_2); down (resource_2); use resource; up (resource_2); down (resource_1); use resource; up (resource_1);

26. 25 Flavors of Deadlock  Not so bad  Programmer creates a situation that deadlocks  Kill the program and move on  Worse  Spin locks and locking mechanisms within the OS

27. 26 Other examples of deadlock

28. 27 Deadlock modeling  Resource Allocation Graphs (RAGs)  Resource R assigned to process A  Process B waiting for resource S  Process C and D are deadlocked over T & U

29. 28 Dealing with deadlock  Four general strategies  Ignore the problem Hmm… advantages, disadvantages?  Detection and recovery  Dynamic avoidance through resource allocation  Prevention, by structurally negating one of the four conditions

30. 29 Deadlock detection (1 resource of each)  Let the problem happen, then recover  How do you know it happened?  Do a depth-first-search on the resource allocation graph

31. 30 Deadlock detection (1 resource of each)  Let the problem happen, then recover  How do you know it happened?  Do a depth-first-search on the resource allocation graph

32. 31 Deadlock detection (1 resource of each)  Let the problem happen, then recover  How do you know it happened?  Do a depth-first-search on the resource allocation graph

33. 32 Deadlock detection (1 resource of each)  Let the problem happen, then recover  How do you know it happened?  Do a depth-first-search on the resource allocation graph

34. 33 Deadlock detection (1 resource of each)  Let the problem happen, then recover  How do you know it happened?  Do a depth-first-search on the resource allocation graph

35. 34 Deadlock modeling with multiple resources  Theorem: If a graph does not contain a cycle then no processes are deadlocked  A cycle in a RAG is a necessary condition for deadlock  Is the existence of a cycle a sufficient condition?

36. 35 Deadlock modeling with multiple resources  Theorem: If a graph does not contain a cycle then no processes are deadlocked  A cycle in a RAG is a necessary condition for deadlock  Is the existence of a cycle a sufficient condition?

37. 36 Deadlock detection (multiple resources)

38. 37 Deadlock detection (multiple resources) Available resource vector Total resource vector

39. 38 Deadlock detection (multiple resources) Available resource vector Total resource vector What I am requesting now What I have (now!)

40. 39 Detection algorithm  Is there a sequence of running process such that all the resources will be returned?

41. 40 Detection algorithm 1. Look for an unmarked process Pi, for which the ith row of R is less than or equal to A 2. If such a process is found, add the i-th row of C to A, mark the process and go back to step 1 3. If no such process exists the algorithm terminates If all marked, no deadlock

42. 41 Detection algorithm

43. 42 Detection algorithm

44. 43 Detection algorithm

45. 44 Detection algorithm 2 2 2 0

46. 45 Detection algorithm 2 2 2 0

47. 46 Detection algorithm 4 2 2 1 2 2 2 0

48. 47 Detection algorithm 4 2 2 1 2 2 2 0 No deadlock!

49. 48 Detection algorithms  How often should the algorithm run?  After every resource request? How many requests types are there?  Periodically?  When CPU utilization is low?  When we suspect deadlock?

50. 49 Recovery from deadlock  What should be done to recover?  Abort deadlocked processes and reclaim resources  Temporarily reclaim resource, if possible  Abort one process at a time until deadlock cycle is eliminated  Where to start? Low priority process How long process has been executing How many resources a process holds Batch or interactive Number of processes that must be terminated

51. 50 Other deadlock recovery techniques  Recovery through rollback  Save state periodically  Start computation again from “checkpoint”  Done for large computation systems

52. 51 Deadlock avoidance  Detection vs. avoidance…  Detection – “optimistic” approach Allocate resources “Break” system to fix it  Avoidance – “pessimistic” approach Don’t allocate resource if it may lead to deadlock  Which one to use depends upon the application

53. 52 Resource allocation plot ?

54. 53 Resource allocation graph

55. 54 Safe states  Safe state – “when system is not deadlocked and there is some scheduling order in which every process can run to completion even if all of them suddenly request their maximum number of resource immediately” 6 2 5 10 total 3

56. 55 Unsafe states 6 2 5 10 total 3 5 2 5 2 unsafe

57. 56 Banker’s algorithm for multiple resources  Look for a row, R, whose unmet resource needs are all smaller than or equal to A. If no such row exists, the system will eventually deadlock since no process can run to completion  Assume the process of the row chosen requests all the resources that it needs (which is guaranteed to be possible) and finishes. Mark that process as terminated and add all its resources to A vector  Repeat steps 1 and 2, until either all process are marked terminated, in which case the initial state was safe, or until deadlock occurs, in which case it was not

58. 57 Avoidance modeling Available resource vector Total resource vector Maximum Request Vector Row 2 is what process 2 might need RUN ALGORITHM ON EVERY RESOURCE REQUEST

59. 58 Avoidance algorithm Max request matrix

60. 59 Avoidance algorithm Max request matrix

61. 60 Avoidance algorithm Max request matrix

62. 61 Avoidance algorithm 2 2 2 0 Max request matrix

63. 62 Avoidance algorithm 2 2 2 0 Max request matrix

64. 63 Avoidance algorithm 4 2 2 1 2 2 2 0 Max request matrix

65. 64 Deadlock avoidance  Deadlock avoidance is usually impossible  because you don’t know in advance what resources a process will need!  Alternative approach “deadlock prevention”  Prevent the situation in which deadlock might occur for all time!  Attack one of the four conditions that are necessary for deadlock to be possible

66. 65 Attacking the conditions  Attacking mutual exclusion?  a bad idea for some resource types  may work for others  Attacking no preemption?  a bad idea for some resource types  may work for others

67. 66 Attacking the conditions  Attacking hold and wait  have processes request all resources before beginning –Underallocation of resources –Unknown requests  if new request, deallocate and reallocate!

68. 67 Attacking the conditions  Attacking circular wait  same problem/solution in the dining philosophers  number all resources and acquire in the same order  may be hard to get an ordering that everyone likes 1 2 3 4 5 6 7

69. 68 Attacking the conditions  Attacking circular wait  Same problem in the dining philosophers  Number all resources  Typically hard to get an ordering that everyone likes 1 2 3 4 5 6 7

70. 69 Attacking the conditions  Attacking circular wait  Same problem in the dining philosophers  Number all resources  Typically hard to get an ordering that everyone likes 1 2 3 4 5 6 7

71. 70 A word on starvation  Starvation and deadlock are two different things  With deadlock – no work is being accomplished for the processes that are deadlocked, because processes are waiting for each other  With starvation – work (progress) is getting done, however, a particular set of processes may not be getting any work done because they cannot obtain the resource they are trying to get

72. 71 Summary  What is deadlock?  Deadlock detection algorithms  Read  Chapter 3  Sample problems Chap 3: 15, 20, 21

73. 72 Spare slides Solution to sleeping barber problem.

74. 73 Deadlocks Chapter 3 3.1. Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance 3.6. Deadlock prevention 3.7. Other issues

75. 74 Deadlock Modeling (2)  Modeled with directed graphs  resource R assigned to process A  process B is requesting/waiting for resource S  process C and D are in deadlock over resources T and U

76. 75 Deadlock Modeling (3) Strategies for dealing with Deadlocks just ignore the problem altogether detection and recovery dynamic avoidance careful resource allocation prevention negating one of the four necessary conditions

77. 76 A B C How Deadlock Occurs

78. 77 How Deadlock Can be Avoided (o) (p) (q)

79. 78 The Ostrich Algorithm  Pretend there is no problem  Reasonable if  deadlocks occur very rarely  cost of prevention is high  UNIX and Windows takes this approach  It is a trade off between  convenience  correctness

80. 79 Detection with One Resource of Each Type  Note the resource ownership and requests  A cycle can be found within the graph, denoting deadlock

81. 80 Detection with One Resource of Each Type Data structures needed by deadlock detection algorithm

82. 81 Example Deadlock Detection Algorithm

83. 82 Recovery from Deadlock (1)  Recovery through preemption  take a resource from some other process  depends on nature of the resource  Recovery through rollback  checkpoint a process periodically  use this saved state  restart the process if it is found deadlocked

84. 83 Recovery from Deadlock (2)  Recovery through killing processes  crudest but simplest way to break a deadlock  kill one of the processes in the deadlock cycle  the other processes get its resources  choose process that can be rerun from the beginning

85. 84 Deadlock Avoidance Resource Trajectories Two process resource trajectories

86. 85 Safe and Unsafe States (1) Demonstration that the state in (a) is safe (a) (b) (c) (d) (e)

87. 86 Safe and Unsafe States (2) Demonstration that the sate in b is not safe (a) (b) (c) (d)

88. 87 The Banker's Algorithm for a Single Resource  Three resource allocation states  safe  unsafe (a) (b) (c)

89. 88 Banker's Algorithm for Multiple Resources Example of banker's algorithm with multiple resources

90. 89 Deadlock Prevention Attacking the Mutual Exclusion Condition  Some devices (such as printer) can be spooled  only the printer daemon uses printer resource  thus deadlock for printer eliminated  Not all devices can be spooled  Principle:  avoid assigning resource when not absolutely necessary  as few processes as possible actually claim the resource

91. 90 Attacking the Hold and Wait Condition  Require processes to request resources before starting  a process never has to wait for what it needs  Problems  may not know required resources at start of run  also ties up resources other processes could be using  Variation:  process must give up all resources  then request all immediately needed

92. 91 Attacking the No Preemption Condition  This is not a viable option  Consider a process given the printer  halfway through its job  now forcibly take away printer  !!??

93. 92 Attacking the Circular Wait Condition (1)  Normally ordered resources  A resource graph (a) (b)

94. 93 Attacking the Circular Wait Condition (1) Summary of approaches to deadlock prevention

95. 94 Other Issues Two-Phase Locking  Phase One  process tries to lock all records it needs, one at a time  if needed record found locked, start over  (no real work done in phase one)  If phase one succeeds, it starts second phase,  performing updates  releasing locks  Note similarity to requesting all resources at once  Algorithm works where programmer can arrange  program can be stopped, restarted

96. 95 Nonresource Deadlocks  Possible for two processes to deadlock  each is waiting for the other to do some task  Can happen with semaphores  each process required to do a down() on two semaphores (mutex and another)  if done in wrong order, deadlock results

97. 96 Starvation  Algorithm to allocate a resource  may be to give to shortest job first  Works great for multiple short jobs in a system  May cause long job to be postponed indefinitely  even though not blocked  Solution:  First-come, first-serve policy

98. 97 Spare Slides

99. 98 System calls  Three main parts  Providing hooks to “register” the system call  Adding the actual system call code  Compiling the kernel  Making it available to programs

100. 99 System calls: header files  /usr/src/linux/include/new_sys_call.h  /usr/src/linux/include/asm-i386/unistd.h  /usr/src/linux/include/arch/i386/kernel/entry.S #include _syscall0(int, new_sys_call);... #define __NR_sys_new_sys_call 243....long SYMBOL_NAME(sys_new_sys_call)...

101. 100 System calls: adding code  /usr/src/linux/kernel/new_sys_call.c  Modify Makefile to update with new files (if any).  Compile and install the kernel #include asmlinkage int sys_new_sys_call(void){ return(222); }

102. 101 System calls: creating a program  The most important thing is to have the header file around (as well as the new kernel). #include int main(){ printf(“return val %d\n”,new_sys_call()); }

103. 102 Monitors (3) Solution to producer-consumer problem in Java (part 1)

104. 103 Monitors (4) Solution to producer-consumer problem in Java (part 2)

105. 104 Semantics of monitors  What is the strongest statement we can make about the state of the monitor after a waiter wakes up? entry deposit(c:char) entry remove(var c: char) begin begin if (fullCount = n) then : : wait(notFull) c := buffer[nextOut] fullCount := fullCount-1 end if signal(notFull) : end deposit end remove

106. 105 Synchronization problems with Mesa P1 P2 P3 /* fullCount=n */ if (fullCount==n) wait(notFull); remove()... fullCount--; signal(notFull);... /* exit monitor */ /* fullCount=n-1*/ deposit()... fullCount++;... /* exit monitor */... fullCount++;

107. 106 Mesa semantics monitor : BoundedBuffer var buffer : array[0..n-1] of char nextIn,nextOut : 0..n-1 := 0 fullCount : 0..n := 0 notEmpty, notFull : condition entry deposit(c:char) entry remove(var c: char) begin begin while (fullCount = n) then while (fullCount = n) then wait(notFull) wait(notEmpty) end while end while buffer[nextIn] := c c := buffer[nextOut] nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n fullCount := fullCount+1 fullCount := fullCount-1 signal(notEmpty) signal(notFull) end deposit end remove end BoundedBuffer

108. 107 Another deadlock model  Model the state of the computer system as a directed graph G = (V,E)  V = set of vertices = {P 1,…,P n } u {R 1,…,R m }  E = set of edges = {edges from resource to process} u {edges from process to resource} PiPi RiRi RjRj Request edgeAllocation edge PiPi PkPk