11 Resource Management Deadlock and Starvation

Transcription

1 11 Resource Management Deadlock and Starvation Examples, Deadlock Conditions, Policies against Deadlocks Winter Term 2004/2005 Gerd Liefländer 2003 Universität Karlsruhe, System Architecture Group 1

2 Recommended Reading:! Bacon, J.: Operating Systems (11, 18)! Nehmer, J.: Grundlagen moderner BS (6, 7, 8)! Silberschatz, A.: Operating System Concepts (7)! Stallings, W.: Operating Systems, 6! Tanenbaum, A.: Modern Operating Systems (3) 2003 Universität Karlsruhe, System Architecture Group 2

3 Overview Roadmap for Today! Motivation! Introduction! Examples! Resource Management! Deadlock Conditions! Policies against Deadlocks 2003 Universität Karlsruhe, System Architecture Group 3

4 Overview First View on Deadlocks Continuous mutual blocking of a set of threads either competing for resources or interacting with each other (via synchronization, cooperation or communication) Conflicting requests by at least 2 threads Current research status: No satisfying solution in all cases Some standard OSes don t bother deadlocks at all (e.g. SUN s OS) arguing that deadlocks will occur scarcely 2003 Universität Karlsruhe, System Architecture Group 4

5 Traffic Deadlock Question: a simple rule to avoid the above situation? 2003 Universität Karlsruhe, System Architecture Group 5

6 Motivation Example of a Deadlock If cars arrive at same time no official protocol solving this problem Universität Karlsruhe, System Architecture Group 6

7 Motivation Another Example of a Deadlock? No, this is called a live lock Live locked threads may run forever in a spin lock (riving up the engine) or they may be in a blocked state. Both situations might lead to starvation (at least if fuel is out) Universität Karlsruhe, System Architecture Group 7

8 Examples Examples of Deadlocks: Nested CS semaphore s1 = 1, s2 = 1; Thread T1 { p(s1); /* outer CS */ p(s2); /* inner CS */ v(s2); v(s1); } Thread T2 { p(s2); /* outer CS */ p(s1); /* inner CS */ v(s1); v(s2); } Some authors claim: Nested CSs are severe design errors 2003 Universität Karlsruhe, System Architecture Group 8

9 Late Signaling, Circular Resource Allocation Examples Thread1 Thread2 Thread1 Thread2 Wait(S 1 ) Wait(S 2 ) Allocate(R 1 ) Allocate(R 2 ) Signal(S 2 ) Signal(S 1 ) Allocate(R 2 ) Allocate(R 1 ) This is a program error However, if thread 1 and thread 2 belong to different applications? Is this also a program error? Yes, this timing may lead to deadlock 2003 Universität Karlsruhe, System Architecture Group 9

10 Examples Examples of Deadlocks Thread1 Allocate(R 1 ) What will happen? Allocate(R 2 ) Thread2 Nevertheless, that program is incorrect because it can result in a deadlock. Allocate(R 2 ) Allocate(R 1 ) Is this also a program error? Can also run without a deadlock! Deadlock analysis always requires worst case scenario Universität Karlsruhe, System Architecture Group 10

11 Examples Another Deadlock due to Resource Allocation Assumption: System offers 10 memory frames Thread1 Thread2 Allocate(5) Allocate(5) Allocate(1) Allocate(1) Remark: Again, the system can result in an deadlock, but does not necessary run into a deadlock 2003 Universität Karlsruhe, System Architecture Group 11

12 Examples Some Comments on Deadlocks! In addition, deadlock is not possible between two threads in a process, because it is the process that holds resources, not the thread that is, each thread has access to the resources held by the process. ( Rashid Bin Muhammad )! Crises and deadlocks when they occur have at least this advantage, that they force us to think. - Jawaharlal Nehru ( ) Indian political leader! 2003 Universität Karlsruhe, System Architecture Group 12

13 Resource Management Resource Management (1) Resource manager is a monitor with interface operations: 1. allocate(r: resource) and release(r: resource) if resource is exclusive as one non-sharable unit (~can be allocated to 1 thread, only, e.g. a printer) Remark: There are analogies between resource management and critical sections (especially exclusive resources) 2003 Universität Karlsruhe, System Architecture Group 13

