UNIT-3 2015 Regulation Process Synchronization and Deadlocks
UNIT-3 2015 Regulation Process Synchronization and Deadlocks
How to solve
To avoid such situations process synchronisation
is used, so another concurrent process P2 is
notified of existing concurrent process P1 and not
allowed to go through as there is P1 process which
is running and P2 execution is only allowed once P1
completes.
Race
Condition
Process synchronization : Background
Concurrent access to shared data may result in data inconsistency.
Maintaining data consistency requires mechanisms to ensure the orderly
execution of co-operating processes.
Example:
Producer consumer problem (also called as bounded buffer problem)
Producer:
The producer ’s job is to generate a piece of data, put into the buffer and start
again.
Consumer:
The consumer is consuming the data (removing it from the buffer) one piece
at a time.
Conflict:
The problem is to make sure that the producer won’t try to add data into the
buffer if it’s full and that the consumer won’t try to remove data from an
empty buffer.
Solution:
Producer:
The next item the consumer removes an item from the buffer and it notifies the producer who
The next time the producer puts data into buffer, it wakes up the sleeping consumer.
Producer: Consumer:
PRODUCER
while (true) {
/* produce an item in next produced */
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
RACE CONDITION
register1 = counter
register1 = register1 + 1
counter = register1
counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
Each process has a code segment, called critical section , in which the shared data is accessed.
Problem − ensure that when one process is executing in its critical section, no other process is
do {
flag[i] = true;
turn = j;
while (flag[j] && turn = = j);
critical section
flag[i] = false;
remainder section
} while (true);
SYNCHRONIZATION HARDWARE
Deadlocks
System model
Deadlock characterization
Methods for handling deadlocks
Deadlock prevention
Deadlock avoidance
Deadlock detection
Recovery from deadlocks
DEADLOCKS:
If the resources are not available at that time, the process enters a waiting state.
Sometimes, a waiting process is never again able to change state, because the resources it has requested are held by other
The resources may be partitioned into several types (or classes), each consisting of some number of identical instances.
If a process requests an instance of a resource type, the allocation of any instance of the type should satisfy the request.
If it does not, then the instances are not identical, and the resource type classes have not been defined properly.
OPERATING SYSTEMS (2015R REGULATION)
OPERATING SYSTEMS (2015R REGULATION)
The request and release of semaphores can be accomplished through the wait() and signal() operations on
semaphores or through acquire() and release() of a mutex lock.
OPERATING SYSTEMS (2015R REGULATION)
Deadlock Characterization:
A deadlock situation can arise if the following four conditions hold resources simultaneously in a system:
1. Mutual exclusion:
Only one process at a time can use the resource.
If another process requests that resource, the requesting process must be delayed until the resource has
been released.
2. Hold and wait:
A process must be holding at least one resource and waiting to acquire additional resources that are
currently being held by other processes.
3. No preemption:
Resources cannot be preempted; that is, a resource can be released only voluntarily by the process holding
it, after that process has completed its task.
4. Circular wait:
A set {P0, P1, ..., Pn} of waiting processes must exist such that P0 is waiting for a resource held by P1, P1
is waiting for a resource held by P2, ..., Pn−1 is waiting for a resource held by Pn, and Pn is waiting for a
resource held by P0.
OPERATING SYSTEMS (2015R REGULATION)
1- Deadlock prevention:
Provides a set of methods to ensure that at least one of the necessary conditions cannot hold.
These methods prevent deadlocks by constraining how requests for resources can be made.
2- Deadlock avoidance :
Deadlock avoidance requires that the operating system be given additional information in advance
concerning which resources a process will request and use during its lifetime.
All the pending processes can be successfully executed in some sequences and also satisfying their
resource requirement completely. this sequences is called safe sequences and system in safe state.
OPERATING SYSTEMS (2015R REGULATION)
3-Deadlock detection:
If a system does not employ either a deadlock-prevention or a deadlock avoidance algorithm, then a
deadlock situation may occur.
In this environment, the system may provide:
An algorithm that examines the state of the system to determine whether a deadlock has occurred and to
recover from the deadlock.
4-Deadlock Recovery:
Let the deadlock occur in the system and then try to recover the system from deadlock.
Deadlock prevention:
To prevent the system from deadlock one of the four condition should be discarded.
1- Mutual Exclusion:
We cannot prevent deadlock by denying mutual exclusion because, we do not have system with all
resources being sharable (or) non sharable.
Example:
Read-only files are a good example of a sharable resource.
A process never needs to wait for a sharable resource.
OPERATING SYSTEMS (2015R REGULATION)
3- No Preemption:
If process is holding some resources and request another resources that cannot be allocated to it.
Operating system check other resources are used (or) unused by another process, if it is unused means the
operating system preempts resources and requested process restarted again old as well as new request
resources.
4- Circular wait:
Each process can only request resources in an increasing order of priority and it must have release all
resources.
OPERATING SYSTEMS (2015R REGULATION)
Deadlock Avoidance:
Deadlock avoidance requires that the operating system be given additional information in advance
concerning which resources a process will request and use during its lifetime.
The system must able to decide whether granting a resource is safe (or) not and will only make the
allocation when it is safe.
Deadlock Avoidance
Resource-Allocation Graph:
Deadlocks can be described more precisely in terms of a directed graph called a system resource-allocation
graph.
This graph consists:
1.set of vertices V
2.set of edges E
The set of vertices V is partitioned into two different types of nodes:
P = {P1, P2, ..., Pn}, the set consisting of all the active processes in the system.
R = {R1, R2, ..., Rm}, the set consisting of all resource types in the system.
In a graph:
Process representing as circle.
Resources representing as square.
Dot within the square represents the number of instances.
OPERATING SYSTEMS (2015R REGULATION)
Banker’s Algorithm:
When a new process enters the system, it declares the maximum number of instances that are needed.
This number cannot exceed the total number of resources in the system.
If the process can be accommodated based upon the needs of the system, then resources are allocated,
otherwise the process must wait.
Before Pi starts executing, it must declare the maximum number of instances of each resource type
that it may need.
OPERATING SYSTEMS (2015R REGULATION)
Step 1:
Available : Vector of length m
Available [ j ] = k
[k is number of instances of the resource type R j ]
Step 2:
Max : n x m matrix
Max [ i , j ] = k
[Process Pi request at maximum number of k instances of resource type R j for its completion]
Step 3:
Allocation : n x m matrix
Allocation [ i , j ] = k
[ k number of instances of resource type R j is currently allocated to process pi ]
Step 4:
Need : n x m matrix
Need [ i , j ] = k
[ k number of instances of resource type R j will be required by process Pi to complete its job]
Need [ i , j ] = Max [ i , j ] – Allocation [ i , j ]
OPERATING SYSTEMS (2015R REGULATION)
Safety algorithm
The safety algorithm is used to determine if a system is in a safe state
Let,
Work : vectors of length m
Finish: vectors of length n
Step 1:
Work =Available;
Finish [ i ] = false;
for all i=0,1,2,……..n;
Step 2:
Find i such that
Finish [ i ] == false;
Need [ i ] <= work;
If no such i exists then the system is in unsafe state; return; go to step 4.
Step 3:
Work = Work + Allocation [ i ] ;
Finish [ i ] =true;
go to step 2.
Step 4:
Finish [ i ] == true for all i
the system is in a safe state;
This algorithm may require an order of m × n2 operations to determine whether a state is safe.
OPERATING SYSTEMS (2015R REGULATION)
Pretend to have allocated the requested resources to process P i by modifying the state as follows:
Available = Available–Requesti ;
Allocationi = Allocationi + Requesti ;
Needi = Needi –Requesti ;
If safe resource are allocated to Pi
If unsafe Pi must wait
OPERATING SYSTEMS (2015R REGULATION)
Safe state:
All the pending processes can be successfully executed in some sequences and also satisfying their
resource requirement completely.
This sequences is called safe sequences and system in safe state.
OPERATING SYSTEMS (2015R REGULATION)
Deadlock Recovery:
Resource Preemption:
To eliminate deadlocks using resource preemption , We successively preempt some resources
from processes and give these resources to other processes until the deadlock cycle is broken.
Rollback
We must roll back the process to some safe state and restart it from that state.
Starvation
Same process may always be picked as victim, Include number of rollback in cost factor. (
Ensure that a process can be picked as a victim only a (Small) finite number of times)