Chapter 6: Synchronization

Tools

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Chapter 6: Synchronization Tools
Background
The Critical-Section Problem
Peterson’s Solution
Hardware Support for Synchronization
Mutex Locks
Semaphores
Monitors
Liveness
Evaluation

Operating System Concepts – 10th Edition 6.2 Silberschatz, Galvin and Gagne ©2018
 Objectives

Describe the critical-section problem and illustrate a race

condition
Illustrate hardware solutions to the critical-section problem
using memory barriers, compare-and-swap operations, and
atomic variables
Demonstrate how mutex locks, semaphores, monitors, and
condition variables can be used to solve the critical section
problem
Evaluate tools that solve the critical-section problem in low-.
Moderate-, and high-contention scenarios

Operating System Concepts – 10th Edition 6.3 Silberschatz, Galvin and Gagne ©2018
 Background
Processes can execute concurrently
May be interrupted at any time, partially completing
execution
Concurrent access to shared data may result in data
inconsistency
Maintaining data consistency requires mechanisms to ensure
the orderly execution of cooperating processes
Illustration of the problem:
Suppose that we wanted to provide a solution to the
consumer-producer problem that fills all the buffers. We can
do so by having an integer counter that keeps track of the
number of full buffers. Initially, counter is set to 0. It is
incremented by the producer after it produces a new buffer
and is decremented by the consumer after it consumes a
buffer.

Operating System Concepts – 10th Edition 6.4 Silberschatz, Galvin and Gagne ©2018
 Producer

while (true) {
/* produce an item in next produced */

while (counter == BUFFER_SIZE)

; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}

Operating System Concepts – 10th Edition 6.5 Silberschatz, Galvin and Gagne ©2018
 Consumer

while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}

Operating System Concepts – 10th Edition 6.6 Silberschatz, Galvin and Gagne ©2018
 Race Condition

counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2

Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}

Operating System Concepts – 10th Edition 6.7 Silberschatz, Galvin and Gagne ©2018
 Race Condition
Processes P0 and P1 are creating child processs using the fork() system
call
Race condition on kernel variable next_available_pid which represents
the next available process identifier (pid)

Unless there is mutual exclusion, the same pid could be assigned to two
different processes!

Operating System Concepts – 10th Edition 6.8 Silberschatz, Galvin and Gagne ©2018
 Critical Section Problem
Consider system of n processes {p0, p1, … pn-1}
Each process has critical section segment of code
Process may be changing common variables, updating
table, writing file, etc
When one process in critical section, no other may be in its
critical section
Critical section problem is to design protocol to solve this
Each process must ask permission to enter critical section in
entry section, may follow critical section with exit section,
then remainder section

Operating System Concepts – 10th Edition 6.9 Silberschatz, Galvin and Gagne ©2018
 Critical Section

General structure of process Pi

Operating System Concepts – 10th Edition 6.10 Silberschatz, Galvin and Gagne ©2018
 Solution to Critical-Section Problem
1. Mutual Exclusion - If process Pi is executing in its critical
section, then no other processes can be executing in their
critical sections
2. Progress - If no process is executing in its critical section and
there exist some processes that wish to enter their critical
section, then the selection of the processes that will enter the
critical section next cannot be postponed indefinitely
3. Bounded Waiting - A bound must exist on the number of
times that other processes are allowed to enter their critical
sections after a process has made a request to enter its critical
section and before that request is granted
 Assume that each process executes at a nonzero speed
 No assumption concerning relative speed of the n
processes

Operating System Concepts – 10th Edition 6.11 Silberschatz, Galvin and Gagne ©2018
 Critical-Section Handling in OS
Two approaches depending on if kernel is preemptive or non-
preemptive
Preemptive – allows preemption of process when running
in kernel mode
Non-preemptive – runs until exits kernel mode, blocks, or
voluntarily yields CPU
Essentially free of race conditions in kernel mode

Operating System Concepts – 10th Edition 6.12 Silberschatz, Galvin and Gagne ©2018
 Peterson’s Solution
