1 / 25

Concurrency: Deadlock and Starvation

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.

kaufman
Télécharger la présentation

Concurrency: Deadlock and Starvation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Concurrency: Deadlock and Starvation Chapter 6

  2. 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

  3. 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

  4. Example of Deadlock

  5. 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;

  6. 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

  7. Example of Deadlock • Deadlock occurs if receive is blocking P1 P2 . . . . . . Receive(P2); Receive(P1); . . . . . . Send(P2, M1); Send(P1, M2);

  8. 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

  9. Conditions for Deadlock • Circular wait • A closed chain of processes exists such that each process holds resource needed by next

  10. 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!!

  11. 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.

  12. 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

  13. 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

  14. 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

  15. 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

  16. Determination of a Safe StateInitial State

  17. Determination of a Safe StateP2 Runs to Completion

  18. Determination of a Safe StateP1 Runs to Completion

  19. Determination of a Safe StateP3 Runs to Completion

  20. Determination of an Unsafe State

  21. 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)

  22. 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

More Related