Deadlocks - I Deadlocks Deadlock Characterization Resource - PDF document

CSC 4103 - Operating Systems Roadmap Spring 2008 • Synchronization – Dining Philosophers Problem Lecture - IX – Monitors Deadlocks - I • Deadlocks – Deadlock Characterization – Resource Allocation Graphs Tevfik Ko � ar Louisiana State University February 19 th , 2008 1 2 Dining Philosophers Problem Dining-Philosophers Problem (Cont.) • The structure of Philosopher i : • Five philosophers spend their time eating and thinking. • They are sitting in front of a round table with Do { spaghetti served. wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); •There are five plates at the table and five chopsticks set between the plates. // eat • Eating the spaghetti requires the use of two chopsticks which the philosophers pick up one signal ( chopstick[i] ); at a time. signal (chopstick[ (i + 1) % 5] ); •Philosophers do not talk to each other. •Semaphore chopstick [5] initialized to 1 // think } while (true) ; 3 4 To Prevent Deadlock Problems with Semaphores • Wrong use of semaphore operations: • Ensures mutual exclusion, but does not prevent – semaphores A and B , initialized to 1 deadlock P 0 P 1 • Allow philosopher to pick up her chopsticks only if both wait (A); wait(B) wait (B); wait(A) chopsticks are available (i.e. in critical section) � Deadlock • Use an asymmetric solution: an odd philosopher picks – signal (mutex) …. wait (mutex) up first her left chopstick and then her right chopstick; � violation of mutual exclusion and vice versa – wait (mutex) … wait (mutex) � Deadlock – Omitting of wait (mutex) or signal (mutex) (or both) � violation of mutual exclusion or deadlock 5 6

Semaphores Monitors • A high-level abstraction that provides a convenient and effective mechanism for process synchronization • inadequate in dealing with deadlocks • Only one process may be active within the monitor at a time • do not protect the programmer from the easy mistakes of taking a semaphore that is already held by the same monitor monitor-name { process, and forgetting to release a semaphore that has // shared variable declarations procedure P1 (…) { …. } been taken … • mostly used in low level code, eg. operating systems procedure Pn (…) {……} • the trend in programming language development, Initialization code ( ….) { … } … though, is towards more structured forms of } synchronization, such as monitors and channels } • A monitor procedure takes the lock before doing anything else, and holds it until it either finishes or waits for a condition 7 8 Monitor - Example Condition Variables • Provide additional synchronization mechanism As a simple example, consider a monitor for performing transactions on a bank account. • condition x, y; monitor account { int balance := 0 • Two operations on a condition variable: – x.wait () – a process invoking this operation is function withdraw( int amount) { if amount < 0 then error "Amount may not be negative" suspended else if balance < amount then error "Insufficient funds" – x.signal () – resumes one of processes (if any) that else balance := balance - amount invoked x.wait () } function deposit( int amount) { If no process suspended, x.signal() operation has no if amount < 0 then error "Amount may not be negative" effect. else balance := balance + amount } } 9 10 Solution to Dining Philosophers (cont) Solution to Dining Philosophers using Monitors monitor DP void test (int i) { { if ((state[i] == HUNGRY) && enum { THINKING; HUNGRY , EATING) state [5] ; (state[(i + 1) % 5] != EATING) && condition self [5]; //to delay philosopher when he is (state[(i + 4) % 5] != EATING) ) { hungry but unable to get chopsticks state[i] = EATING ; self[i].signal () ; initialization_code() { } for (int i = 0; i < 5; i++) } state[i] = THINKING; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors void pickup (int i) { test((i + 4) % 5); state[i] = HUNGRY; test((i + 1) % 5); test(i);//only if both neighbors are not eating } if (state[i] != EATING) self [i].wait; } } � No two philosophers eat at the same time � No deadlock 11 12 � But starvation can occur!

The Deadlock Problem - revisiting • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. Deadlocks • Example – System has 2 disk drives. – P 1 and P 2 each hold one disk drive and each needs another one. • Example – semaphores A and B , initialized to 1 P 0 P 1 wait (A); wait(B) wait (B); wait(A) 13 14 Bridge Crossing Example Deadlock Characterization Deadlock can arise if four conditions hold simultaneously. 1. Mutual exclusion: nonshared resources; only one process at a time can use a specific resource 2. Hold and wait: a process holding at least • Traffic only in one direction. one resource is waiting to acquire additional • Each section of a bridge can be viewed as a resources held by other processes resource. 3. No preemption: a resource can be released • If a deadlock occurs, it can be resolved if only voluntarily by the process holding it, after that process has completed its task one car backs up (preempt resources and rollback). • Several cars may have to be backed up if a deadlock occurs. • Starvation is possible. 15 16 Deadlock Characterization (cont.) Resource-Allocation Graph • Used to describe deadlocks Deadlock can arise if four conditions hold simultaneously. 4. Circular wait: there exists a set { P 0 , P 1 , …, • Consists of a set of vertices V and a set of edges E . P 0 } of waiting processes such that P 0 is • V is partitioned into two types: waiting for a resource that is held by P 1 , P 1 – P = { P 1 , P 2 , …, P n }, the set consisting of all the processes is waiting for a resource that is held by in the system. P 2 , …, P n –1 is waiting for a resource that is held by – R = { R 1 , R 2 , …, R m }, the set consisting of all resource P n , and P n is waiting for a resource that is types in the system. held by P 0 . • P requests R – directed edge P 1 � R j • R is assigned to P – directed edge R j � P i 17 18

Example of a Resource Allocation Graph Resource-Allocation Graph (Cont.) • Process • Resource Type with 4 instances P i • P i requests instance of R j R j • P i is holding an instance of R j P i R j 19 20 Resource Allocation Graph – Example 1 Basic Facts • If graph contains no cycles � no deadlock. • If graph contains a cycle � there may be a deadlock – if only one instance per resource type, then deadlock. – if several instances per resource type, possibility of deadlock. � No Cycle, no Deadlock 21 22 Resource Allocation Graph – example 2 Resource Allocation Graph – Example 3 � Deadlock Which Processes deadlocked? � Cycle, but no Deadlock � P1 & P2 & P3 23 24

Rule of Thumb Summary • A cycle in the resource allocation graph Hmm. • Synchronization – Is a necessary condition for a deadlock – Dining Philosophers Problem . – But not a sufficient condition – Monitors • Deadlocks – Deadlock Characterization – Resource Allocation Graphs • Next Lecture: Deadlocks - II • Reading Assignment: Chapter 7 from Silberschatz. 25 26 Acknowledgements • “Operating Systems Concepts” book and supplementary material by A. Silberschatz, P . Galvin and G. Gagne • “Operating Systems: Internals and Design Principles” book and supplementary material by W. Stallings • “Modern Operating Systems” book and supplementary material by A. Tanenbaum • R. Doursat and M. Yuksel from UNR 27