Not guaranteed to work on modern architectures! (But good
algorithmic description of solving the problem)
Two process solution
Assume that the load and store machine-language
instructions are atomic; that is, cannot be interrupted
The two processes share two variables:
int turn;
boolean flag[2]

The variable turn indicates whose turn it is to enter the critical

section
The flag array is used to indicate if a process is ready to enter
the critical section. flag[i] = true implies that process Pi is
ready!

Operating System Concepts – 10th Edition 6.13 Silberschatz, Galvin and Gagne ©2018
 Algorithm for Process Pi

while (true){
flag[i] = true;
turn = j;
while (flag[j] && turn = = j)
;

/* critical section */

flag[i] = false;

/* remainder section */

Operating System Concepts – 10th Edition 6.14 Silberschatz, Galvin and Gagne ©2018
 Peterson’s Solution (Cont.)
Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met

Operating System Concepts – 10th Edition 6.15 Silberschatz, Galvin and Gagne ©2018
 Peterson’s Solution
Although useful for demonstrating an algorithm, Peterson’s Solution is not
guaranteed to work on modern architectures.
Understanding why it will not work is also useful for better understanding
race conditions.
To improve performance, processors and/or compilers may reorder
operations that have no dependencies.
For single-threaded this is ok as the result will always be the same.
For multithreaded the reordering may produce inconsistent or unexpected
results!

Operating System Concepts – 10th Edition 6.16 Silberschatz, Galvin and Gagne ©2018
 Peterson’s Solution
Two threads share the data:

boolean flag = false;

int x = 0;
Thread 1 performs

while (!flag)
;
print x
Thread 2 performs

x = 100;
flag = true

What is the expected output?

Operating System Concepts – 10th Edition 6.17 Silberschatz, Galvin and Gagne ©2018
 Peterson’s Solution
100 is the expected output.
However, the operations for Thread 2 may be reordered:

flag = true;
x = 100;
If this occurs, the output may be 0!
The effects of instruction reordering in Peterson’s Solution

This allows both processes to be in their critical section at the same time!

Operating System Concepts – 10th Edition 6.18 Silberschatz, Galvin and Gagne ©2018
 Synchronization Hardware
Many systems provide hardware support for implementing the
critical section code.
Uniprocessors – could disable interrupts
Currently running code would execute without preemption
Generally too inefficient on multiprocessor systems
Operating systems using this not broadly scalable


We will look at three forms of hardware support:

1. Memory barriers

2. Hardware instructions

3. Atomic variables

Operating System Concepts – 10th Edition 6.19 Silberschatz, Galvin and Gagne ©2018
 Memory Barriers
Memory model are the memory guarantees a computer architecture makes
to application programs.
Memory models may be either:

➢ Strongly ordered – where a memory modification of one processor is

immediately visible to all other processors.
➢ Weakly ordered – where a memory modification of one processor may not
be immediately visible to all other processors.

A memory barrier is an instruction that forces any change in memory to be

propagated (made visible) to all other processors.

Operating System Concepts – 10th Edition 6.20 Silberschatz, Galvin and Gagne ©2018
 Memory Barrier
We could add a memory barrier to the following instructions to ensure
Thread 1 outputs 100:
Thread 1 now performs

while (!flag)
memory_barrier();
print x
Thread 2 now performs

x = 100;
memory_barrier();
flag = true

Operating System Concepts – 10th Edition 6.21 Silberschatz, Galvin and Gagne ©2018
 Hardware Instructions
Special hardware instructions that allow us to either test-and-modify the
content of a word, or two swap the contents of two words atomically
(uninterruptibly.)
Test-and-Set instruction
Compare-and-Swap instruction

Operating System Concepts – 10th Edition 6.22 Silberschatz, Galvin and Gagne ©2018
 test_and_set Instruction
Definition:
boolean test_and_set (boolean *target)
{
boolean rv = *target;
*target = true;
return rv:
}
1. Executed atomically
2. Returns the original value of passed parameter
3. Set the new value of passed parameter to true

Operating System Concepts – 10th Edition 6.23 Silberschatz, Galvin and Gagne ©2018
 Solution using test_and_set()

Shared boolean variable lock, initialized to false

Solution:
do {
while (test_and_set(&lock))
; /* do nothing */

/* critical section */

lock = false;
/* remainder section */
} while (true);

Operating System Concepts – 10th Edition 6.24 Silberschatz, Galvin and Gagne ©2018
 compare_and_swap Instruction
Definition:
int compare _and_swap(int *value, int expected, int new_value) {
int temp = *value;

if (*value == expected)
*value = new_value;
return temp;
}
1. Executed atomically
2. Returns the original value of passed parameter value
3. Set the variable value the value of the passed parameter new_value
but only if *value == expected is true. That is, the swap takes place
only under this condition.

Operating System Concepts – 10th Edition 6.25 Silberschatz, Galvin and Gagne ©2018
 Solution using compare_and_swap
Shared integer lock initialized to 0;
Solution:
while (true){
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */

/* critical section */

lock = 0;

/* remainder section */
}

Operating System Concepts – 10th Edition 6.26 Silberschatz, Galvin and Gagne ©2018
 Bounded-waiting Mutual Exclusion
with compare-and-swap

while (true) {
waiting[i] = true;
key = 1;
while (waiting[i] && key == 1)
key = compare_and_swap(&lock,0,1);
waiting[i] = false;
/* critical section */
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = 0;
else
waiting[j] = false;
/* remainder section */
}

Operating System Concepts – 10th Edition 6.27 Silberschatz, Galvin and Gagne ©2018
 Atomic Variables
Typically, instructions such as compare-and-swap are used as building
blocks for other synchronization tools.
One tool is an atomic variable that provides atomic (uninterruptible)
updates on basic data types such as integers and booleans.
For example, the increment() operation on the atomic variable
sequence ensures sequence is incremented without interruption:

increment(&sequence);

Operating System Concepts – 10th Edition 6.28 Silberschatz, Galvin and Gagne ©2018
 Atomic Variables
The increment() function can be implemented as follows:

void increment(atomic_int *v)

{
int temp;

do {
temp = *v;
}
while (temp != (compare_and_swap(v,temp,temp+1));
}

Operating System Concepts – 10th Edition 6.29 Silberschatz, Galvin and Gagne ©2018
 Mutex Locks
Previous solutions are complicated and generally inaccessible
to application programmers
OS designers build software tools to solve critical section
problem
Simplest is mutex lock
Protect a critical section by first acquire() a lock then
release() the lock
Boolean variable indicating if lock is available or not
Calls to acquire() and release() must be atomic
Usually implemented via hardware atomic instructions
such as compare-and-swap.

But this solution requires busy waiting

This lock therefore called a spinlock

Operating System Concepts – 10th Edition 6.30 Silberschatz, Galvin and Gagne ©2018
 Solution to Critical-section Problem Using Locks

while (true) {
acquire lock

critical section

release lock

remainder section
}

Operating System Concepts – 10th Edition 6.31 Silberschatz, Galvin and Gagne ©2018
 Mutex Lock Definitions
acquire() {
while (!available)
; /* busy wait */
available = false;;
}

release() {
available = true;
}

These two functions must be implemented atomically.

Both test-and-set and compare-and-swap can be
used to implement these functions.

Operating System Concepts – 10th Edition 6.32 Silberschatz, Galvin and Gagne ©2018
 Semaphore
Synchronization tool that provides more sophisticated ways (than Mutex locks)
for process to synchronize their activities.
Semaphore S – integer variable
Can only be accessed via two indivisible (atomic) operations
wait() and signal()
 (Originally called P() and V())
Definition of the wait() operation
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
Definition of the signal() operation
signal(S) {
S++;
}

Operating System Concepts – 10th Edition 6.33 Silberschatz, Galvin and Gagne ©2018
 Semaphore Usage
Counting semaphore – integer value can range over an unrestricted
domain
Binary semaphore – integer value can range only between 0 and 1
Same as a mutex lock
Can solve various synchronization problems
Consider P1 and P2 that require S1 to happen before S2
Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
Can implement a counting semaphore S as a binary semaphore

Operating System Concepts – 10th Edition 6.34 Silberschatz, Galvin and Gagne ©2018
 Semaphore Implementation
Must guarantee that no two processes can execute the wait()
and signal() on the same semaphore at the same time
Thus, the implementation becomes the critical section problem
where the wait and signal code are placed in the critical
section
Could now have busy waiting in critical section
implementation
 But implementation code is short
 Little busy waiting if critical section rarely occupied
Note that applications may spend lots of time in critical sections
and therefore this is not a good solution

Operating System Concepts – 10th Edition 6.35 Silberschatz, Galvin and Gagne ©2018
 Semaphore Implementation with no Busy waiting

With each semaphore there is an associated waiting queue

Each entry in a waiting queue has two data items:
value (of type integer)
pointer to next record in the list
Two operations:
block – place the process invoking the operation on the
appropriate waiting queue
wakeup – remove one of processes in the waiting queue
and place it in the ready queue
typedef struct {
int value;
struct process *list;
} semaphore;

Operating System Concepts – 10th Edition 6.36 Silberschatz, Galvin and Gagne ©2018
 Implementation with no Busy waiting (Cont.)

wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}

Operating System Concepts – 10th Edition 6.37 Silberschatz, Galvin and Gagne ©2018
 Problems with Semaphores

Incorrect use of semaphore operations:

signal (mutex) …. wait (mutex)

wait (mutex) … wait (mutex)

Omitting of wait (mutex) and/or signal (mutex)

These – and others – are examples of what can occur when

sempahores and other synchronization tools are used
incorrectly.

Operating System Concepts – 10th Edition 6.38 Silberschatz, Galvin and Gagne ©2018
 Monitors
A high-level abstraction that provides a convenient and effective
mechanism for process synchronization
Abstract data type, internal variables only accessible by code within the
procedure
Only one process may be active within the monitor at a time
Pseudocode syntax of a monitor:

monitor monitor-name
{
// shared variable declarations
function P1 (…) { …. }

function P2 (…) { …. }

function Pn (…) {……}

initialization code (…) { … }

}

Operating System Concepts – 10th Edition 6.39 Silberschatz, Galvin and Gagne ©2018
 Schematic view of a Monitor

Operating System Concepts – 10th Edition 6.40 Silberschatz, Galvin and Gagne ©2018
 Condition Variables

condition x, y;
Two operations are allowed on a condition variable:
x.wait() – a process that invokes the operation is
suspended until x.signal()
x.signal() – resumes one of processes (if any) that
invoked x.wait()
 If no x.wait() on the variable, then it has no effect on
the variable

Operating System Concepts – 10th Edition 6.41 Silberschatz, Galvin and Gagne ©2018
 Monitor with Condition Variables

Operating System Concepts – 10th Edition 6.42 Silberschatz, Galvin and Gagne ©2018
 Condition Variables Choices
If process P invokes x.signal(), and process Q is suspended in
x.wait(), what should happen next?
Both Q and P cannot execute in paralel. If Q is resumed, then P
must wait
Options include
Signal and wait – P waits until Q either leaves the monitor or it
waits for another condition
Signal and continue – Q waits until P either leaves the monitor or it
waits for another condition
Both have pros and cons – language implementer can decide
Monitors implemented in Concurrent Pascal compromise
 P executing signal immediately leaves the monitor, Q is
resumed
Implemented in other languages including Mesa, C#, Java

Operating System Concepts – 10th Edition 6.43 Silberschatz, Galvin and Gagne ©2018
 Monitor Implementation Using Semaphores

Variables

semaphore mutex; // (initially = 1)

semaphore next; // (initially = 0)
int next_count = 0;

Each function F will be replaced by

wait(mutex);
…
body of F;
…
if (next_count > 0)
signal(next)
else
signal(mutex);

Mutual exclusion within a monitor is ensured

Operating System Concepts – 10th Edition 6.44 Silberschatz, Galvin and Gagne ©2018
 Monitor Implementation – Condition Variables

For each condition variable x, we have:

semaphore x_sem; // (initially = 0)

int x_count = 0;

The operation x.wait() can be implemented as:

x_count++;
if (next_count > 0)
signal(next);
else
signal(mutex);
wait(x_sem);
x_count--;

Operating System Concepts – 10th Edition 6.45 Silberschatz, Galvin and Gagne ©2018
 Monitor Implementation (Cont.)

The operation x.signal() can be implemented as:

if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}

