Concurrency: Deadlock and Starvation

1. Concurrency: Deadlock and Starvation Fred Kuhns (fredk@arl.wustl.edu, http://www.arl.wustl.edu/~fredk) Department of Computer Science and Engineering Washington University in St. Louis

2. Introduction to deadlock • Typical scenario for a process P: • request exclusive access to some resource R • process P uses the resource • P then releases or returns the resource R to the system. • If two processes request R, one must block to ensure sequential access to R • “a set of processes is in a deadlock state when every process in the set is waiting for an event that can be caused only by another process in the set”, Silberschatz et. al., “Operating Systems Concepts” • There is no efficient solution Cs422 – Operating Systems Organization

3. Reusable Resources • Reusable resource: • Description: • Used by one process at a time and not depleted by that use • Processes obtain resources that they later release for reuse by other processes • Example: • Processor time, I/O channels, main and secondary memory, files, databases, and semaphores • Consumable resources • Description: • Created (produced) and destroyed (consumed) by a process • Examples: • Interrupts, signals, messages, and information in I/O buffers Cs422 – Operating Systems Organization

4. Bridge Crossing Example • Traffic only in one direction. • Each section of a bridge can be viewed as a resource. • Deadlock can occur if two cars enter the bridge from opposite sides • it can be resolved if one car backs up (preempt resources and rollback). • Several cars may have to be backed up if a deadlock occurs. • Starvation is possible • timid driver hesitates to enter bridge Cs422 – Operating Systems Organization

5. Consumable Resource Example • Deadlock occurs if receive is blocking P1 P2 . . . . . . Receive(P2); Receive(P1); . . . . . . Send(P2); Send(P1); Cs422 – Operating Systems Organization

6. Necessary Conditions for Deadlock • 1) Mutual exclusion: • One process holds a resource in a non-sharable mode. • Other processes requesting resource must wait for resource to be released. • 2) Hold-and-wait: • A process must hold at least one allocated resource while awaiting other resources held by other processes. • 3) No preemption: • Resources not forcibly removed from a process holding it, the holding process must voluntarily released it. • 4) Circular wait • a closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain. Cs422 – Operating Systems Organization

7. System Model - Reusable Resources • Resource types R1, R2, . . ., Rm CPU cycles, memory space, I/O devices • Each resource type Ri has Wi instances. • At any given time the system has N processes, designated by Pi • Each process utilizes a resource as follows: • request – block if resource is not available • use – process “owns” resource, but may elect to share with other processes • release – may result in a blocked processes being woken up Cs422 – Operating Systems Organization

8. Resource-Allocation Graph • A set of Vertices V and a set of Edges E • V is partitioned into: • P = {P1, P2, …, Pn}, all processes in the system. • R = {R1, R2, …, Rm}, all resource types in the system. • Request edge – directed edge Pi  Rj. Indicates Pi is waiting for an instance of resource type Rj • Assignment edge– directed edge Rj Pi. Indicates that and instance of resource type Rj has been allocated to Pi. Cs422 – Operating Systems Organization

9. Pi Rj R1 R2 Pi Rj P1 P2 Resource-Allocation Graph • Process Pi • Resource Type Rj with 4 instances • Pirequests instance of Rj • Pi is holding an instance of Rj • Deadlock P Cs422 – Operating Systems Organization

10. R1 R1 R2 R2 P1 P1 P2 P2 P3 P3 R3 R3 R4 R4 Example of a Resource Allocation Graph R1 R2 P1 P2 P3 R3 R4 P3 requests R3 (Deadlock) Initial: No Deadlock P2 releases R1, P3 requests R3 (No Deadlock: Why not?) Cs422 – Operating Systems Organization

11. Basic Facts • If graph contains no cycles  • no deadlock. • If graph contains a cycle  • if only one instance per resource type, then deadlock. • if several instances per resource type, possibility of deadlock. Cs422 – Operating Systems Organization

12. Approaches to Deadlock Handling • Ensure system never enters a deadlocked state: Use protocol to prevent or avoid deadlock: • deadlock prevention scheme - ensure that at least one of the necessary conditions cannot hold. • deadlock avoidance scheme - requires the OS know in advance the resource usage requirements of all processes. Then for each request the OS decides if it could lead to a deadlock before granting. • Allow the system to enter a deadlock state and then recover (detection and recovery). • system implements an algorithm for deadlock detection, if so then recover • Assume deadlocks never occur in the system • used by most operating systems, including UNIX. Cs422 – Operating Systems Organization

13. Deadlock Prevention • At least 1 necessary conditions does not hold • Mutual Exclusion: not required for sharable resources; must hold for non-sharable resources. • Hold-and-Wait: can not request new when holding resources. • Protocol 1: request all resources before it begins execution • Protocol 2: request resources only when the process has none. • Low resource utilization; starvation possible. • No Preemption: preempt resources from processes • Protocol 1: If a request can not be satisfied then preempt all resources held and block • Protocol 2: Preempt only if resources are needed by another running process • Requires resource state to be easily restored • Circular Wait: Block any request that results in a cycle. • Impose a total ordering of all resource types, and require that each process requests resources in an increasing order Cs422 – Operating Systems Organization

