Deadlock and Starvation
Deadlock Permanent blocking of a set of processes Processes are waiting on events, but the events can only be triggered by other blocked processes No simple, efficient solution 2
Bridge Crossing Example Traffic only in one direction. Each section of a bridge can be viewed as a resource. If a deadlock occurs, 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. 3
Can deadlock occur? Process P Get A Get B Release A Release B. Process Q Get B Get A Release B Release A.
Joint Progress Diagram (Fig.6.2) The occurrence of deadlock depends on both of the execution rates and the details of the application.
Can deadlock occur? Process P Get A Release A Get B Release B. Process Q Get B Get A Release B Release A.
Types of Resources Reusable vs. Consumable Preemptible vs Non-preemptible 7
Reusable resources 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, printers Deadlock occurs if each process holds one resource and requests the other 8
Deadlock with Reusable Resources P1 Request disk Lock disk Request tape Lock tape Unlock disk Unlock tape P1 Request tape Lock tape Request disk Lock disk Unlock tape Unlock disk
Consumable Resources Description: Created (produced) and destroyed (consumed) by a process Examples: Interrupts, signals, messages, and information in I/O buffers Deadlock: May occur if a Receive message is blocking May take a rare combination of events to cause deadlock 10
Example of Deadlock with a Consumable Resource Deadlock occurs if at some point each is waiting to receive a message from the other, assuming Receive is blocking. Caused by a design error. Process P Receive (Q) Send (Q, message1) Process Q Receive (P) Send (P, message2)
Preemptible Resources Can be taken away (preempted) from the owning process with no ill effects Can be restored to the process at a later time Examples: memory processor Cannot cause deadlock 12
Nonpreemptible Resources Cannot be taken away from the owning process without adversely affecting its computation Examples: printer tape disk semaphore Can cause deadlock 13
Four Conditions for Deadlock Necessary policies 1. Mutual exclusion must be enforced. 2. No preemption no resource can be forcibly removed from the process. 3. Hold and Wait a process may hold a resource while waiting for another. Sufficient circumstance 4. Circular wait closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain. Conditions 1-3 create a situation that could result in deadlock Condition 4 indicates that deadlock has occurred.
Resource Allocation Graphs A directed graph used to represent the current snapshot of a system, i.e. current allocations and pending requests. A circle represents a process A square represents a resource (can have more than one instance of a resource) A graph edge from a resource instance to a process implies that the resource instance is allocated to the process A graph edge from a process to a resource implies that the process is requesting an instance of the resource Can be used to determine if a system is deadlocked.
RAG Example with Deadlock 16
RAG Example with No Deadlock 17
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. 18
Approaches to Deadlock Handling Ostrich Approach Prevention Avoidance Detection and Recovery 19
Ostrich Approach Treat deadlock as a rare annoyance by ignoring it Used by most operating systems, including Windows and UNIX 20
Ostrich Approach Not Always Viable A real-time control system monitoring a gasoline refinery ensures the safe and proper operation of the refinery. An avoidance strategy or prevention strategy must be employed. A computerized pacemaker can t afford to miss a single beat deadlock avoidance or prevention must be employed Embedded computers cell phones, PDAs. These are SoCs or system on chips i.e. everything is on one chip and SoCs are characterized by a small set of resources and real-time processing constraints. Can t have a system administrator come in and decide which process to abort after deadlock has been detected. Either a prevention or avoidance strategy must be employed.
Deadlock Prevention Restrain ways a request can be made Indirect method: prevent any one of the three necessary conditions from occurring Mutual Exclusion No preemption Hold and Wait Direct method: prevent circular wait from occurring 22
Prevention Indirect Method Option 1 Don t enfoce mutual exclusion Rarely an option Option 2 Allow preemption Resource(s) must be preemptible Priority must be used to decide which process should be preempted.
Prevention Indirect Method (cont.) Option 3 Don t allow Hold and wait One approach a process must request all its resources at the same time. If it does not get all of them, then it must release all and block until all resources simultaneously available. Another approach a process, if denied a resource, must release all of its previously allocated resources. If necessary, it must request them all again together with the next resource. Drawbacks: Processes can be held up for a long time waiting to acquire all resources Processes can hold on to resources they do not immediately need Processes may not know in advance all the resources they need
Prevention Direct Method Prevent circular wait Organize resources into groups that are linearly ordered: G 1, G 2, G 3 G n. A process can request a resource from G1 and then from G2 and then from G3 and so on, but not vice versa. Drawbacks Processes may have to request and hold on to resources that may be used much later, thus wasting resources. Processes must know in advance all the resources they need.
Deadlock Avoidance Two strategies: Process initiation denial Resource allocation denial Each process declares the maximum number of resources of each type that it may need Requires that system has a priori information 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 and allocated resources, and the maximum demands/claims of the processes 26
Process Initiation Denial The following conditions will apply All resources are either available or allocated. No process can claim more than the total amount of resources. No process can claim or hold more resources than it originally claimed. Start a process only if all the needs of the current processes and the new process can be met. Pessimistic approach as the assumption is that all processes will require their maximum claims at the same time.
Resource Allocation Denial: Bank Analogy Credit limit Allocated Ann $10000 $1000 Mark $6000 $2000 Judy $3000 $1000 Greg $6000 $1000 Bank had a total of $12,000. Current total = $7000. Should Ann s request for $5000 be granted? If yes, amount remaining is $2000.
Resource Allocation Denial: Bank Analogy (cont.) Credit limit Allocated Ann $10000 $6000 Mark $6000 $2000 Judy $3000 $1000 Greg $6000 $1000 Bank had a total of $12,000. Current total = $2000. Can any other customer get her/his max credit limit? Judy can take the $2000 and finish, leaving $3000.
Resource Allocation Denial: Bank Analogy (cont.) Credit limit Allocated Ann $10000 $6000 Mark $6000 $2000 Greg $6000 $1000 Bank had a total of $12,000. Current total = $3000. No other customer can get her/his max credit limit According to Banker s algorithm, Ann s original request for $5000 should not have been granted.
Avoidance Using the Bankers algorithm A request is granted only if the request keeps the system in a safe state Otherwise, the process blocks A safe state is one which there is at least one sequence of resource allocations such that every process can claim its maximum resources and complete. An unsafe state does not imply deadlock, only the possibility of deadlock All processes do not request maximum claims. Even if they do, deadlock will occur depending on the sequence in which these demands are made.
Determination of a Safe State 32
Determination of a Safe State (cont.) 33
Determination of a Safe State (cont.) 34
Determination of a Safe State (cont.) 35
Deadlock Detection and Recovery Construct a resource allocation graph If only one instance of each resource exists Circular wait implies deadlock If there are two or more instances of any resource Circular wait could mean deadlock Must reduce the RAG to see if deadlock exists
Recovery from Deadlock 1. Abort all deadlocked processes. 2. Back up each deadlocked process to some previously defined checkpoint and restart all processes. Widely used in current database systems. Possibility of the same situation occurring again. 3. Successively abort all deadlocked processes, until deadlock no longer exists. Must decide which process to abort first. 4. Successively pre-empt resources until deadlock no longer exists. Must decide which process to pre-empt from
Recovery from Deadlock (cont.) To choose which process to abort or to pre-empt a device from: Least amount of processor time consumed so far Least amount of output produced so far Most estimated remaining time Least total resources allocated so far Lowest priority
An Integrated Approach Group resources into a number of classes. Use linear ordering to prevent circular wait between classes. Within a class use an algorithm that is most appropriate for the class.
Dining Philosophers Five philosophers who alternately think and eat spaghetti/sushi Share a fork/chopstick with each neighbor Assume each philosopher enters, picks up left utensil, then right utensil, then eats Deadlock if all enter at once Figure 6.11, page 276
Dining Philosophers problem Solution 1: Show with an example why this solution is not a correct solution. semaphore fork[5] = {1,1,1,1,1}; Philosopher(int i){ while(true){ Think(); semwait(fork[i]); semwait(fork[(i+1)mod5]); eat(); semsignal(fork[(i+1)mod5]); semsignal(fork[i]); } } int main(){ parbegin(philosopher(0), Philosopher(2), Philosopher(3), Philosopher(4), } Philosopher(1));
Solution 2: Show with an example why this solution is not a correct solution. semaphore x = 1; Philosopher(int i){ while(true){ Think(); semwait(x); pick up fork[i]; pick up fork[(i+1)mod5]; semsignal(x); eat(); semwait(x); place fork[i] back on the table; place fork[(i+1)mod5] back on the table; semsignal(x); } } int main(){ parbegin(philosopher(1), Philosopher(2), Philosopher(3), Philosopher(4), Philosopher(5)); }
Solution 3: Provide a correct solution for the dining philosophers problem.
Solutions to Dining Philosophers Problem Buy more utensils Equivalent to increasing resources Put utensil down if 2 nd utensil busy Can produce livelock if philosophers stay synchronized Room attendant Only let 4 of the philosophers into the room at once May have 4 philosophers in room, but only 1 can eat Invite some left-handed philosophers Grab forks in the other order (right fork, then left fork) Any mix will avoid deadlock (effective linear ordering on forks)