Operating System Concepts – 10th Edition 6.46 Silberschatz, Galvin and Gagne ©2018
 Resuming Processes within a Monitor

If several processes queued on condition variable x, and

x.signal() is executed, which process should be
resumed?
FCFS frequently not adequate
conditional-wait construct of the form x.wait(c)
Where c is priority number
Process with lowest number (highest priority) is
scheduled next

Operating System Concepts – 10th Edition 6.47 Silberschatz, Galvin and Gagne ©2018
 Single Resource allocation
Allocate a single resource among competing processes using
priority numbers that specify the maximum time a process
plans to use the resource

R.acquire(t);
...
access the resurce;
...

R.release;

Where R is an instance of type ResourceAllocator

Operating System Concepts – 10th Edition 6.48 Silberschatz, Galvin and Gagne ©2018
 A Monitor to Allocate Single Resource
monitor ResourceAllocator
{
boolean busy;
condition x;
void acquire(int time) {
if (busy)
x.wait(time);
busy = true;
}
void release() {
busy = FALSE;
x.signal();
}
initialization code() {
busy = false;
}
}

Operating System Concepts – 10th Edition 6.49 Silberschatz, Galvin and Gagne ©2018
 Liveness
Processes may have to wait indefinitely while trying to acquire a
synchronization tool such as a mutex lock or semaphore.
Waiting indefinitely violates the progress and bounded-waiting criteria
discussed at the beginning of this chapter.
Liveness refers to a set of properties that a system must satisfy to ensure
processes make progress.
Indefinite waiting is an example of a liveness failure.