14 Resource Management Resource Management (2) 2. allocate(r:resource, p:integer, a: address) release(r:resource, p:integer, a:address) if the resource can be allocated piece by piece, e.g. frames of main memory, p specifies the number of contiguous frames etc., a specifies the address of the first entity Universität Karlsruhe, System Architecture Group 14

15 Resource Management Resource Management enter_section exit_section allocate release Data structures for resource management 2003 Universität Karlsruhe, System Architecture Group 15

16 Resource Management Resources Types! Logical Resources! Buffer! Container! File! Directory!...! Physical Resources! Memory (Cache, Main, Disk, )! Network! Printer! Display! Keyboard! Universität Karlsruhe, System Architecture Group 16

17 Resource Management Utilization Protocol (1) allocate use use use use release time Remark: Utilization of an exclusive resource ~ handling of a CS i.e. Allocate ~ EnterCriticalSection and Release ~ LeaveCriticalSection 2003 Universität Karlsruhe, System Architecture Group 17

18 Resource Management Utilization Protocol (2) allocate use use use use release thread T1 allocate T1 may hand over the resource to T2 thread T2 T2 has to wait until T1 releases the resource 2003 Universität Karlsruhe, System Architecture Group 18

19 Resource Management Resources (1)! Deadlocks may occur when! processes are granted exclusive access to devices! we refer to these devices generally as 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 2003 Universität Karlsruhe, System Architecture Group 19

20 Resource Management Resources (2)! Sequence of events required to use a resource 1. request the resource 2. use the resource 3. release the resource! Must wait if request is denied! requesting process may be blocked! may fail with error code 2003 Universität Karlsruhe, System Architecture Group 20

21 Deadlock Notions Formal Definition Formal Definition: A set of processes(klts) is deadlocked if each process(klt) in the set is waiting for an event that only another process(klt) in this set can cause! Usually the event processes are waiting for- is a release notification of a currently held resource or a v(semaphore) operation ending a critical section or????! None of the processes can! run! release resources or critical sections! be awakened (Why???) 2003 Universität Karlsruhe, System Architecture Group 21

22 Deadlock Notions Necessary Conditions for a Resource Deadlock 1. Exclusiveness No Sharing at all! a resource is either assigned to 1 process or is available 2. Hold and Wait Allocating/releasing occur at random! process holding resources can request additional resources 3. No Preemption from exclusive resources! previously granted resources cannot forcibly taken away 4. Circular Wait Circular dependency! must be a circular chain of at least 2 or more processes! each waiting for resource held by next member of chain Note: These are not sufficient conditions 2003 Universität Karlsruhe, System Architecture Group 22

23 Deadlock Notions Exclusiveness At least one resource must be held in a non-sharable mode, i.e. only a single thread (task) at a time can use this resource. If another thread (task) requests that resource, the requesting thread (task) must be delayed (e.g. blocked) until that resource is released Universität Karlsruhe, System Architecture Group 23

24 Deadlock Notions Hold and Wait There must exist a thread (task), that is holding at least one resource and that is waiting to acquire additional resources that are currently held by other threads (tasks) 2003 Universität Karlsruhe, System Architecture Group 24

25 Deadlock Notions No Preemption Resources cannot be preempted; a resource can be released only voluntarily by the thread (task) currently holding it Universität Karlsruhe, System Architecture Group 25

26 Deadlock Notions Circular Wait There must exist a closed chain of threads (tasks) {T 1,T 2, T k }, such that each thread T i holds at least one exclusive resource needed by T i+1, the next thread in this chain! 2003 Universität Karlsruhe, System Architecture Group 26

27 Deadlock Notions Resource Allocation Graph * Type R1 P holds R1 P P requests for one of the two objects of R2 Type R2 Remark: RAG = mean to illustrate deadlocks respectively situations without a deadlock * Peterson, Silberschatz 2003 Universität Karlsruhe, System Architecture Group 27

28 Deadlock Notions Circular Wait Condition R1 P1 requests R1 P2 holds R1 P1 P1 holds R2 P2 P2 requests R2 R2 The circular wait condition is sufficient for the existence of a deadlock iff only one object per resource type (one exemplar systems) 2003 Universität Karlsruhe, System Architecture Group 28

