Administrivia � Assignments 0 & 1 � Class contact f or the next two weeks � Next week � midt er m exam � pr oj ect r eview & discussion (Chr is Chamber s) � Following week � Memor y Management (Wuchi Feng) 1
CSE 513 I ntroduction to Operating Systems Class 4 - I PC & Synchronization (2) Deadlock Jonathan Walpole Dept. of Comp. Sci. and Eng. Oregon Health and Science University 2
Counting semaphores � A binary semaphore can only take on the values of [0, 1]. � Class exercise: create a counting semaphore (generalized semaphore that we discussed previously) using just a binary semaphore!! 3
Possible solution Semaphore S1, S2, S3; // BINARY!! int C = N; // N is # locks down_c(sem){ downB(S3); up_c(sem){ downB(S1); downB(S1); C = C – 1; C = C + 1; if (C<0) { if (C<=0) { upB(S1); upB(S2); downB(S2); } } upB(S1); else { } upB(S1); } upB(S3); } 4
Monitors � I t is dif f icult to produce correct programs using semaphores � cor r ect or der ing of up and down is t r icky! � avoiding deadlock is t r icky! � boundar y condit ions ar e t r icky! � Can we get the compiler to generate the correct semaphore code f or us? � what ar e suit able higher level abst r act ions f or synchr onizat ion? 5
Monitors Collect related shared objects together in a monitor � Encapsulation and mutual exclusion � � Local dat a variables are accessible only via t he monit or’s procedures � P rocesses ent er t he monit or by invoking one of it s procedures � Only one process may execut e wit hin t he monit or at a given t ime Condition variables (cv) � � Wait (cv) – process blocked (queued) unt il condit ion holds � Signal(cv) – signals t he condit ion and unblocks (dequeues) a process 6
Monitor structures shared data monitor entry queue condition queues x y monitor operations initialization code 7
Monitor example f or mutual exclusion process Producer begin monitor: BoundedBuffer loop var buffer : ...; <produce char “c”> nextIn, nextOut :... ; BoundedBuffer.deposit(c) end loop entry deposit(c: char) end Producer� begin ... end entry remove(var c: char) process Consumer begin begin ... loop end BoundedBuffer.remove(c) <consume char “c”> end BoundedBuffer end loop end Consumer 8
Monitor example with condition variables monitor : BoundedBuffer var buffer : array[0..n-1] of char nextIn,nextOut : 0..n-1 := 0 fullCount : 0..n := 0 notEmpty, notFull : condition entry deposit(c:char) entry remove(var c: char) begin begin if (fullCount = n) then if (fullCount = n) then wait(notFull) wait(notEmpty) end if end if buffer[nextIn] := c c := buffer[nextOut] nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n fullCount := fullCount+1 fullCount := fullCount-1 signal(notEmpty) signal(notFull) end deposit end remove end BoundedBuffer 9
Monitor design choices Condition variables introduce a problem f or mutual � exclusion � only one process act ive in t he monit or at a t ime, so what t o do when a process is unblocked on signal? � must not block holding t he mut ex, so what t o do when a process blocks on wait ? Should signals be stored/ remembered? � � signals are not st ored � if signal occurs bef ore wait , signal is lost ! Should condition variables count? � 10
Monitor design choices Choices when A signals a condition that unblocks B � � A wait s f or B t o exit t he monit or or blocks again � B wait s f or A t o exit t he monit or or block � Signal causes A t o immediat ely exit t he monit or or block (on what condit ion?) Choices when A signals a condition that unblocks B & C � � B is unblocked, but C remains blocked � C is unblocked, but B remains blocked Choices when A calls wait and blocks � � a new ext ernal process is allowed t o ent er � but which one? 11
Common monitor semantics � Hoare semantics � On signal, allow signaled pr ocess t o r un; upon it s exit f r om t he monit or , signaler pr ocess cont inues � Brinch Hansen semantics � signaler must immediat ely exit f ollowing signal 12
Message Passing � I nterprocess communication � via shar ed memor y � acr oss machine boundar ies � Message passing can be used locally or remotely f or synchronization or general communication � pr ocesses use send and receive pr imit ives � r eceive can block like wait � send unblocks a pr ocess blocked on r eceive (like signal unblocking a wait ing pr ocess) 13
Producer consumer with message passing 14
Design Choices f or Message Passing � Mailboxes � syst em maint ains a buf f er of sent , but not yet r eceived, messages � Rendezvous � sender and r eceiver must be act ive at t he same t ime � r eceive must be blocked bef or e send occur s � ker nel does no buf f er ing � when does t he send r et ur n? 15
Barriers � Use of a barrier � pr ocesses appr oaching a bar r ier � all pr ocesses but one blocked at bar r ier � last pr ocess ar r ives, all ar e let t hr ough 16
Deadlock 17
Resources and Deadlocks Processes need access to resources in order to make progress � Examples of computer resources � � print ers � t ape drives � kernel dat a st ruct ures (process & f ile t able ent ries … ) � locks/ semaphores t o prot ect crit ical sect ions Suppose a process holds resource A and requests resource B � � at t he same t ime anot her process holds B and request s A � bot h are blocked and remain so … t his is deadlock 18
Resource Usage Model Sequence of events required to use a resource � r equest t he r esour ce (like acquir ing a mut ex lock) � use t he r esour ce � r elease t he r esour ce (like r eleasing a mut ex lock) � Must wait if request is denied � block � busy wait � f ail wit h er r or code � 19
Preemptable vs Nonpreemptable Resources � Preemptable resources � can be t aken away f r om a pr ocess wit h no ill ef f ect s � Nonpreemptable resources � will cause t he pr ocess t o f ail if t aken away � Deadlocks occur when processes are granted exclusive access to non- preemptable resources and wait when the resource is not available 20
Def inition of Deadlock A set of processes is deadlocked if each process in the set is waiting f or an event that only another process in the set can cause Usually the event is the release of a currently held � resource None of the processes can … � � be awakened � run � release resources 21
Deadlock conditions A deadlock situation can occur if and only if the f ollowing � conditions hold simultaneously � Mut ual exclusion condit ion – resource assigned t o one process � Hold and wait condit ion – processes can get more t han one resource � No preempt ion condit ion � Circular wait condit ion – chain of t wo or more processes (must be wait ing f or resource f rom next one in chain) 22
Resource acquisition scenarios down (resource_1); down (resource_2); use resource_1; use resource_2; up (resource_1); up (resource_2); down (resource_1); down (resource_1); down (resource_2); down (resource_2); use both resources; use both resources; up (resource_2); up (resource_2); up (resource_1); up (resource_1); 23
Resource acquisition scenarios down (resource_1); down (resource_2); use resource; use resource; up (resource_1); up (resource_2); down (resource_2); down (resource_1); use resource; use resource; up (resource_2); up (resource_1); down (resource_1); down (resource_2); down (resource_2); down (resource_1); use resources; use resources; up (resource_2); up (resource_1); up (resource_1); up (resource_2); 24
Flavors of Deadlock � Not so bad � Pr ogr ammer cr eat es a sit uat ion t hat deadlocks � Kill t he pr ogr am and move on � Worse � Spin locks and locking mechanisms wit hin t he OS 25
Other examples of deadlock 26
Deadlock modeling � Resource Allocation Graphs (RAGs) � Resource R assigned to process A � Process B waiting f or resource S � Process C and D are deadlocked over T & U 27
Dealing with deadlock � Four general strategies � I gnor e t he pr oblem • Hmm… advantages, disadvantages? � Det ect ion and r ecover y � Dynamic avoidance t hr ough r esour ce allocat ion � Pr event ion, by st r uct ur ally negat ing one of t he f our condit ions 28
Deadlock detection (1 resource of each) � Let the problem happen, then recover � How do you know it happened? � Do a depth- f irst- search on the resource allocation graph 29
Deadlock detection (1 resource of each) � Let the problem happen, then recover � How do you know it happened? � Do a depth- f irst- search on the resource allocation graph 30
Deadlock detection (1 resource of each) � Let the problem happen, then recover � How do you know it happened? � Do a depth- f irst- search on the resource allocation graph 31
Deadlock detection (1 resource of each) � Let the problem happen, then recover � How do you know it happened? � Do a depth- f irst- search on the resource allocation graph 32
Recommend
More recommend