Operating System Concepts – 10th Edition 6.50 Silberschatz, Galvin and Gagne ©2018
 Liveness
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);
... ...
signal(S); signal(Q);
signal(Q); signal(S);

Consider if P0 executes wait(S) and P1 wait(Q). When P0 executes

wait(Q), it must wait until P1 executes signal(Q)
However, P1 is waiting until P0 execute signal(S).
Since these signal() operations will never be executed, P0 and P1 are
deadlocked.

Operating System Concepts – 10th Edition 6.51 Silberschatz, Galvin and Gagne ©2018
 Liveness
Other forms of deadlock:
Starvation – indefinite blocking
A process may never be removed from the semaphore queue in which it is
suspended
Priority Inversion – Scheduling problem when lower-priority process
holds a lock needed by higher-priority process
Solved via priority-inheritance protocol

Operating System Concepts – 10th Edition 6.52 Silberschatz, Galvin and Gagne ©2018
 Priority Inheritance Protocol
Consider the scenario with three processes P1, P2, and P3. P1 has
the highest priority, P2 the next highest, and P3 the lowest. Assume a
resouce P3 is assigned a resource R that P1 wants. Thus, P1 must
wait for P3 to finish using the resource. However, P2 becomes
runnable and preempts P3. What has happened is that P2 - a process
with a lower priority than P1 - has indirectly prevented P3 from gaining
access to the resource.