14. More on Preventing Circular Wait • Define F such that F: R -> N (i.e. each resource type is assigned a unique integer. • Assume process holds resource Ri • Protocol 1: Request resource Rj iff F(Rj) > F(Ri). • Must request multiple instances of same type at same time • Protocol 2: Request resource Rj iff it has released all Ri such that F(Ri)  F(Rj). • Prove that there can not be a circular wait. Cs422 – Operating Systems Organization

15. Deadlock Avoidance • Requires that system have a priori information • Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. • The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition. • Resource-allocation state is defined by the • number of available resources • number of allocated resources, • maximum demands of the processes. Cs422 – Operating Systems Organization

16. Safe State • Safe State: System can allocate resources to existing processes in some order that prevents deadlock. i.e. there is a safe sequenceof all processes whose allocation requests can be satisfied. • Sequence <P1, P2, …, Pn> is safe if for each Pi, the resources that Pican still request can be satisfied by currently available resources + resources held by all the Pj, with j < I. • If Pi resource needs are not immediately available, then Pi can wait until all Pjhave finished. • When Pj is finished, Pi can obtain needed resources, execute, return allocated resources, and terminate. • When Pi terminates, Pi+1 can obtain its needed resources, and so on. Cs422 – Operating Systems Organization

17. Basic Facts • If a system is in safe state  • no deadlocks. • If a system is in unsafe state  • possibility of deadlock. • Avoidance  • ensure that a system will never enter an unsafe state. Cs422 – Operating Systems Organization

18. Resource-Allocation Graph Algorithm • Must have no more that one instance of each resource type. • Claim edgePi Rj indicates process Pjmay request resource Rj; represented by a dashed line. • Claim edge converts to request edge when a process requests a resource. • When a resource is released by a process, assignment edge reconverts to a claim edge. • Resources must be claimed a priori in the system. Cs422 – Operating Systems Organization

19. Resource-Allocation Graph:Deadlock Avoidance Resource Allocation graph P2 requests R2, Unsafe state (cycle) Cs422 – Operating Systems Organization

20. A11 A12 ... A1m M11 M12 ... M1m A21 A22 ... A2m M21 M22 ... M2m ... ... An1 An2 ... Anm Mn1 Mn2 ... Mnm N11 N12 ... N1m N21 N22 ... N2m ... Nn1 Nn2 ... Nnm n  1) Ri = Vi + Aki, for all i k=1 2) Mki Ri, for all k, i 3) Aki Mki, for all k, i Some Definitions Definitions Resource = R = (R1, R2, ..., Rm) Available = V = (V1, V2, ..., Vm) Relationships Max = M = Allocation = A = Need = N = Max - Allocation = • If X and Y are vectors then X < Y iff X[i] < Y[i] for all i • Row i of a matrix corresponds to process Pi. So Mi is the set of maximum allocations for process i. Cs422 – Operating Systems Organization

21. n  Mki Ri M(n+1)i + for all i k=1 Deadlock Avoidance Policies • Deadlock Avoidance Policy – Process Initiation Denial • Start if the max claim of all process can be met (including new process) • Start a new process Pn+1 only if the below inequality holds • Resource Allocation Denial: Banker’s Algorithm • Each process must a priori claim maximum use (claims) which may not exceed the total number of resources • When a process requests a resource it may have to wait. • When a process gets all its resources it must return them in a finite amount of time. Cs422 – Operating Systems Organization

22. Safety Algorithm • Let Workand Finish be vectors of lengthm andn, respectively. Initialize: • Work = Available • Finish [i] = false for i - 1,3, …, n. • Find an i (that is, a Pi) such that both: • Finish [i] == false // Pi has not completed • Needi Work// Pi can allocate remaining Resources • If no such i exists, go to step 4. • Set Work = Work + Allocationi • Set Finish[i] = True • go to step 2. • If Finish [i] == True for all i, then the system is in a safe state. Otherwise it is unsafe. Cs422 – Operating Systems Organization

23. Resource-Request Algorithm for Pi If Requesti [j] = k,then process Piwants k instances of resource type Rj. • If Requesti Needi,, then go to step 2. Otherwise, raise error condition, (exceeded claim). • If Requesti Available, then go to step 3. Otherwise Pimust wait, resources not available. • Pretend to allocate requested resources to Pi: Available = Available - Requesti; Allocationi = Allocationi + Requesti; Needi = Needi – Requesti; • If safe  the resources are allocated to Pi. • If unsafe  Pi must wait, and the old resource-allocation state is restored Cs422 – Operating Systems Organization

24. Example of Banker’s Algorithm • 5 processes P0 through P4;3 resource types A (10), B (5), and C (7). • Snapshot at time T0: AllocMaxAvailNeed A B C A B C A B C A B C P0 0 1 0 7 5 3 3 3 2 7 4 3 P1 2 0 0 3 2 2 1 2 2 P2 3 0 2 9 0 2 6 0 0 P3 2 1 1 2 2 2 0 1 1 P4 0 0 2 4 3 3 4 3 1 • Is the system in a safe state? Cs422 – Operating Systems Organization

25. Example (Cont.) • The system is in a safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria. Cs422 – Operating Systems Organization

26. Example P1 Request (1,0,2) • Check that Request  Available • (that is, (1,0,2)  (3,3,2)  true: Request[i]  Avail[i]) AllocMaxAvailNeed A B C A B C A B C A B C P0 0 1 0 7 5 3 3 3 2 7 4 3 P1 2 0 0 3 2 2 1 2 2 P2 3 0 2 9 0 2 6 0 0 P3 2 1 1 2 2 2 0 1 1 P4 0 0 2 4 3 3 4 3 1 • Executing safety algorithm shows that sequence <P1, P3, P4, P0, P2> satisfies safety requirement. • Can request for (3,3,0) by P4 be granted? • Can request for (0,2,0) by P0 be granted? Request1 (1,0,2) Alloc1 (3,0,2) Need1 (0,2,0) Avail (2,3,0) Cs422 – Operating Systems Organization