6. Concurrency: Deadlock

Transcription

1 CSC400 - Operating Systems 6. Concurrency: Deadlock J. Sumey Deadlock one problem that results from multiprogramming def: a process (or thread) is said to be deadlocked if it is waiting for an event that will not occur ex: 2 processes can be deadlocked on each other because of serially reusable resources a deadlock with the OS results in system deadlock CSC400 - Deadlock 2 CSC400 Operating Systems 1

2 Serially Reusable Resources typically the cause of deadlock when processes need >1 can be hardware memory, printer, DVDROM or software 2 processes attempting to lock 2 common records in a DB max number of open files system-wide spooling CSC400 - Deadlock 3 Resource Usage Procedure processes using an exclusive resource must follow a procedure: 1. request the resource, blocking if not available 2. use the resource 3. release it if not available at step 1, OS may either: block process then wake it when resource becomes available fail with an error code, making process responsible for waiting & trying again CSC400 - Deadlock 4 CSC400 Operating Systems 2

3 Ex: Dining Philosophers Problem models processes that compete for exclusive access to a shared resource goals: avoid deadlock and starvation i.e. indefinite postponement where a process is continually delayed in favor of other processes CSC400 - Deadlock 5 Dining Philosophers Attempt void typicalphilosopher() { while (true) { thinkforawhile(); eat(); } } void eat() { pickupleftfork(); pickuprightfork(); eatforawhile(); putdownrightfork(); putdownleftfork(); } why is this solution so dangerous? ex: CSC400 - Deadlock 6 CSC400 Operating Systems 3

4 About Resources resources may be: preemptable no harm in revoking exclusive access to a granted resource ex: CPU, RAM preemptable resources don t cause deadlock nonpreemptable revoking a previously granted resource would cause failure ex: printers, tape/optic drives also: shared vs. dedicated ex: an editor CSC400 - Deadlock 7 Deadlock Conditions in order for deadlock to occur, 4 conditions must hold: 1. mutual exclusion a shared resource must either be available or assigned to a single process 2. hold & wait a process currently holding previously granted resources may request more 3. no-preemption a granted resource may not be revoked by the system (holding process must release it) 4. circular wait the processes involved in holding or waiting for resources form a circular chain CSC400 - Deadlock 8 CSC400 Operating Systems 4

5 Deadlock Handling various approaches at dealing with deadlock ignore the problem prevention remove possibility of deadlock occurrence avoidance possibility exists but is carefully avoided detection / recovery determine which process(es) are deadlocked and take steps to clear deadlock CSC400 - Deadlock 9 Solution 1: Ignore the problem considers cost of handling deadlock vs. possibility of deadlock occurrence w.r.t. other problems in the system ex: the Ostrich algorithm practiced in Unix CSC400 - Deadlock 10 CSC400 Operating Systems 5

6 Solution 2: Prevention impose restrictions on processes to ensure at least 1 of the 4 conditions is never satisfied mutual exclusion: create a dedicated process (i.e. a monitor!) for a resource and use IPC ex: a printer would be owned by a spooler process; all processes send output to spooler instead problems: additional complications and overhead, doesn't fit every resource CSC400 - Deadlock 11 Solution 2: Prevention, cont. hold & wait: require process to request its resources "in toto"; i.e. all-or-nothing problems: process doesn't always know how many resources it needs in advance; wastes resources if overestimated no preemption: allow resources held by a process to be revoked if needed by another process no good; consider a printer also: lost work CSC400 - Deadlock 12 CSC400 Operating Systems 6

7 Solution 2: Prevention, cont. circular wait: OS assigns resources a system-wide numeric id and requires processes to request their resources in strict linear order (until release) guarantees no cycles in resource graph problem: difficult to implement when all potential resources are considered summary: deadlock prevention can result in poor resource usage CSC400 - Deadlock 13 Solution 3: Avoidance strategy: avoid possibility of deadlock by making correct choices when granting resources only works if certain info is known in advance implementation: Dijkstra's Banker's algorithm CSC400 - Deadlock 14 CSC400 Operating Systems 7

8 Avoidance via Banker's Algorithm modeled after a loan officer at a bank customers, lines of credit, pool of funds avoids unsafe state by always insuring that amount of available resources is sufficient to satisfy at least 1 process safe state: condition in which the OS can guarantee all process can complete within a finite amount of time example CSC400 - Deadlock 15 Banker's Algorithm - 1 applies to multiple processes requesting multiple resources uses 2 matrices: M1 is currently assigned resources M2 is resources still needed given Existing resources vector E and currently Possessed vector P, compute an Available vector A = E P CSC400 - Deadlock 16 CSC400 Operating Systems 8

9 Banker s Algorithm Example E: M1: Assigned M2: Needed { Ptr. Tape CDR RAM P P P P Ptr. Tape CDR RAM P P P P A=(E-P) P: A: Q: is this state safe? CSC400 - Deadlock 17 Banker's Algorithm - 2 safety check: 1. find a row R in M2 whose unmet resource needs < A and grant them if none, you're already dead 2. complete the process of row R and return its resources to A 3. repeat 1,2 for all processes; if completion possible, state was safe else it was unsafe CSC400 - Deadlock 18 CSC400 Operating Systems 9

10 Banker's Algorithm Weaknesses only works for a fixed number of resources what about failures, PM, etc? requires fixed number of processes not appropriate for today's computing needs must know max. needed resources in advance not always known! loans are issued and repaid in "finite time" to vague! (consider real-time systems) summary: deadlock avoidance via Banker's alg. not typically implemented in today's OSs CSC400 - Deadlock 19 Solution 4: Detection/Recovery allows deadlocks to occur, but then detects which processes/resources are involved and takes action to break it detection possible via resource allocation graphs can add significant overhead to OS recovery entails forcible termination of processes & resource reclamation difficult to do with acceptable results CSC400 - Deadlock 20 CSC400 Operating Systems 10

11 Resource Allocation Graphs model used to detect deadlock, based on directed graphs (digraphs) circle = process node (P) square = resource node (R) arc from R to P means R is held by P arc from P to R means P is blocked waiting for R a cycle means deadlock exists! as each resource is granted by OS, graph is reevaluated for any circular paths CSC400 - Deadlock 21 Checkpoints / Rollback a mechanism used to recover from certain deadlock situations a checkpoint stores a snapshot of the system state at some instant a rollback allows a return to a previous state as saved in a checkpoint common practice in DBMSs also found in Windows XP on CSC400 - Deadlock 22 CSC400 Operating Systems 11

12 Summary deadlock is a serious issue in concurrent systems and a primary concern in OSs may be acceptable for user processes, but not for the kernel! also not acceptable for real-time or mission-critical systems is the basis of on-going research and OS development CSC400 - Deadlock 23 CSC400 Operating Systems 12