To prevent this from occurring, a priority inheritance protocol is

used. This simply allows the priority of the highest thread waiting to
access a shared resource to be assigned to the thread currently using
the resource. Thus, the current owner of the resource is assigned the
priority of the highest priority thread wishing to acquire the resource.

Operating System Concepts – 10th Edition 6.53 Silberschatz, Galvin and Gagne ©2018
 End of Chapter 6

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
OPERATING SYSTEMS

DEADLOCKS

Jerry Breecher

7: Deadlocks 1
 OPERATING SYSTEM
Deadlocks
What Is In This Chapter?
• What is a deadlock?

• Staying Safe: Preventing and Avoiding Deadlocks

• Living Dangerously: Let the deadlock happen, then

detect it and recover from it.

7: Deadlocks 2
 DEADLOCKS
EXAMPLES:

• "It takes money to make money".

• You can't get a job without experience; you can't get experience without a
job.

BACKGROUND:

The cause of deadlocks: Each process needing what another process has. This
results from sharing resources such as memory, devices, links.

Under normal operation, a resource allocations proceed like this::

1. Request a resource (suspend until available if necessary ).

2. Use the resource.
3. Release the resource.
7: Deadlocks 3
 DEADLOCKS Bridge Crossing
Example

• Traffic only in one direction.

