cs 471 - lecture 3 process synchronization & deadlock ch. 6 (6.1-6.7), 7 fall 2009
TRANSCRIPT
![Page 1: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/1.jpg)
CS 471 - Lecture 3
Process Synchronization & Deadlock
Ch. 6 (6.1-6.7), 7
Fall 2009
![Page 2: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/2.jpg)
3.2GMU – CS 571
Process Synchronization
Race Conditions The Critical Section Problem Synchronization Hardware Classical Problems of Synchronization Semaphores Monitors Deadlock
![Page 3: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/3.jpg)
3.3GMU – CS 571
Concurrent Access to Shared Data
Suppose that two processes A and B have access to a shared variable “Balance”.
PROCESS A: PROCESS B:
Balance = Balance - 100 Balance = Balance + 200
Further, assume that Process A and Process B are executing concurrently in a time-shared, multi-programmed system.
![Page 4: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/4.jpg)
3.4GMU – CS 571
Concurrent Access to Shared Data
The statement “Balance = Balance – 100” is implemented by several machine level instructions such as:A1. lw $t0, BALANCE
A2. sub $t0,$t0,100
A3. sw $t0, BALANCE
Similarly, “Balance = Balance + 200” can be implemented by the following: B1. lw $t1, BALANCE
B2. add $t1,$t1,200
B3. sw $t1, BALANCE
![Page 5: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/5.jpg)
3.5GMU – CS 571
Race Conditions
Scenario 1:
A1. lw $t0, BALANCE
A2. sub $t0,$t0,100
A3. sw $t0, BALANCE
Context Switch
B1. lw $t1, BALANCE
B2. add $t1,$t1,200
B3. sw $t1, BALANCE Balance is increased by
100
Observe: In a time-shared system the exact instruction execution order cannot be predicted
Scenario 2:
A1. lw $t0, BALANCE
A2. sub $t0,$t0,100
Context Switch
B1. lw $t1, BALANCE
B2. add $t1,$t0,200
B3. sw $t1, BALANCE
Context Switch
A3. sw $t0, BALANCE Balance is decreased by
100
![Page 6: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/6.jpg)
3.6GMU – CS 571
Race Conditions
Situations where multiple processes are writing or reading some shared data and the final result depends on who runs precisely when are called race conditions.
A serious problem for most concurrent systems using shared variables! Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes.
We must make sure that some high-level code sections are executed atomically.
Atomic operation means that it completes in its entirety without worrying about interruption by any other potentially conflict-causing process.
![Page 7: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/7.jpg)
3.7GMU – CS 571
The Critical-Section Problem
n processes all competing to use some shared data
Each process has a code segment, called critical section (critical region), in which the shared data is accessed.
Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in their critical section.
The execution of the critical sections by the processes must be mutually exclusive in time.
![Page 8: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/8.jpg)
3.8GMU – CS 571
Mutual Exclusion
![Page 9: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/9.jpg)
3.9GMU – CS 571
Solving Critical-Section Problem Any solution to the problem must satisfy three conditions.
1. Mutual Exclusion:
No two processes may be simultaneously inside the same critical section.
2. Bounded Waiting:
No process should have to wait forever to enter a critical section.
3. Progress:
No process executing a code segment unrelated to a given critical section can block another
process trying to enter the same critical section.
Arbitrary Speed:
In addition, no assumption can be made about the relative speed of different processes (though all processes have a non-zero speed).
![Page 10: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/10.jpg)
3.10GMU – CS 571
Attempts to solve mutual exclusiondo {
….
entry section
critical section
exit section
remainder section
} while (1);
General structure as above Two processes P1 and P2 Processes may share common variables Assume each statement is executed atomically (is this
realistic?)
![Page 11: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/11.jpg)
3.11GMU – CS 571
Algorithm 1 Shared variables:
• int turn; initially turn = 0
• turn = i Pi can enter its critical section
Process Pi
do {
while (turn != i) ; //it can be forever
critical section
turn = j;
reminder section
} while (1);
Satisfies mutual exclusion, but not progress
busy waiting
![Page 12: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/12.jpg)
3.12GMU – CS 571
Algorithm 2 Shared variables:
• boolean flag[2]; initially flag[0] = flag[1] = false
• flag[i] = true Pi wants to enter its critical region
Process Pi
do {
flag[i]=true;
while (flag[j]) ; //Pi & Pj both waiting
critical section
flag[i] = false;
reminder section
} while (1);
Satisfies mutual exclusion, but not progress
![Page 13: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/13.jpg)
3.13GMU – CS 571
Algorithm 3: Peterson’s solution Combine shared variables of previous attempts Process Pi
do {
flag[i]=true;
turn = j;
while (flag[j] and turn == j) ;
critical section
flag[i] = false;
reminder section
} while (1);
Meets our 3 requirements (assuming each individual statement is executed atomically)
flag[j] = false or turn = i
![Page 14: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/14.jpg)
3.14GMU – CS 571
Synchronization Hardware Many machines provide special hardware instructions
that help to achieve mutual exclusion
The TestAndSet (TAS) instruction tests and modifies the content of a memory word atomically
TAS R1,LOCK reads the contents of the memory word LOCK into register R1, and stores a nonzero value (e.g. 1) at the memory word LOCK (atomically)
Assume LOCK = 0• calling TAS R1, LOCK will set R1 to 0, and set LOCK to 1.
Assume LOCK = 1• calling TAS R1, LOCK will set R1 to 1, and set LOCK to 1.
![Page 15: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/15.jpg)
3.15GMU – CS 571
Mutual Exclusion with Test-and-Set
Initially, shared memory word LOCK = 0.
Process Pi
do {
entry_section: TAS R1, LOCK
CMP R1, #0 /* was LOCK = 0? */
JNE entry_section
critical section
MOVE LOCK, #0 /* exit section */
remainder section
} while(1);
![Page 16: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/16.jpg)
3.16GMU – CS 571
Classical Problems of Synchronization
Producer-Consumer Problem
Readers-Writers Problem
Dining-Philosophers Problem
We will develop solutions using semaphores and monitors as synchronization tools (no busy waiting).
![Page 17: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/17.jpg)
3.17GMU – CS 571
Producer/Consumer Problem
Producer Consumer
bounded size buffer (N)
Producer and Consumer execute concurrently but only one should be accessing the buffer at a time. Producer puts items to the buffer area but should not be allowed to put items into a full buffer Consumer process consumes items from the buffer but cannot remove information from an empty buffer
![Page 18: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/18.jpg)
3.18GMU – CS 571
Readers-Writers Problem
A data object (e.g. a file) is to be shared among several concurrent processes.
A writer process must have exclusive access to the data object.
Multiple reader processes may access the shared data simultaneously without a problem
Several variations on this general problem
![Page 19: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/19.jpg)
3.19GMU – CS 571
Dining-Philosophers Problem
Five philosophers share a common circular table. There are five chopsticks and a bowl of rice (in the middle). When a philosopher gets hungry, he tries to pick up the closest chopsticks.
A philosopher may pick up only one chopstick at a time, and cannot pick up a chopstick already in use. When done, he puts down both of his chopsticks, one after the other.
![Page 20: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/20.jpg)
3.20GMU – CS 571
Synchronization
Synchronization• Most synchronization can be regarded as
either: Mutual exclusion (making sure that only one
process is executing a CRITICAL SECTION [touching a variable or data structure, for example] at a time),
or as CONDITION SYNCHRONIZATION, which
means making sure that a given process does not proceed until some condition holds (e.g. that a variable contains a given value)
The sample problems will illustrate this
Competition
Cooperation
![Page 21: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/21.jpg)
3.21GMU – CS 571
Semaphores
Language level synchronization construct introduced by E.W. Dijkstra (1965)
Motivation: Avoid busy waiting by blocking a process execution until some condition is satisfied.
Each semaphore has an integer value and a queue. Two operations are defined on a semaphore variable
s:
wait(s) (also called P(s) or down(s))
signal(s) (also called V(s) or up(s)) We will assume that these are the only
user-visible operations on a semaphore. Semaphores are typically available in thread
implementations.
![Page 22: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/22.jpg)
3.22GMU – CS 571
Semaphore Operations
Conceptually a semaphore has an integer value greater than or equal to 0.
wait(s):: wait/block until s.value > 0; s.value-- ; /* Executed atomically! */
A process executing the wait operation on a semaphore with value 0 is blocked (put on a queue) until the semaphore’s value becomes greater than 0.• No busy waiting
signal(s):: s.value++; /* Executed atomically! */
![Page 23: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/23.jpg)
3.23GMU – CS 571
Semaphore Operations (cont.)
If multiple processes are blocked on the same semaphore s, only one of them will be awakened when another process performs signal(s) operation. Who will have priority?
Binary semaphores only have value 0 or 1. Counting semaphores can have any non-
negative value. [We will see some of these later]
![Page 24: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/24.jpg)
3.24GMU – CS 571
Shared data:
semaphore mutex; /* initially mutex = 1 */
Process Pi:
do {
wait(mutex);
critical section
signal(mutex);
remainder section
} while (1);
Critical Section Problem with Semaphores
![Page 25: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/25.jpg)
3.25GMU – CS 571
Re-visiting the “Simultaneous Balance Update” Problem
Process A:
…….
wait (mutex); Balance = Balance – 100;
signal (mutex);
……
Shared data:
int Balance;
semaphore mutex; // initially mutex = 1
Process B:
…….
wait (mutex); Balance = Balance + 200;
signal (mutex);
……
![Page 26: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/26.jpg)
3.26GMU – CS 571
Suppose we need to execute B in Pj only after A executed in Pi
Use semaphore flag initialized to 0 Code:
Pi : Pj :
A wait(flag)
signal(flag) B
Semaphore as a General Synchronization Tool
![Page 27: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/27.jpg)
3.27GMU – CS 571
Returning to Producer/Consumer
Producer Consumer
bounded size buffer (N)
Producer and Consumer execute concurrently but only one should be accessing the buffer at a time. Producer puts items to the buffer area but should not be allowed to put items into a full buffer Consumer process consumes items from the buffer but cannot remove information from an empty buffer
![Page 28: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/28.jpg)
3.28GMU – CS 571
Producer-Consumer Problem (Cont.)
Make sure that:
1.The producer and the consumer do not access the buffer area and related variables at the same time.
2.No item is made available to the consumer if all the buffer slots are empty.
3.No slot in the buffer is made available to the producer if all the buffer slots are full.
competition
cooperation
![Page 29: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/29.jpg)
3.29GMU – CS 571
Producer-Consumer Problem
Shared data
semaphore full, empty, mutex;
Initially:
full = 0 /* The number of full buffers */
empty = n /* The number of empty buffers */
mutex = 1 /* Semaphore controlling the access to the buffer pool */
binary
counting
![Page 30: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/30.jpg)
3.30GMU – CS 571
Producer Process
do { …
produce an item in p …
wait(empty);wait(mutex);
…add p to buffer
…signal(mutex);signal(full);
} while (1);
![Page 31: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/31.jpg)
3.31GMU – CS 571
Consumer Process
do { wait(full);wait(mutex);
…remove an item from buffer to c
…signal(mutex);signal(empty);
…consume the item in c
…} while (1);
![Page 32: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/32.jpg)
3.32GMU – CS 571
Readers-Writers Problem A data object (e.g. a file) is to be shared among
several concurrent processes. A writer process must have exclusive access
to the data object. Multiple reader processes may access the
shared data simultaneously without a problem
Shared data
semaphore mutex, wrt;
int readcount;
Initially
mutex = 1, readcount = 0, wrt = 1;
![Page 33: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/33.jpg)
3.33GMU – CS 571
Readers-Writers Problem: Writer Process
wait(wrt); …
writing is performed …
signal(wrt);
![Page 34: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/34.jpg)
3.34GMU – CS 571
Readers-Writers Problem: Reader Process
wait(mutex);readcount++;if (readcount == 1)
wait(wrt);signal(mutex);
…reading is performed
…wait(mutex);readcount--;if (readcount == 0)
signal(wrt);signal(mutex);
Is this solution o.k.?
![Page 35: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/35.jpg)
3.35GMU – CS 571
Dining-Philosophers Problem
Shared data
semaphore chopstick[5];
Initially all semaphore values are 1
Five philosophers share a common circular table. There are five chopsticks and a bowl of rice (in the middle). When a philosopher gets hungry, he tries to pick up the closest chopsticks.
A philosopher may pick up only one chopstick at a time, and cannot pick up a chopstick already in use. When done, he puts down both of his chopsticks, one after the other.
![Page 36: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/36.jpg)
3.36GMU – CS 571
Dining-Philosophers Problem
Philosopher i:do {
wait(chopstick[i]);wait(chopstick[(i+1) % 5]);
…eat …
signal(chopstick[i]);signal(chopstick[(i+1) % 5]);
…think …
} while (1);
Is this solution o.k.?
![Page 37: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/37.jpg)
3.37GMU – CS 571
Semaphores
It is generally assumed that semaphores are fair, in the sense that processes complete semaphore operations in the same order they start them
Problems with semaphores• They're pretty low-level.
When using them for mutual exclusion, for example (the most common usage), it's easy to forget a wait or a release, especially when they don't occur in strictly matched pairs.
• Their use is scattered. If you want to change how processes synchronize access to a
data structure, you have to find all the places in the code where they touch that structure, which is difficult and error-prone.
• Order Matters What could happen if we switch the two ‘wait’ instructions in the
consumer (or producer)?
![Page 38: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/38.jpg)
3.38GMU – CS 571
Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes.
Let S and Q be two semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
M M signal(S);
signal(Q); signal(Q)
signal(S); Starvation – indefinite blocking. A process
may never be removed from the semaphore queue in which it is suspended.
Deadlock and Starvation
![Page 39: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/39.jpg)
3.39GMU – CS 571
High Level Synchronization Mechanisms
Several high-level mechanisms that are easier to use have been proposed. • Monitors• Critical Regions• Read/Write locks
We will study monitors (Java and Pthreads provide synchronization mechanisms based on monitors)
They were suggested by Dijkstra, developed more thoroughly by Brinch Hansen, and formalized nicely by Tony Hoare in the early 1970s
Several parallel programming languages have incorporated some version of monitors as their fundamental synchronization mechanism
![Page 40: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/40.jpg)
3.40GMU – CS 571
Monitors A monitor is a shared object
with operations, internal state, and a number of condition queues. Only one operation of a given monitor may be active at a given point in time
A process that calls a busy monitor is delayed until the monitor is free• On behalf of its calling
process, any operation may suspend itself by waiting on a condition
• An operation may also signal a condition, in which case one of the waiting processes is resumed, usually the one that waited first
![Page 41: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/41.jpg)
3.41GMU – CS 571
Monitors
Condition (cooperation) Synchronization with Monitors:• Access to the shared data
in the monitor is limited by the implementation to a single process at a time; therefore, mutually exclusive access is inherent in the semantic definition of the monitor
• Multiple calls are queued
Mutual Exclusion (competition) Synchronization with Monitors:• delay takes a queue type
parameter; it puts the process that calls it in the specified queue and removes its exclusive access rights to the monitor’s data structure
• continue takes a queue type parameter; it disconnects the caller from the monitor, thus freeing the monitor for use by another process. It also takes a process from the parameter queue (if the queue isn’t empty) and starts it
![Page 42: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/42.jpg)
3.42GMU – CS 571
Shared Data with Monitors
Monitor SharedData
{ int balance;
void updateBalance(int amount);
int getBalance();
void init(int startValue) { balance = startValue; }
void updateBalance(int amount){ balance += amount; }
int getBalance(){ return balance; }
}
![Page 43: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/43.jpg)
3.43GMU – CS 571
Monitors To allow a process to wait within the monitor, a
condition variable must be declared, as
condition x, y; Condition variable can only be used with the
operations wait and signal.• The operation
x.wait();means that the process invoking this operation is suspended until another process invokes
x.signal();
• The x.signal operation resumes exactly one suspended process on condition variable x. If no process is suspended on condition variable x, then the signal operation has no effect.
Wait and signal operations of the monitors are not the same as semaphore wait and signal operations!
![Page 44: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/44.jpg)
3.44GMU – CS 571
Monitor with Condition Variables When a process P “signals” to wake up the process Q
that was waiting on a condition, potentially both of them can be active.
However, monitor rules require that at most one process can be active within the monitor. Who will go first?
• Signal-and-wait: P waits until Q leaves the monitor (or, until Q waits for another condition).
• Signal-and-continue: Q waits until P leaves the monitor (or, until P waits for another condition).
• Signal-and-leave: P has to leave the monitor after signaling (Concurrent Pascal)
The design decision is different for different programming languages
![Page 45: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/45.jpg)
3.45GMU – CS 571
Monitor with Condition Variables
![Page 46: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/46.jpg)
3.46GMU – CS 571
Producer-Consumer Problem with Monitors
Monitor Producer-consumer
{
condition full, empty;
int count;
void insert(int item); //the following slide
int remove(); //the following slide
void init() { count = 0;
}}
![Page 47: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/47.jpg)
3.47GMU – CS 571
Producer-Consumer Problem with Monitors (Cont.)
void insert(int item){if (count == N) full.wait();
insert_item(item); // Add the new item count ++;if (count == 1) empty.signal();
}int remove()
{ int m;if (count == 0) empty.wait();m = remove_item(); // Retrieve one itemcount --;if (count == N–1) full.signal();
return m; }
![Page 48: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/48.jpg)
3.48GMU – CS 571
Producer-Consumer Problem with Monitors (Cont.)
void producer() { //Producer process while (1) {
item = Produce_Item();
Producer-consumer.insert(item); }
}
void consumer() { //Consumer process while (1) {
item =
Producer-consumer.remove(item);
consume_item(item); }
}
![Page 49: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/49.jpg)
3.49GMU – CS 571
Monitors
Evaluation of monitors:• Strong support for mutual exclusion synchronization • Support for condition synchronization is very similar as
with semaphores, so it has the same problems• Building a correct monitor requires that one think about the
"monitor invariant“. The monitor invariant is a predicate that captures the notion "the state of the monitor is consistent."
It needs to be true initially, and at monitor exit It also needs to be true at every wait statement
• Can implement monitors in terms of semaphores that semaphores can do anything monitors can.
• The inverse is also true; it is trivial to build a semaphores from monitors
![Page 50: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/50.jpg)
3.50GMU – CS 571
Dining-Philosophers Problem with Monitors
monitor dp {
enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following
slidesvoid putdown(int i) // following
slidesvoid test(int i) // following
slidesvoid init() {
for (int i = 0; i < 5; i++)state[i] = thinking;
}}
Each philosopher will perform:
dp. pickup (i);
…eat..
dp. putdown(i);
![Page 51: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/51.jpg)
3.51GMU – CS 571
void pickup(int i) {state[i] = hungry;test(i);if (state[i] != eating)
self[i].wait();}
void putdown(int i) {state[i] = thinking;// test left and right neighbors// wake them up if possibletest((i+4) % 5);test((i+1) % 5);
}
Solving Dining-Philosophers Problem with Monitors
![Page 52: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/52.jpg)
3.52GMU – CS 571
void test(int i) {if ( (state[(i + 4) % 5] != eating)
&& (state[i] == hungry) && (state[(i + 1) % 5] != eating)) {
state[i] = eating;self[i].signal();
}}
Solving Dining-Philosophers Problem with Monitors
Is this solution o.k.?
![Page 53: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/53.jpg)
3.53GMU – CS 571
Dining Philosophers problem (Cont.)
Philosopher1 arrives and starts eating
Philosopher2 arrives; he is suspended
Philosopher3 arrives and starts eating
Philosopher1 puts down the chopsticks, wakes up Philosopher2 (suspended once again)
Philosopher1 re-arrives, and starts eating
Philosopher3 puts down the chopsticks, wakes up Philosopher2 (suspended once again)
Philosopher3 re-arrives, and starts eating
……
![Page 54: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/54.jpg)
3.54GMU – CS 571
Deadlock
In a multi-programmed environment, processes/threads compete for (exclusive) use of a finite set of resources
![Page 55: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/55.jpg)
3.55GMU – CS 571
Necessary Conditions for Deadlock
1. Mutual exclusion – At least one resource must be held in a non-sharable mode
2. Hold and wait – A process holds at least one resource while waiting to acquire additional resources that are being held by other processes
3. No preemption – a resource is only released voluntarily from a process
4. Circular wait: A set of processes {P0,…,Pn} such that Pi is waiting for a resource held by Pi+1 and Pn is waiting for a resource held by P0
![Page 56: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/56.jpg)
3.56GMU – CS 571
Resource-Allocation Graphs
Process
Resource Type with 4 instances
Pi requests instance of Rj
Pi is holding an instance of Rj
Pi
PiRj
Rj
![Page 57: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/57.jpg)
3.57GMU – CS 571
Resource Allocation Graph
deadlocked
request edge
assignment
edge
![Page 58: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/58.jpg)
3.58GMU – CS 571
Graph With A Cycle But No Deadlock
![Page 59: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/59.jpg)
3.59GMU – CS 571
Handling Deadlock
Deadlock prevention – ensure that at least one of the necessary conditions cannot occur
Deadlock avoidance – analysis determines whether a new request could lead toward a deadlock situation
Deadlock detection – detect and recover from any deadlocks that occur
![Page 60: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/60.jpg)
3.60GMU – CS 571
Deadlock Prevention
Prevent deadlocks by ensuring one of the required conditions cannot occur
Mutual exclusion this condition typically cannot be removed for non-sharable resources
Hold and wait elimination requires that processes request and acquire all resources in single atomic action
No preemption add pre-emption when waiting for a resource and some other processes needs a resource currently held
Circular wait require processes to acquire resources in some ordered way.
![Page 61: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/61.jpg)
3.61 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Deadlock AvoidanceDeadlock Avoidance
When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state.
System is in safe state if there exists a sequence <P1, P2, …, Pn> of ALL the processes in the systems such that for each Pi, the resources that Pi can still request can be satisfied by currently available resources + resources held by all the Pj, with j < i. If a system is in safe state no deadlocks.
If a system is in unsafe state possibility of deadlock.
Avoidance ensure that a system will never enter an unsafe state.
![Page 62: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/62.jpg)
3.62GMU – CS 571
Example: Deadlock Avoidance
Overall System has 12 tape drives and 3 processes:
Safe state: <P1, P0, P2>• P1 only needs 2 of the 3 remaining drives
• P0 needs 5 (3 remaining + 2 held by P1)
• P2 needs 7 (3 remaining + 4 held by P0)
Max Needs Current Needs
P0 10 5
P1 4 2
P2 9 2
3 free drives
![Page 63: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/63.jpg)
3.63GMU – CS 571
Example (cont’d)
Overall System has 12 tape drives and 3 processes.
Now P2 requests 1 more drive – are we still in a safe state if we grant this request??
Unsafe state – only P1 can be granted its request and once it terminates, there are still not enough drives for P0 and P2 potential deadlock
Avoidance algorithm would make P2 wait
Max Needs Current Needs
P0 10 5
P1 4 2
P2 9 3
2 free drives
![Page 64: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/64.jpg)
3.64 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Avoidance algorithmsAvoidance algorithms
Single instance of a resource type. Use a resource-allocation graph
Multiple instances of a resource type. Use the banker’s algorithm
![Page 65: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/65.jpg)
3.65 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Resource-Allocation Graph SchemeResource-Allocation Graph Scheme
Claim edge Pi Rj indicated that process Pi may request resource Rj; represented by a dashed line.
Claim edge converts to request edge when a process requests a resource.
Request edge converted to an assignment edge when the resource is allocated to the process.
When a resource is released by a process, assignment edge reconverts to a claim edge.
Resources must be claimed a priori in the system.
![Page 66: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/66.jpg)
3.66 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Resource-Allocation GraphResource-Allocation Graph
P1 has been assigned R1
P2 has requested R1
Both P1 and P2 may request
R2 in the future
A request can be granted only
if converting the request edge
to an assignment edge does not
result in the formation of a cycle in
the resource allocation graph
![Page 67: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/67.jpg)
3.67 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Unsafe State In Resource-Allocation GraphUnsafe State In Resource-Allocation Graph
![Page 68: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/68.jpg)
3.68 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Banker’s AlgorithmBanker’s Algorithm
Multiple instances.
Each process must a priori claim maximum use.
When a process requests a resource it may have to wait.
When a process gets all its resources it must return them in a finite amount of time.
![Page 69: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/69.jpg)
3.69GMU – CS 571
Bankers Algorithm
Overall System has m=3 different resource types (A=10, B=5, C=7) and n=5 processes:
In a safe state??
Allocation
A B C
Max
A B C
P0 0 1 0 7 5 3
P1 2 0 0 3 2 2
P2 3 0 2 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3
![Page 70: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/70.jpg)
3.70 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Data Structures for the Banker’s Algorithm Data Structures for the Banker’s Algorithm
Available: Vector of length m. If available [j] = k, there are k instances of resource type Rj available.
Max: n x m matrix. If Max [i,j] = k, then process Pi may request at most k instances of resource type Rj.
Allocation: n x m matrix. If Allocation[i,j] = k then Pi is currently allocated k instances of Rj.
Need: n x m matrix. If Need[i,j] = k, then Pi may need k more instances of Rj to complete its task.
Need [i,j] = Max[i,j] – Allocation [i,j].
Let n = number of processes, and m = number of resources types.
![Page 71: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/71.jpg)
3.71GMU – CS 571
Bankers Algorithm (cont’d)
Overall System has 3 different resource types (A=10, B=5, C=7) and 5 processes:
safe state: <P1,P3,P4,P2,P0>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
3 3 2
![Page 72: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/72.jpg)
3.72GMU – CS 571
Bankers Algorithm (cont’d)
<P1,P3,P4,P2,P0> All of P1’s requests can be granted from available
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
3 3 2
*
*
![Page 73: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/73.jpg)
3.73GMU – CS 571
Bankers Algorithm (cont’d)
<P1,P3,P4,P2,P0> Once P1 ends, P3’s requests could be granted
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
5 3 2
**
![Page 74: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/74.jpg)
3.74GMU – CS 571
Bankers Algorithm (cont’d)
<P1,P3,P4,P2,P0> Once P3 ends, P4’s requests could be granted
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
7 4 3*
*
*
![Page 75: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/75.jpg)
3.75GMU – CS 571
Bankers Algorithm (cont’d)
<P1,P3,P4,P2,P0> Once P4 ends, P2’s requests could be granted
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
7 4 5
*
*
![Page 76: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/76.jpg)
3.76GMU – CS 571
Bankers Algorithm (cont’d)
<P1,P3,P4,P2,P0> Once P2 ends, P0’s requests could be granted
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
10 4 7
*
![Page 77: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/77.jpg)
3.77 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Safety Algorithm (Sec. 7.5.3.1)Safety Algorithm (Sec. 7.5.3.1)
1. Let Work and Finish be vectors of length m and n, respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1.
2. Find an i such that both:
(a) Finish [i] = false
(b) Needi Work
If no such i exists, go to step 4.
3. Work = Work + Allocationi
Finish[i] = truego to step 2.
4. If Finish [i] == true for all i, then the system is in a safe state.
May require m x n2 operations
![Page 78: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/78.jpg)
3.78GMU – CS 571
Bankers Algorithm (cont’d)
Starting from previous state, suppose P1 requests (1,0,2). Should this be granted?
<P1>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
3 3 2
*3 2
2 0
0 0
![Page 79: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/79.jpg)
3.79GMU – CS 571
Bankers Algorithm (cont’d)
P1 requests (1,0,2). Should this be granted?
<P1,P3>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
5 3 2
*
*
![Page 80: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/80.jpg)
3.80GMU – CS 571
Bankers Algorithm (cont’d)
P1 requests (1,0,2). Should this be granted?
<P1,P3,P0>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
7 4 3
*
*
*
![Page 81: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/81.jpg)
3.81GMU – CS 571
Bankers Algorithm (cont’d)
P1 requests (1,0,2). Should this be granted?
<P1,P3,P0,P2>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
7 5 3
*
*
![Page 82: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/82.jpg)
3.82GMU – CS 571
Bankers Algorithm (cont’d)
P1 requests (1,0,2). Should this be granted?
<P1,P3,P0,P2,P4>
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
10 5 5
*
![Page 83: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/83.jpg)
3.83GMU – CS 571
Bankers Algorithm (cont’d)
Now, P4 requests (3,3,0). Should this be granted?
No – more than the available resources
Allocation
A B C
Max
A B C
Need
A B C
P0 0 1 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
2 3 0
![Page 84: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/84.jpg)
3.84GMU – CS 571
Bankers Algorithm (cont’d)
Now, P0 requests (0,2,0). Should this be granted?
Allocation
A B C
Max
A B C
Need
A B C
P0 0 3 0 7 5 3 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
Available
2 1 0
![Page 85: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/85.jpg)
3.85 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Resource-Request Algorithm for Process Resource-Request Algorithm for Process PPi i
(Sec 7.5.3.2)(Sec 7.5.3.2)
Request = request vector for process Pi. If Requesti [j] = k then process Pi wants k instances of resource type Rj.
1. If Requesti Needi go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim.
2. If Requesti Available, go to step 3. Otherwise Pi must wait, since resources are not available.
3. Pretend to allocate requested resources to Pi by modifying the state as follows:
Available = Available – Request;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti; If safe the resources are allocated to Pi. If unsafe Pi must wait, and the old resource-allocation
state is restored
![Page 86: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/86.jpg)
3.86GMU – CS 571
Deadlock Detection and Recovery
Allow system to enter deadlock state
Detection algorithm• Single Instance (look for cycles in wait-for graph)
• Multiple instance (related to banker’s algorithm) Algorithm requires an order of O(m x n2) operations to detect whether the system is in deadlocked state.
Recovery scheme
![Page 87: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/87.jpg)
3.87 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Resource-Allocation Graph and Wait-for GraphResource-Allocation Graph and Wait-for Graph
Resource-Allocation Graph Corresponding wait-for graph
![Page 88: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/88.jpg)
3.88 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Detection-Algorithm UsageDetection-Algorithm Usage
When, and how often, to invoke depends on:
How often a deadlock is likely to occur?
How many processes will need to be rolled back?
one for each disjoint cycle
If detection algorithm is invoked arbitrarily, there may be many cycles in the resource graph and so we would not be able to tell which of the many deadlocked processes “caused” the deadlock.
![Page 89: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/89.jpg)
3.89 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Recovery from Deadlock: Process TerminationRecovery from Deadlock: Process Termination
Abort all deadlocked processes.
Abort one process at a time until the deadlock cycle is eliminated.
In which order should we choose to abort?
Priority of the process.
How long process has computed, and how much longer to completion.
Resources the process has used.
Resources process needs to complete.
How many processes will need to be terminated.
Is process interactive or batch?
![Page 90: CS 471 - Lecture 3 Process Synchronization & Deadlock Ch. 6 (6.1-6.7), 7 Fall 2009](https://reader038.vdocuments.net/reader038/viewer/2022110207/56649d215503460f949f721b/html5/thumbnails/90.jpg)
3.90 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition
Recovery from Deadlock: Resource PreemptionRecovery from Deadlock: Resource Preemption
Selecting a victim – minimize cost.
Rollback – return to some safe state, restart process for that state.
Starvation – same process may always be picked as victim, include number of rollbacks in cost factor.