250 likes | 277 Views
Concurrency: Deadlock and Starvation. Chapter 6. Deadlock. Permanent blocking of a set of processes that either compete for system resources or communicate with each other No efficient solution Involve conflicting needs for resources by two or more processes. Reusable Resources.
E N D
Concurrency: Deadlock and Starvation Chapter 6
Deadlock • Permanentblocking of a set of processes that either compete for system resources or communicate with each other • No efficient solution • Involve conflicting needs for resources by two or more processes
Reusable Resources • 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 • Processors, I/O channels, main and secondary memory, files, databases, and semaphores • Deadlock occurs if each process holds one resource and requests the other
Another Example of Deadlock • Space is available for allocation of 200K bytes, and the following sequence of events occur • Deadlock occurs if both processes progress to their second request P1 P2 . . . . . . Request 80K bytes; Request 70K bytes; . . . . . . Request 60K bytes; Request 80K bytes;
Consumable Resources • Created (produced) and destroyed (consumed) by a process • Interrupts, signals, messages, and information in I/O buffers • Deadlock may occur if Receive message is a blocking call • May take a rare combination of events to cause deadlock
Example of Deadlock • Deadlock occurs if receive is blocking P1 P2 . . . . . . Receive(P2); Receive(P1); . . . . . . Send(P2, M1); Send(P1, M2);
Conditions for Deadlock • Mutual exclusion • Only one process may use a resource at a time • Hold-and-wait • A process holds one resource while requesting another resource • No Preemption • No resource may be removed from a process by force
Conditions for Deadlock • Circular wait • A closed chain of processes exists such that each process holds resource needed by next
All Conditions • First three conditions lead to the fourth condition • All four conditions are necessary and sufficient for a deadlock to occur • Design the system to exclude the possibility of a deadlock!!
Deadlock Prevention • Indirect method calls for preventing the occurrence of first 3 conditions • Direct method calls for preventing the fourth condition • Mutual Exclusion is unavoidable • Hold and wait can be eliminated by forcing the processes to request all resources at the same time (impractical) • If a process is denied a requested resource, it should release the resource currently held • Define linear ordering of resource types so a process can only request next resource in the linear order.
Deadlock Avoidance • Prevention results in inefficient use of resources • We can use deadlock avoidance in which first three conditions still hold • A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock • Requires knowledge of future process request
Two Approaches to Deadlock Avoidance • Do not start a process if its demands might lead to deadlock • Do not grant an incremental resource request to a process if this allocation might lead to deadlock
Process Initiation Denial • A process declares all its resource requests in advance • A process can only be started if maximum requirements of all current processes plus its own requirements can be met • It is a worst case strategy because it assumes the worst (all required resources will be needed at the same time) so it is an inefficient approach
Resource Allocation Denial • Referred to as the banker’s algorithm • State of the system is the current allocation of resources to process • Safe state is where there is at least one sequence that does not result in deadlock • Unsafe state is a state that is not safe
Determination of an Unsafe State (Not Necessarily a Deadlocked State) P1 requests one unit each of R2 and R3; results in an unsafe state if granted (R1 request still unfulfilled for P1,P2,P3,P4)
Deadlock Avoidance Conditions • Maximum resource requirement must be stated in advance • Processes under consideration must be independent; no synchronization requirements • There must be a fixed number of resources to allocate • No process may exit while holding resources