• Each section of a bridge can be viewed as a resource.
• If a deadlock occurs, it can be resolved if one car backs up (preempt
resources and rollback).
• Several cars may have to be backed up if a deadlock occurs.
• Starvation is possible.

7: Deadlocks 4
 DEADLOCKS DEADLOCK
CHARACTERISATION
NECESSARY CONDITIONS
ALL of these four must happen simultaneously for a deadlock to occur:

Mutual exclusion
One or more than one resource must be held by a process in a non-sharable
(exclusive) mode.

Hold and Wait

A process holds a resource while waiting for another resource.

No Preemption
There is only voluntary release of a resource - nobody else can make a process
give up a resource.

Circular Wait
Process A waits for Process B waits for Process C .... waits for Process A.
7: Deadlocks 5
 DEADLOCKS RESOURCE
ALLOCATION GRAPH
A visual ( mathematical ) way to determine if a deadlock has, or may occur.

G = ( V, E ) The graph contains nodes and edges.

V Nodes consist of processes = { P1, P2, P3, ...} and resource types
{ R1, R2, ...}

E Edges are ( Pi, Rj ) or ( Ri, Pj )

An arrow from the process to resource indicates the process is requesting the
resource. An arrow from resource to process shows an instance of the resource
has been allocated to the process.

Process is a circle, resource type is square; dots represent number of instances of

resource in type. Request points to square, assignment comes from dot.
Pi Pi
Pi
7: Deadlocks Rj Rj 6
 DEADLOCKS RESOURCE
ALLOCATION GRAPH
• If the graph contains no cycles, then no process is deadlocked.
• If there is a cycle, then:
a) If resource types have multiple instances, then deadlock MAY exist.
b) If each resource type has 1 instance, then deadlock has occurred.

R3 Assigned to P3

Resource allocation graph

P2 Requests P3

7: Deadlocks 7
 DEADLOCKS RESOURCE
ALLOCATION GRAPH

Resource allocation graph

Resource allocation graph with a cycle but no deadlock.
with a deadlock.

7: Deadlocks 8
 DEADLOCKS Strategy
HOW TO HANDLE DEADLOCKS – GENERAL STRATEGIES

There are three methods:

Ignore Deadlocks: Most Operating systems do this!!

Ensure deadlock never occurs using either

Prevention Prevent any one of the 4 conditions from happening.

Avoidance Allow all deadlock conditions, but calculate cycles about to

happen and stop dangerous operations..

Allow deadlock to happen. This requires using both:

Detection Know a deadlock has occurred.

Recovery Regain the resources.

7: Deadlocks 9
 DEADLOCKS Deadlock
Prevention

Do not allow one of the four conditions to occur.

Mutual exclusion:
a) Automatically holds for printers and other non-sharables.
b) Shared entities (read only files) don't need mutual exclusion (and aren’t
susceptible to deadlock.)
c) Prevention not possible, since some devices are intrinsically non-sharable.

Hold and wait:

a) Collect all resources before execution.
b) A particular resource can only be requested when no others are being
held. A sequence of resources is always collected beginning with the
same one.
c) Utilization is low, starvation possible.

7: Deadlocks 10
 DEADLOCKS Deadlock
Prevention

Do not allow one of the four conditions to occur.

No preemption:

a) Release any resource already being held if the process can't get an
additional resource.
b) Allow preemption - if a needed resource is held by another process, which
is also waiting on some resource, steal it. Otherwise wait.

Circular wait:

a) Number resources and only request in ascending order.

b) EACH of these prevention techniques may cause a decrease in utilization
and/or resources. For this reason, prevention isn't necessarily the best
technique.
c) Prevention is generally the easiest to implement.
7: Deadlocks 11
 DEADLOCKS Deadlock
Avoidance
If we have prior knowledge of how resources will be requested, it's possible to
determine if we are entering an "unsafe" state.

Possible states are:

Deadlock No forward progress can be made.

Unsafe state A state that may allow deadlock.

Safe state A state is safe if a sequence of processes exist such that there
are enough resources for the first to finish, and as each finishes
and releases its resources there are enough for the next to finish.

The rule is simple: If a request allocation would cause an unsafe state, do not honor
that request.

NOTE: All deadlocks are unsafe, but all unsafes are NOT deadlocks.
7: Deadlocks 12
 DEADLOCKS Deadlock
Avoidance

NOTE: All deadlocks are unsafe, but all unsafes are NOT deadlocks.

UNSAFE
SAFE
DEADLOCK

Only with luck will O.S. can avoid

processes avoid deadlock.
deadlock.

7: Deadlocks 13
 DEADLOCKS Deadlock
Avoidance
Let's assume a very simple model: each process declares its maximum
needs. In this case, algorithms exist that will ensure that no unsafe state is
reached.
There are multiple instances of
the resource in these examples.
EXAMPLE:
There exists a total of 12 tape drives. The current state looks like this:
Process Max Needs Allocated Current
Needs

P0 10 5 5
In this example, < p1, p0, p2 >
is a workable sequence. P1 4 2 2

Suppose p2 requests and is P2 9 2 7

given one more tape drive.
What happens then?

7: Deadlocks 14
 Deadlock
DEADLOCKS
Avoidance
Safety Algorithm
A method used to determine if a particular state is safe. It's safe if there exists a
sequence of processes such that for all the processes, there’s a way to avoid
deadlock:

The algorithm uses these variables:

Need[I] – the remaining resource needs of each process.

Work - Temporary variable – how many of the resource are currently
available.
Finish[I] – flag for each process showing we’ve analyzed that process or not.

need <= available + allocated[0] + .. + allocated[I-1] <- Sign of success

Let work and finish be vectors of length m and n respectively.

7: Deadlocks 15
 DEADLOCKS Deadlock
Avoidance
Safety Algorithm
1. Initialize work = available
Initialize finish[i] = false, for i = 1,2,3,..n

2. Find an i such that:

finish[i] == false and need[i] <= work

If no such i exists, go to step 4.

3. work = work + allocation[i]

finish[i] = true
goto step 2

4. if finish[i] == true for all i, then the system is in a safe state.

7: Deadlocks 16
 DEADLOCKS Deadlock
Safety Algorithm Avoidance
Do these examples:
Consider a system with: five processes, P0 P4, three resource types, A, B, C.
Type A has 10 instances, B has 5 instances, C has 7 instances.
At time T0 the following snapshot of the system is taken.
Max Needs = allocated + can-be-requested

Alloc Req Avail

Is the system A B C A B C A B C
in a safe state? P0 0 1 0 7 4 3 3 3 2
P1 2 0 0 0 2 0
P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
P4 0 0 2 4 3 1

7: Deadlocks 17
 DEADLOCKS Deadlock