29 Deadlock Notions Specific Situations P R3 R1 Q R2 Question: Can a deadlock occur due to requests of threads P or Q? 2003 Universität Karlsruhe, System Architecture Group 29

30 Deadlock Notions Specific Situations P R3 R1 R2 Q P R3 Yes, if R2 is given to P, then an unsolvable circular wait exists. R1 Q R Universität Karlsruhe, System Architecture Group 30

31 Deadlock Notions Specific Situations R1 P Q R3 2xR2 T a deadlock due to circle in resource allocation graph? (Type R2 has 2 objects. One used by P, one by T) Not necessarily, you can run T, then Q, and finally P Universität Karlsruhe, System Architecture Group 31

32 Deadlock Notions Conditions for Deadlock 1. Exclusiveness 2. Hold and Wait Due to allocation policy 3. No Preemption 4. Circular Wait Snapshot of system behavior 2003 Universität Karlsruhe, System Architecture Group 32

33 Managing Deadlocks Managing Deadlocks! Prevention! Preventing deadlocks by constraining how requests for resources can be made in the system and how they are handled (system design)! Eliminate one of the four necessary deadlock conditions! Avoidance! System dynamically considers every request and decides whether it is safe to grant it at that time! Maximum requirements of each resource must be stated in advance by each process! Detection and Recovery! Ignoring 2003 Universität Karlsruhe, System Architecture Group 33

34 Deadlock Prevention Deadlock Prevention (1) Construct a system: deadlocks may never arise, i.e. ensure that at least one of the necessary conditions for deadlock won t occur Attacking the mutual-exclusion condition! Some physical and logical resources require mutually-exclusion, e.g. keyboard, stack etc.! We have to admit mutual exclusion! However, some resource types like Universität Karlsruhe, System Architecture Group 34

35 Deadlock Prevention Spooling a Resource! Some devices (see printer) can be spooled! only the printer daemon uses printer resource! thus deadlocks for spooled printer eliminated! Other devices (see CPU) can be virtualized! multiplexing the CPU is an elegant method 2003 Universität Karlsruhe, System Architecture Group 35

36 Deadlock Prevention Deadlock Prevention (2)! Attacking the hold-and-wait condition! Requires that each thread requests all resources by one single and atomic request. Consequence: Thread has to wait until all requests can be granted simultaneously.! Disadvantages:! Thread has to wait unnecessarily long until all resources are available, even though it may not use all resources in the next run! Resources allocated to a thread may remain unused for a long period. They could be used be other threads in the meantime.! An application must be aware of all resources that it will need eventually.! Impossibilities: e.g. a resource ping-pong between threads 2003 Universität Karlsruhe, System Architecture Group 36

37 Deadlock Prevention Deadlock Prevention (3)! Attacking the no-preemption condition! Preemption: once a resource request is denied, the according thread should release all resources that it already holds! Alternatively you could preempt the current resource owner to release its resources.! States of the preempted resources have to be saved for later resumption. Only possible when the state of a resource can be easily saved and restored! Enables live locks, even system-wide live locks (see dining philosophers) 2003 Universität Karlsruhe, System Architecture Group 37

38 Deadlock Prevention (3) Virtualization or Multiplexing of resources! no-preemption is a very condition? successful technique to avoid! Preemption: once deadlock a resource request problems. is denied, the according Processor, thread should memory, release files,... all resources are that obvious it already candidates, holds e.g., VMWARE multiplexes! Alternatively even you display could preempt and network the current hardware. resource owner to release its resources.! States of the preempted resources have to be saved for later resumption. Only possible when the state of a resource can be easily saved and restored! Enables live locks, even system-wide live locks (see dining philosophers) Deadlock Prevention 2003 Universität Karlsruhe, System Architecture Group 38

39 Deadlock Prevention Preemptive Printer?! This is not a viable option! Consider a process given the printer! halfway through its job! now forcibly take away printer!!!?? Hint: Try to find a solution for preempting even a printer, even though Andy won t like it 2003 Universität Karlsruhe, System Architecture Group 39

