1 / 43

Chapter 6 Concurrency: Deadlock and Starvation

Chapter 6 Concurrency: Deadlock and Starvation. Operating Systems: Internals and Design Principles. Operating Systems: Internals and Design Principles. “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.”

hubert
Télécharger la présentation

Chapter 6 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. Chapter 6Concurrency: Deadlock and Starvation Operating Systems:Internals and Design Principles Seventh Edition By William Stallings

  2. Operating Systems:Internals and Design Principles “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” Statute passed by the Kansas State Legislature, early in the 20th century. —A TREASURY OF RAILROAD FOLKLORE, B. A. Botkin and Alvin F. Harlow

  3. Deadlock • The permanent blocking of a set of processes that either compete for system resources or communicate with each other • A set of processes is deadlocked when each process in the set is blocked awaiting an event that can only be triggered by another blocked process in the set • Permanent • No efficient solution

  4. Potential Deadlock I need quad C and D I need quad B and C I need quad A and B I need quad D and A

  5. Actual Deadlock HALT until D is free HALT until C is free HALT until B is free HALT until A is free

  6. Deadlock - Unpredictable • In the previous example, the actual deadlock was not guaranteed to happen • For example, if one of the cars decides to stop rather than enter the intersection, then the other three cars could cross through with no problem. • Like race conditions, deadlock is a result of a particular sequence of execution steps that may occur infrequently or never

  7. Resource Categories Resources are fundamental to deadlock – competition to control them is the cause of the problem.

  8. Reusable Resources Example

  9. Example 2:Memory Request P1 P2 . . . . . . Request 70 Kbytes; Request 80 Kbytes; . . . . . . Request 80 Kbytes; Request60 Kbytes; Space is available for allocation of 200Kbytes, and the following sequence of events occur: Deadlock occurs if both processes progress to their second request Competition for memory and CPU could cause deadlock, but modern operating systems manage these resources so it doesn’t happen.

  10. Consumable Resources Deadlock Consider a pair of processes, in which each process attempts to receive a message from the other process and then send a message to the other process: Deadlock occurs if the Receive is blocking

  11. Deadlock Detection, Prevention, and Avoidance

  12. Resource Allocation Graphs

  13. Resource Allocation Graphs

  14. Conditions for Deadlock

  15. Dealing with Deadlock Three general approaches exist for dealing with deadlock:

  16. Deadlock Prevention Strategy • Design a system in such a way that the possibility of deadlock is excluded • Two main methods: • Indirect • prevent the occurrence of one of the three necessary conditions • Direct • prevent the occurrence of a circular wait

  17. Deadlock ConditionPrevention

  18. Deadlock Condition Prevention • No Preemption • if a process holding certain resources is denied a further request, that process must release its original resources and request them again • OS may preempt a lower priority process and require it to release its resources • Works for resources whose state can be saved, such as the CPU, but is not a good general solution

  19. Deadlock Condition Prevention • Circular Wait • define a linear ordering of resource types – assume they are numbered 1, 2, …, n • Require all processes to request their resources in order; for example: if process 1 already holds a resource from type 4, it may not request any resources from types 1, 2, or 3. • If this condition is enforced there can never be a circular wait, although a normal wait is possible.

  20. Deadlock Avoidance A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock Requires knowledge of future process requests

  21. Two Approaches to Deadlock Avoidance

  22. Resource Allocation Denial Referred to as the banker’s algorithm State of the system reflects the current allocation of resources to processes Safe state is one in which there is at least one sequence of resource allocations to processes that does not result in a deadlock Unsafe state is a state that is not safe

  23. Determination of a Safe State Amount of existing resources Resources available after allocation State of a system consisting of four processes and three resources Allocations have been made to the four processes. Is this a safe state?

  24. Yes:P2 Runs to Completion

  25. P1 Runs to Completion

  26. P3 Runs to Completion Thus, the state defined originally is a safe state

  27. Determination of an Unsafe State

  28. Deadlock Avoidance Logic

  29. Deadlock Avoidance Logic

  30. Deadlock Avoidance Advantages It is not necessary to preempt and rollback processes, as in deadlock detection It is less restrictive than deadlock prevention

  31. Deadlock Avoidance Restrictions Maximum resource requirement for each process must be stated in advance Processes under consideration must be independent and with no synchronization requirements There must be a fixed number of resources to allocate No process may exit while holding resources

  32. Deadlock Strategies

  33. Deadlock Detection, Prevention, and Avoidance

  34. Deadline Detection Algorithms • A check for deadlock can be made as frequently as each resource request or, less frequently, depending on how likely it is for a deadlock to occur. Tradeoffs involved in determining frequency • Advantages: • Frequent checks lead to early detection • The algorithm is simpler if it is done more often (there have been fewer changes to the pattern of resource allocation) • Disadvantage • frequent checks consume considerable processor time

  35. Deadlock Detection Algorithm

  36. Recovery Strategies Abort all deadlocked processes Back up each deadlocked process to some previously defined checkpoint and restart all processes Successively abort deadlocked processes until deadlock no longer exists Successively preempt resources until deadlock no longer exists

  37. Deadlock Approaches

  38. Dining Philosophers Problem • No two philosophers can use the same fork at the same time (mutual exclusion) • No philosopher must starve to death (avoid deadlock and starvation)

  39. Using Semaphores Solutions Cont.

  40. A Second Solution . . .

  41. Solution Using A Monitor

  42. DEADLOCK v STARVATION Deadlock is permanent: no way out unless some external process takes action Deadlock processes are holding resources that are being waited for by other deadlocked processes. Starvation is not necessarily permanent; the situation may correct itself A starving process is waiting for a resource that does not belong to a blocked process, it is in use by other processes. Starvation occurs when the wait for some resource is not structured so that when a process begins to wait for something no other process can get ahead of it.

  43. Summary • Deadlock: • the blocking of a set of processes that either compete for system resources or communicate with each other • blockage is permanent unless OS takes action • may involve reusable or consumable resources • Consumable = destroyed when acquired by a process • Reusable = not depleted/destroyed by use • Dealing with deadlock: • prevention – guarantees that deadlock will not occur • detection – OS checks for deadlock and takes action • avoidance – analyzes each new resource request

More Related