Safety Algorithm
Avoidance
Do these examples:
Now try it again with only a slight change in the request by P1.
P1 requests one additional resource of type A, and two more of type C.
Request1 = (1,0,2).
Is Request1 < available?
Alloc Req Avail
Produce the state
chart as if the A B C A B C A B C
request is Granted P0 0 1 0 7 4 3 1# 3 0#
and see if it’s safe.
(We’ve drawn the P1 3# 0 2# 0 2 0
chart as if it’s
granted. P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
Can the request P4 0 0 2 4 3 1
be granted?

7: Deadlocks 18
 DEADLOCKS Deadlock Detection
Need an algorithm that determines SINGLE INSTANCE OF A RESOURCE TYPE
if deadlock occurred.
• Wait-for graph == remove the resources
Also need a means of recovering from the usual graph and collapse edges.
from that deadlock. • An edge from p(j) to p(i) implies that p(j) is
waiting for p(i) to release.

7: Deadlocks 19
 DEADLOCKS Deadlock Detection

SEVERAL INSTANCES OF A RESOURCE TYPE

Complexity is of order m * n * n.

We need to keep track of:

available - records how many resources of each type are available.

allocation - number of resources of type m allocated to process n.
request - number of resources of type m requested by process n.

Let work and finish be vectors of length m and n respectively.

7: Deadlocks 20
 DEADLOCKS Deadlock Detection

1. Initialize work[] = available[]

For i = 1,2,...n, if allocation[i] != 0 then
finish[i] = false; otherwise, finish[i] = true;

2. Find an i such that:

finish[i] == false and request[i] <= work

If no such i exists, go to step 4.

3. work = work + allocation[i]

finish[i] = true
goto step 2

4. if finish[i] == false for some i, then the system is in deadlock state.

IF finish[i] == false, then process p[i] is deadlocked.

7: Deadlocks 21
 DEADLOCKS Deadlock Detection

EXAMPLE
We have three resources, A, B, and C. A has 7 instances, B has 2 instances, and C has 6
instances. At this time, the allocation, etc. looks like this:

Is there a Alloc Req Avail

sequence that will A B C A B C A B C
allow deadlock to
be avoided? P0 0 1 0 0 0 0 0 0 0
Is there more than P1 2 0 0 2 0 2
one sequence that P2 3 0 3 0 0 0
will work?
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2

7: Deadlocks 22
 DEADLOCKS Deadlock Detection

EXAMPLE
Suppose the Request matrix is changed like this. In other words, the maximum amounts to be
allocated are initially declared so that this request matrix results.

Is there now a
sequence that will Alloc Req Avail
allow deadlock to be
avoided?
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0
USAGE OF THIS P1 2 0 0 2 0 2
DETECTION ALGORITHM P2 3 0 3 0 0 1#
Frequency of check P3 2 1 1 1 0 0
depends on how often a
deadlock occurs and how P4 0 0 2 0 0 2
many processes will be
affected.

7: Deadlocks 23
 DEADLOCKS Deadlock Recovery

So, the deadlock has occurred. Now, how do we get the resources back and gain forward
progress?

PROCESS TERMINATION:

• Could delete all the processes in the deadlock -- this is expensive.

• Delete one at a time until deadlock is broken ( time consuming ).
• Select who to terminate based on priority, time executed, time to completion, needs
for completion, or depth of rollback
• In general, it's easier to preempt the resource, than to terminate the process.

RESOURCE PREEMPTION:

• Select a victim - which process and which resource to preempt.

• Rollback to previously defined "safe" state.
• Prevent one process from always being the one preempted ( starvation ).

7: Deadlocks 24
 DEADLOCKS Deadlock Recovery

COMBINED APPROACH TO DEADLOCK HANDLING:

• Type of resource may dictate best deadlock handling. Look at ease of implementation, and
effect on performance.

• In other words, there is no one best technique.

• Cases include:

Preemption for memory,

Preallocation for swap space,

Avoidance for devices ( can extract Needs from process. )

7: Deadlocks 25
 DEADLOCKS
WRAPUP

In this section we have:

Looked at necessary conditions for a deadlock to occur.

Determined how to prevent, avoid, detect and recover from deadlocks.

7: Deadlocks 26