40 Deadlock Prevention Deadlock Prevention (4)! no-circular-wait condition! Define a strictly increasing linear ordering OR(RT) for resource types, e.g.! R1: tape drives: OR(R1) = 2! R2: disk drives: OR(R2) = 4! R3: printers: OR(R3) = 7! A thread initially requests a number of instances of a resource type, say Ri! A single request must be issued to obtain several instances.! After that, this thread can request instances for resource types Rj if and only if OR(Rj)>OR(Ri) 2003 Universität Karlsruhe, System Architecture Group 40

41 Deadlock Prevention Summary: Deadlock Prevention In general, this principle is either far too restrictive (you may request resources in some predefined ordering, only) or the usage of the resources is far too low (allocating all resources at the start is quite wasteful) or too much overhead is involved (e.g. a preemption costs time and requires additional containers for saving and restoring the resource states) in many commercial system prevention is not used 2003 Universität Karlsruhe, System Architecture Group 41

42 Deadlock Prevention 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 2003 Universität Karlsruhe, System Architecture Group 42

43 Deadlock Prevention Non Resource 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 2003 Universität Karlsruhe, System Architecture Group 43

44 Deadlock Prevention 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 jobs to be postponed indefinitely! even though not blocked! Solution:! First-come, first-serve policy 2003 Universität Karlsruhe, System Architecture Group 44

45 Deadlock Avoidance Deadlock Avoidance (1) At runtime a decision is made whether a complete new thread or a new request of an active thread might lead to a deadlock 2 straightforward policies:! Do not start a new thread if its requests all together with those of the current active threads might lead to a deadlock! Do not grant an incremented request to a thread if its allocation might lead to a deadlock 2003 Universität Karlsruhe, System Architecture Group 45

46 Deadlock Avoidance Deadlock Avoidance (1) Some formal description of the system Given: n threads T 1, T 2, T n and m resource types R 1, R 2, R m R = (r 1, r 2, r m ) total amount of each resource V = (v 1, v 2, v m ) total amount of each resource currently not allocated to one of the n threads 2003 Universität Karlsruhe, System Architecture Group 46

47 Deadlock Avoidance Deadlock Avoidance (3) C = C C. C n1 C C. C n C C C 1m 2m. nm Maximal requirement per resource of each thread A = A A. A n1 A A. A n A A A 1m 2m. nm Currently allocated resources of each thread 2003 Universität Karlsruhe, System Architecture Group 47

48 Deadlock Avoidance Invariants and Constraints R i = V i + n Aki k = 1 for all i: All resources are either available or allocated C ki Ri, for all k, i : no thread claims more than the total amount of resources in the system A k,i, k, Ck, i for all i : no thread is allocated more resources than initially claimed 2003 Universität Karlsruhe, System Architecture Group 48

49 Deadlock Avoidance Deadlock Avoidance Algorithm (1) Start a new thread iff ( if and only if) R i C n + 1, i + n k = 1 C ki for all i Policy is far too pessimistic assuming that all threads will request all their claimed resources at the same time. In practice, however, the following often holds:! Some of the claimed resources are never requested! Few threads need all their claimed resources at the same time we need a better, i.e. more optimistic algorithm 2003 Universität Karlsruhe, System Architecture Group 49

50 Deadlock Avoidance progress of thread 2 Release R1 Release R2 Smart passage Allocate R1 Allocate R2 Allocate R1 Allocate R2 Release R1 Release R2 progress of thread Universität Karlsruhe, System Architecture Group 50

51 Release R1 progress of thread 2 Titanic crash Deadlock Avoidance Deadlock Region Release R2 Allocate R1 Allocate R2 Is this a region we should avoid? Allocate R1 Allocate R2 Release R1 Release R1 progress of thread Universität Karlsruhe, System Architecture Group 51

52 progress of thread 2 Deadlock Avoidance Entering an unsafe region potential deadlock Release R1 Release R2 Deadlock Allocate R1 Allocate R2 Unsafe Region Allocate R1 Allocate R2 Release R1 Release R1 progress of thread Universität Karlsruhe, System Architecture Group 52

