



































Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Main points of this lecture are: Deadlock Prevention, Deadlock Theory, Resource Allocation Graph, Poor Locking Patterns, Resource Contention, Deadlock Situation, Buffering Deadlock, Locking in Order, Atomic Allocation, Streams of Input
Typology: Study notes
1 / 43
This page cannot be seen from the preview
Don't miss anything!




































If a process gets the resources it requests, it completes, exits, and releases resources. There are no outside influences upon the processes. Basic assumptions of deadlock theory: There is a cycle in the resource allocation graph (for locks). Incremental allocation (for a set of resources) leads to a situation in which N processes have managed to consume all resources, where each of the N processes needs more. Deadlock occurs when: All processes request locks in exactly the same order. Each process requests all resources that it needs in one atomic step. Deadlock cannot occur when: Recall from deadlock lecture Tuesday, October 18, 2011 1:17 PM Docsity.com
Poor locking patterns: certain patterns of locking create deadlocks inadvertently. Resource contention: a bunch of processes all need too much memory -- at the same time. Poor understanding of I/O: a set of processes end up waiting for one another due to poor planning or misunderstanding of I/O buffering. How do deadlocks arise? How do deadlocks arise? Thursday, October 18, 2012 2:00 PM Docsity.com
Suppose we have 20 pages of memory, and 5 processes, and each one owns 4 pages, and each one needs another page. Result: deadlock. Resource contention deadlock Resource contention deadlock Thursday, October 18, 2012 2:08 PM Docsity.com
#define READ 0 #define WRITE 1 #define SIZE 200 char buf[SIZE]; int p[2]; pipe(p); FILE *read = fdopen(p[READ],"r"); FILE *write = fdopen(p[WRITE], "w"); fprintf(write, "hi"); // not flushed fgets(buf, SIZE, read); // deadlock! Consider the following: Buffering deadlock Thursday, October 18, 2012 2:10 PM Docsity.com
process must wait for the process that locks it first. Then there are n processes left, which complete by the inductive hypothesis. Docsity.com
Existing code doesn't have to lock resources in order. There is often no logic that gives an appropriate lock order. But… Locking non-contiguous sets of locks can lead to deadlock. And… But… Tuesday, October 18, 2011 1:52 PM Docsity.com
Reading unbounded streams of input Dynamically allocating 2+-dimensional arrays. Several common computational patterns require incremental allocation But… But… Tuesday, October 18, 2011 1:53 PM Docsity.com
works on individual locks concentrates on when locks are made Lock prioritization prevents lock sequence deadlocks. works on resources concentrates on total resource usage transparent Banker's algorithm prevents resource starvation deadlocks. Two algorithms for deadlock prevention Two algorithms for lock handling Wednesday, October 20, 2010 5:38 PM Docsity.com
consider all of the locks we hold. at end of request, will hold all of them. allow (temporary) releases in the middle of the request. Whenever a lock request is made, Key idea: Good news: no deadlock possible. Bad news: not transparent. Key idea in lock prioritization Wednesday, October 13, 2004 6:00 PM Docsity.com
This is difficult to understand: Suppose A B; A must be locked first P: Lock A; Lock B; do something; Unlock A; Unlock B; Q: Lock B; Lock A; do something; Unlock B; Unlock A; strong semantics: when I ask for a lock, it's granted in order of the request. processes request locks all at once, and don't wait between requests. This diagram assumes In words: When I have two schedules: lock(A); lock(B); lock(B); lock(A); then the second is rewritten as lock(B); unlock(B); lock(A); lock(B); A subtlety Wednesday, October 13, 2004 6:00 PM Docsity.com
refer to semaphores by number. number is offset into table. semaphores are a kernel table arbitrary. unknown to process. Low-numbered semaphore wins. Implementation Implementation Wednesday, October 13, 2004 6:00 PM Docsity.com
Controversy: this takes (perhaps too much) time Reason: orthogonality : it is possible for processes to utilize "orthogonal sets" of locks, i.e., locks that have nothing to do with one another. if R1< S1 < R2 < S2, lock(R2) followed by lock(R1) in the application results in: lock(R2) unlock(R2) lock(R1) lock(R2) in the OS, even if there is no other process using R1, R2! Controversy over lock priority Wednesday, October 13, 2004 6:00 PM Docsity.com
Only works for single resources (not resources having multiple equivalent instances) ○ All priorities must be different or ties ensue, deadlock possible. ○ If two processes contend, and one locks in order while the other one does not, then the one that locks in order goes first. ○ ○ ○ ○ If two processes contend in order, then first one wins. Priority locking caveats ○ Priority locking caveats Wednesday, October 13, 2004 6:00 PM Docsity.com
lack of transparency : application has to know that locking has these properties
lack of handling of multiplicity : every resource must have one instance, to disambiguate priorities.
Two problems with lock priority: Problems with lock priority Thursday, October 21, 2004 1:39 PM Docsity.com