Concurrency, Deadlock, and Starvation in Reusable Resource Management
This chapter discusses the challenges of concurrent access to reusable resources and the issues of deadlock and starvation. We explore the types of resources that can cause these problems and their impact on system performance. While there is no efficient solution to deadlock, we provide strategies to detect and prevent it.
- Uploaded on | 1 Views
-
ninahaag
About Concurrency, Deadlock, and Starvation in Reusable Resource Management
PowerPoint presentation about 'Concurrency, Deadlock, and Starvation in Reusable Resource Management'. This presentation describes the topic on This chapter discusses the challenges of concurrent access to reusable resources and the issues of deadlock and starvation. We explore the types of resources that can cause these problems and their impact on system performance. While there is no efficient solution to deadlock, we provide strategies to detect and prevent it.. The key topics included in this slideshow are Concurrency, Deadlock, Starvation, Reusable Resources, System Performance,. Download this presentation absolutely free.
Presentation Transcript
1. Concurrency: Deadlock and Starvation Chapter 6
2. 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
6. 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
7. Example of Deadlock
8. 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 . . . . . . Request 80K bytes; Request 60K bytes; P2 . . . . . . Request 70K bytes; Request 80K bytes;
9. 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
10. Example of Deadlock Deadlock occurs if receive is blocking P1 . . . . . . Receive(P2); Send(P2, M1); P2 . . . . . . Receive(P1); Send(P1, M2);
11. 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
12. Conditions for Deadlock Circular wait A closed chain of processes exists such that each process holds resource needed by next
13. 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!!
14. 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.
15. 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
16. 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
17. 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
18. Resource Allocation Denial Referred to as the bankers 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
19. Determination of a Safe State Initial State
20. Determination of a Safe State P2 Runs to Completion
21. Determination of a Safe State P1 Runs to Completion
22. Determination of a Safe State P3 Runs to Completion
23. Determination of an Unsafe State
24. 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)
25. 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