53 Deadlock Avoidance progress of thread 2 Entering unsafe region no deadlock this time Release R1 Release R2 Allocate R1 Allocate R2 unsafe region Allocate R1 Release R1 Allocate R2 Release R1 progress of thread Universität Karlsruhe, System Architecture Group 53

54 Deadlock Avoidance Safe State Definition: The state of a system of n threads is safe if there is at least one execution sequence allowing that all n threads can complete. More formally: System state = safe permutation <T k1,t k2, T kn > within {T 1, T 2,,T n } : for all i {1,2, n}: or for all i {1,2, n}: C C k k i i A A k k i i V R i + = s n 1 1 s= i A A k k s s 2003 Universität Karlsruhe, System Architecture Group 54

55 Deadlock Avoidance Banker Algorithm type state = record R,V: array[0..m-1] of integer C,A: array[o,n-1,0 m-1]of integer T: {set of threads} end procedure deadlock_avoidance (var answer:state, DT:set of threads) { answer := undefined /* initialization */ DT := T /* all threads deadlocked */ while answer = undefined do if T[i] DT: C[i] - A[i] V then { DT := DT \ {T[i]} V := V + A[i] if DT = {} then answer := safe } else answer := unsafe /* n 1 thread deadlocked */ od } O(n 2 m) with n = # of threads and m = # of resource types 2003 Universität Karlsruhe, System Architecture Group 55

56 Deadlock Detection Deadlock Detection If neither prevention nor avoidance works, at least you want to detect deadlocks. The whole concept is a bit more optimistic. Algorithm: Replace in the Banker Algorithm the if condition as follows: if T[i] DT: CR[i] V then... Remark: CR[1..n,1..m] is the matrix of the current pending requests! If there is a deadlock, DT = { deadlocked threads } 2003 Universität Karlsruhe, System Architecture Group 56

57 Deadlock Detection Deadlock Detection with 1 Resource of Each Type (a) Note the resource ownership and requests (b) Cycle found within the graph deadlock 2003 Universität Karlsruhe, System Architecture Group 57

58 Deadlock Detection Usage of Detection Algorithm! When and how often to invoke?! In the extreme case every time a request for a resource cannot be granted immediately! This comes with enormous cost /think about complexity in real systems)! Reasonable alternative periodically. But what period to use?! How long are we willing to wait after it happens to be detected! How much system resources are we willing to commit to this detection algorithm 2003 Universität Karlsruhe, System Architecture Group 58

59 Deadlock Recovery Recovery from Deadlock What can a system do after it has detected a deadlock?! Process termination! Abort all deadlocked processes:! That s fast, but..! A lot of work has been wasted! Abort one deadlocked process at a time and check for deadlock again! More work to resolve a deadlock! Better in terms of process work! But in which order to abort the processes?! Resource preemption! What is a good way to select a victim to be aborted! How can we rollback and recover from preemption! How can we protect from starvation 2003 Universität Karlsruhe, System Architecture Group 59

60 Deadlock Recovery Deadlock Recovery (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 2003 Universität Karlsruhe, System Architecture Group 60

61 Deadlock Recovery Recovery (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 2003 Universität Karlsruhe, System Architecture Group 61

62 Deadlock Recovery Deadlock Recovery (3) What possibilities for killing processes?! Some criteria for aborting processes:! Size of pending request! Amount of allocated resources! Priority! Application-/system-process! Expected duration of abortion! Accumulated execution time! Expected remaining execution time!... If short, let it finish, if long, abort it 2003 Universität Karlsruhe, System Architecture Group 62

63 Ostrich Algorithm Ignoring Deadlocks Ostrich Algorithm :! Pretend there is no deadlock problem at all! Reasonable if! deadlocks occur very rarely! cost of prevention or avoidance is too high! UNIX and Windows takes this approach! It is a trade off between! convenience! correctness 2003 Universität Karlsruhe, System Architecture Group 63

64 Deadlock Management Combined Deadlock Policy We can combine some previous approaches in the following way: Group resources into a number of different classes and order them, e.g.: Swappable space (secondary memory) Task resources (I/O devices, files...) Main memory... Use prevention of circular wait to prevent deadlock between these resource classes Use the most appropriate approach against deadlocks within each class 2003 Universität Karlsruhe, System Architecture Group 64