lecture4 - CSCC69H Lecture 3 Dan Zingaro May 17, 2010...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CSCC69H Lecture 3 Dan Zingaro May 17, 2010 Deadlocks I A resource is anything that can be used by only a single process at any instant of time I e.g. hardware devices, locked records in a database I Preemptable resource: can be taken away from a process (e.g. memory) I Nonpreemptable resource: cannot be taken away without causing the computation to fail (e.g. CD drive while burning) I Deadlocks involve nonpreemptable resources I A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. Example: Deadlock Assume bank accounts are objects with a mutex and a balance . To transfer from one account to another: lock sourceAccount.mutex lock destAccount.mutex sourceAccount.balance = sourceAccount.balance - amount destAccount.balance = destAccount.balance + amount unlock sourceAccount.mutex unlock destAccount.mutex I Lets say A transfers money to B, and B transfers money to A, at about the same time I The mutexes ensure there will be no races I But we can deadlock if A locks their account, and then (after a context-switch) B locks their account I A will wait indefinitely for Bs mutex, as B waits indefinitely for As mutex Deadlock Prevention through Resource Ordering I Each bank account is stored at a numeric address in memory I min (account1, account2) : return the account at the lower address in memory I max (account1, account2) : return the account at the higher address in memory I Now, no deadlock is possible if both threads request the account locks in the same order lock min(sourceAccount, destAccount).mutex lock max(sourceAccount, destAccount).mutex sourceAccount.balance = sourceAccount.balance - amount destAccount.balance = destAccount.balance + amount unlock sourceAccount.mutex unlock destAccount.mutex Deadlock Prevention through Resource Ordering... I This technique works for any number of resources, not just two I Assign a linear ordering to resource types and force acquisition in that order I e.g. R i is requested before R j if i < j I For deadlock to occur, p must hold r i and request r j , while q holds r j and requests r i I This implies that i < j (for P s request order) and j < i (for Q s request order), which is impossible. I However, we require that all resource requirements are known in advance I Hard to come up with total order when there are lots of resource types Deadlock Detection and Recovery I Here, we let deadlock occur, but then detect it and recover I If we have one resource of each type, we can construct a resource allocation graph I Finding circular waits is equivalent to finding a cycle in the graph I Two types of nodes: processes (drawn as circles) and resources (drawn as squares) I Arcs from a resource to a process represent allocations of resources I Arcs from a process to a resource represent a process blocked waiting for that resource I Any algorithm for finding a cycle in a directed graph will do I With multiple instances of a type of resource, cycles may exist without deadlock; different algorithm is required Example Resource Allocation Graph P owns R1 and is waiting for R2; Q owns R2 and is waiting for R1....
View Full Document

This note was uploaded on 02/05/2011 for the course CS 69 taught by Professor Cathy during the Summer '10 term at University of Toronto- Toronto.

Page1 / 26

lecture4 - CSCC69H Lecture 3 Dan Zingaro May 17, 2010...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online