www.acharya.ac.

in

Process Synchronization
 Process Synchronization
• Process Synchronization is mainly needed in a multi-
process system when multiple processes are running
together
Dept. of BCA • More than one processes try to gain access to the
Click to Edit

same shared resource or any data at the same time.

 Race Condition
• When more than one process is either executing the
same code or accessing the same memory or any
shared variable;
• In that condition, there is a possibility that the output
Dept. of BCA
Click to Edit
or the value of the shared variable is wrong
• So for that purpose all the processes are doing the race
to say that my output is correct.
 • This condition is commonly known as a race
condition.
 Critical Condition
• As several processes access and process the
manipulations on the same data in a concurrent manner
Dept. of BCA
Click to Edit
• Due to which the outcome depends on the particular
order in which the access of data takes place.
• Mainly this condition is a situation that may occur
inside the critical section.
 • Race condition in the critical section happens when
the result of multiple thread execution differs
according to the order in which the threads execute.
• But this condition is critical sections can be avoided if
the critical section is treated as an atomic instruction.
Dept. of BCA
Click to Edit
• Proper thread synchronization using locks or atomic
variables can also prevent race conditions.
 • A Critical Section is a code segment that accesses
shared variables and has to be executed as an atomic
action.
• It means that in a group of cooperating processes, at a
given point of time, only one process must be
Dept. of BCA
Click to Edit
executing its critical section.
 • If any other process also wants to execute its critical
section, it must wait until the first one finishes.
• The entry to the critical section is mainly handled by
wait () function while the exit from the critical section
is controlled by the signal () function
Dept. of BCA
Click to Edit
Dept. of BCA
Click to Edit

1.Entry Section: In this section mainly the process requests for its
entry in the critical section.

2.Exit Section: This section is followed by the critical section.

  The Critical-Section Problem
The solution to the Critical Section Problem

•A solution to the critical section problem must satisfy the

following three conditions:
Mutual Exclusion: Out of a group of cooperating processes, only
Dept. of BCA
Click to Edit
one process can be in its critical section at a given point of time.
Progress: If no process is in its critical section, and if one or more
threads want to execute their critical section then any one of these
threads must be allowed to get into its critical section.
 •Bounded Waiting: After a process makes a request for getting
into its critical section,

There is a limit for how many other processes can get

into their critical section, before this process's request is
granted.
Dept. of BCA
Click to Edit •So, after the limit is reached, the system must grant the
process permission to get into its critical section.
 Peterson's Solution

• This is widely used and software-based solution to critical

section problems.

• Peterson's solution was developed by a computer scientist

Dept. of BCA
Click to Edit Peterson that's why it is named so.

• With the help of this solution whenever a process is

executing in any critical state, then the other process only

executes the rest of the code, and vice-versa can happen.

 • This method also helps to make sure of the thing that only a

single process can run in the critical section at a specific time.

•This solution preserves all three conditions:

Mutual Exclusion is comforted as at any time only one

process can access the critical section.
Dept. of BCA
Click to Edit Progress is also comforted, as a process that is outside the
critical section is unable to block other processes from
entering into the critical section.
 • Bounded Waiting is assured as every process gets a fair

chance to enter the Critical section.

Dept. of BCA
Click to Edit
 •The above shows the structure of process Pi in Peterson's
solution.
 Suppose there are N processes (P1, P2, ... PN) and as
at some point of time every process requires to enter
in the Critical Section
Dept. of BCA  A FLAG [] array of size N is maintained here which is
Click to Edit

by default false. Whenever a process requires to enter in

the critical section, it has to set its flag as true. Example:
If Pi wants to enter it will set FLAG[i]=TRUE.
  Another variable is called TURN and is used to
indicate the process number that is currently waiting
to enter into the critical section.
 The process that enters into the critical section while
exiting would change the TURN to another number
Dept. of BCA from the list of processes that are ready.
Click to Edit
 Example: If the turn is 3 then P3 enters the Critical
section and while exiting turn=4 and therefore P4 breaks
out of the wait loop.
  Synchronization Hardware
• Synchronization hardware is a hardware-based solution to

resolve the critical section problem.

Synchronize the processes sharing a common variable in
two ways.
Dept. of BCA
Click to Edit 1. Software-based solution which includes Peterson’s
solution
2. Hardware-based solution which is also referred to as
synchronization hardware or hardware synchronization.
  Hardware solutions are often easier and also
improves the efficiency of the system
• The hardware synchronization provides two
kinds of hardware instructions that are
Dept. of BCA
Click to Edit
TestAndSet and Swap.
• TestAndSet Hardware Instruction: The
TestAndSet() hardware instruction is atomic
instruction.
 • Atomic means both the test operation and set operation are
executed in one machine cycle at once.
• If the two different processes are executing TestAndSet()
simultaneously each on different CPU.
• Still, they will be executed sequentially in some random
Dept. of BCA order
Click to Edit

boolean test_and_set(boolean *target) {

boolean rv= *target;

target=true;

return rv; }
 • Now, as a solution to the critical section, how this
TestAndSet() instruction be implemented to achieve mutual
exclusion, bounded wait and progress.
• Let us do it one by one, first, we will try to achieve mutual
exclusion using TestAndSet() instruction and for that,
Dept. of BCA
Click to Edit • You have to globally declare a Boolean variable lock and
initialize it to false.
•Consider we have three processes P0, P1 and P2 are interested to enter their critical section. So the

structure for achieving mutual exclusion is as follow;

Dept. of BCA
Click to Edit
  MUTEX LOCKS
• A mutex lock makes it possible to implement
mutual exclusion by limiting the number of
threads or processes that can simultaneously

Click to Edit acquire the lock.

• A single thread or procedure has to first try

to obtain the mutex lock for something that
is shared before it can access it
 •The seeking string or procedure
gets halted and placed in a state of
waiting as long as the encryption
Click to Edit key turns into accessible
•If it is being organized by a
different thread or process.
 •The thread or process is able to use
the resource that has been shared
after acquiring the lock.

Click to Edit
• When finished, it introduces the
lock so that different threads or
processes can take possession of it..
 Types of Mutex Locks
• Mutex locks come in a variety of forms that
offer varying levels of capabilities and
behavior.
Click to Edit

• Below are a few different kinds of mutex

locks that are frequently used −
 Recursive Mutex
o A recursive mutex enables multiple lock
acquisitions without blocking an operating
system or procedure.
Click to Edit
o It keeps track of the number of occasions it was
previously purchased and needs the same
amount of discharges before it can be
completely unlocked.
 Error-Checking Mutex

oWhen lock processes, an error-checking

mutex executes further error checking.

Click to Edit
oBy hindering looping lock appropriation, it
makes a guarantee that an application or
procedure doesn't take over a mutex lock it
presently already holds.
 Times Mutex
o For a predetermined amount of time, an algorithm or
procedure can try to acquire a lock using a timed
mutex.
o The acquiring functioning fails if the security key
Click to Edit

fails to become accessible during the allotted time, as

well as if the thread/process can respond
appropriately.
 SEMAPHORES
• Semaphores are integer variables that
are used to solve the critical section

Click to Edit
problem
• By using two atomic operations, wait
and signal that are used for process
synchronization.
 The definitions of wait and signal are as follows
−

 Wait
The wait operation decrements the value of its argument S, if it is
positive. If S is negative or zero, then no operation is performed.
Click to Edit wait(S)
{
while (S<=0);

S--;
}
  Signal
The signal operation increments the value of its argument S.
signal(S)
{
S++;
}

Types of Semaphores
Click to Edit
• There are two main types of semaphores i.e. Counting
semaphores and Binary semaphores. Details about these are
given as follows −
  Counting Semaphores
• These are integer value semaphores and have an
unrestricted value domain.
• These semaphores are used to coordinate the resource
access, where the semaphore count is the number of
Click to Edit available resources.
• If the resources are added, semaphore count
automatically incremented and if the resources are
removed, the count is decremented.
  Binary Semaphores
• The binary semaphores are like counting
semaphores but their value is restricted to 0 and 1.
• The wait operation only works when the
semaphore is 1 and the signal operation succeeds
Click to Edit

when semaphore is 0.
• It is sometimes easier to implement binary
semaphores than counting semaphores.
 Classic Problems of
Synchronization
Readers and Writers Problem:
Reader’s writer problem is another example of a classic
synchronization problem

Problem statement
• There is a shared resource which should be accessed by multiple

Click to Edit
processes.
• There are two types of processes in this context.
• They are reader and writer.
• Any number of readers can read from the shared resource
simultaneously, but only one writer can write to the shared
 • When a writer is writing data to the resource, no other
process can access the resource.
• A writer cannot write to the resource if there are non-zero
number of readers accessing the resource at that time.

 The Solution
Click to Edit
• From the above problem statement, it is evident that readers have
higher priority than writer.

• If a writer wants to write to the resource, it must wait until there are no
readers currently accessing that resource.
 • An integer variable read_count is used to maintain the
number of readers currently accessing the resource.
• The variable read_count is initialized to 0.

• A value of 1 is given initially to m(mutex) and

w(write).
• Instead of having the process to acquire lock on the shared
Click to Edit
resource,

we use the mutex m to make the process to

acquire and release lock whenever it is updating the
read_count variable.
 The code for the writer process looks like this:
/* perform the reading operation */

wait(mutex);

readcnt --; // a reader wants to leave

if(read_count == 0) // no reader is left in the critical section

signal(wrt); // writers can enter

Click to Edit
signal(mutex); // reader leaves

} while(true);
 Dining Philosophers
Problem

• The dining philosopher's problem is a version of

the classical synchronization problem, in which
Click to Edit
five philosophers sit around a circular table and
alternate between thinking and eating.
• A bowl of noodles and five forks for each
philosopher are placed at the centre of the table.
 • One simple solution is to represent each chopstick with a semaphore.
• A philosopher tries to grab a chopstick by executing a wait () operation
Click to Edit
on that semaphore.
• She releases her chopsticks by executing the signal () operation on the
appropriate semaphores.
• Thus, the shared data are where all the elements of chopstick are
initialized to 1.
 semaphore chopstick
[5]; do {

wait (chopstick[i]);

wait (chopstick[(i+1) % 5]);

/* eat for a while */

Click to Edit signal(chopstick[i]);

signal (chopstick [ (i+1 % 5]);

/* think for while */

} while(true);
 Fig. The structure of Philosopher
• Although this solution guarantees that no two
neighbours are eating simultaneously, it nevertheless
must be rejected because it could create a deadlock.
• Suppose that all five-philosopher become hungry at
Click to Edit the same time and each grabs her left chopstick.
• All the elements of chopstick will now be equal to 0.

• When each philosopher tries to grab her right

chopstick, she will be delayed forever.
  Monitors
 A high-level abstraction that provides a convenient and effective
mechanism for process synchronization.
 A monitor type presents a set of programmer-defined operations
that provide mutual exclusion within the monitor.
Click to Edit  The monitor type also contains the declaration of variables whose
values define the state of an instance of that type, along with the
bodies of procedures or functions that operate on those variables.
 Syntax of a
monitor monitor
monitor_name

{Procedure P1(…) {

….}

Procedure P2(…) { ….
Click to Edit
}Procedure Pn(…){

…. }
Initialization code (…) {…
}}
 I.A procedure defined within a monitor can access only those
variables declared locally within the monitor and its formal
parameters.

II.Similarly, the local variable of a monitor can be accessed by

only the local procedures.
Click to Edit III.The monitor construct ensures that only one process at a time
can be active within the monitor
 Condition Construct: condition x, y;
 The only operation that can be invoked on a condition
variable are wait () and signal ().
 The operation x. wait (); means that the process invoking
this operation is suspended until another process invokes x.
Click to Edit signal ();
 The x. signal () operation resumes exactly one suspended
process.
Click to Edit Fig. Monitor with condition variable
 Deadlocks
Introduction
 In a multiprogramming environment, several process may
compete for a finite number of resources.
 A process requests resources; if the resources are not
Click to Edit
available at that time, the process enters a wait state.
 It may happen that waiting process will never again change
state, because the resources they have requested are held by
other waiting processes. This situation is called deadlock.
 • If a process requests an instance of a resource type, the
allocation of any instance of the type will satisfy the request.

• If it will not, then the instances are not identical, and the
resource type classes have not been defined properly.
 A process must request a resource before using it, and must
Click to Edit release the resource after using it.
 A process may request as many resources as it requires
carrying out its designated task.
 Example of Deadlock
 A real-world example would be traffic, which is going only
in one direction.
 Here, a bridge is considered a resource.
 So, when Deadlock happens, it can be easily resolved if one

Click to Edit
car backs up (Pre-empt resources and rollback).
 Several cars may have to be backed up if a deadlock
situation occurs.
 So, starvation is possible.
 Example of deadlock

Click to Edit Under the normal mode of operation, a process may utilize a resource in only
the following sequence:
Request: If the request cannot be granted immediately, then the requesting
process must wait until it can acquire the resource.

Use: the process can operate on the resource.

Release: the process releases the resource.

 Deadlock
Characterization
• In deadlock, processes never finish executing and system resources are
tied up . preventing other jobs from ever starting.

Necessary Conditions for Deadlock

Click to Edit
A deadlock situation can arise if the following four conditions hold
simultaneously in a system:

1. Mutual exclusion: At least one resource must be held in a non - sharable

mode; that is , only one process at a time can use the resource .

• If another process requests that resource, the requesting process must be

 2. Hold and wait: There must exist a process that is holding at least one
resource and is waiting to acquire additional resources that are currently
being held by other processes.

3. No pre-emption: Resources cannot be pre-empted; that is , a resource

can be released only voluntarily by the process holding it , after that
process , has completed its task .

Click to Edit 4. Circular wait: There must exist a set (P0 , P1 ... Pn ) of waiting
processes such that PO is waiting for a resource that is held by P1 , P1 is
waiting for a resource that is held by P2 , ..... Pn-1 is waiting for a resource
that is held by Pn. and Pn is waiting for a resource that is held by P0.
 Methods of Handling Deadlock

1. Deadlock Ignorance

2. Deadlock Prevention

3. Deadlock Avoidance

4. Deadlock Detection and Recovery

Deadlock Prevention
Click to Edit • For a deadlock to occur, each of the four necessary - conditions must hold,
by ensuring that at least on one these conditions cannot hold, we can
prevent the occurrence of a deadlock.

• Deadlock prevention means try to make all four conditions false or at least
try to remove one of the condition or at least make one of the conditions is
 Deadlock ignorance
Deadlock ignorance refers to a situation in computing or

concurrent programming where a system or application does not

take any measures to prevent, detect, or resolve deadlocks.

Click to Edit
A deadlock occurs when two or more processes are unable to

proceed because each is waiting for a resource that the other

holds.
 Deadlock Detection and Recovery
Deadlock occurs when a set of processes are blocked because

each process is holding a resource and waiting for another

resource held by another process.

Click to Edit
Detection involves monitoring the state of resource allocation and

process states to identify cycles in a resource allocation graph.

 Deadlock recovery is a critical process in operating

systems that involves resolving a deadlock situation

where two or more processes are unable to proceed

because they are each waiting for resources held by the

Click to Edit
others.
 Mutual Exclusion
• This condition must hold for non-sharable resources.

• For example, a printer cannot be simultaneously shared by several

processes.
• In contrast, Sharable resources do not require mutually exclusive access
and thus cannot be involved in a deadlock.

Click to Edit • A good example of a sharable resource is Read-only files because if

several processes attempt to open a read-only file at the same time, then
they can be granted simultaneous access to the file.
 Hold and Wait
• Hold and wait condition occurs when a process holds
a resource and is also waiting for some other
resource in order to complete its execution.
• Thus, if we did not want the occurrence of this
Click to Edit
condition then we must guarantee that when a
process requests a resource, it does not hold any
other resource.
 There are some protocols that can be used in order to ensure that the
Hold and Wait condition never occurs:
Click to Edit  According to the first protocol; Each process must request
and gets all its resources before the beginning of its
execution.
 The second protocol allows a process to request resources
only when it does not occupy any resource.
 Resource - Allocation Graph
• Deadlocks can be described more precisely in terms of
a directed graph called a system resource - allocation
graph.
• The set of vertices V is partitioned into two different
types of nodes P= {P1, P2, Pn}
Click to Edit
• The set consisting of all the active processes in the
system; and R = {R1, R2. Rm}, the set consisting of all
resource types in the system.
 • A directed edge from process Pi to resource type Rj is
denoted by Pi → Rj, it signifies that process Pi
requested an instance of resource type Rj and is
currently waiting for that resource.
• A directed edge from resource type Rj to process Pi is
denoted by Rj_ Pi it signifies that an instance of
Click to Edit
resource type Rj has been allocated to process Pi.
• A directed edge Pi_ Rj is called a request edge; a
directed edge Rj_ Pi is called an assignment edge.
 • When process Pi requests an instance of resource type
Rj, a request edge is inserted in the resource- allocation
graph.
• When this request can be fulfilled, the request edge is
instantaneously transformed to an
assignment edge.
Click to Edit
The resource-allocation graph shown in fig.,
• The set P, R and E:
o P= {P1, P2, P3}
o R= {R1, R2, R3, R4}
 Resource instances:
o One instance of resource type R1
o Two instance of resource type R2
o One instance of resource type R3
o Three instance of resource type R4

• Process states:
o Process P1 is holding an instance of resource type R2
Click to Edit and is waiting for an instance of resource type R1.
o Process P2 is holding an instance of R1 and an instance
of R2 and is waiting for an instance of R3.
o Process P3 is holding an instance of R3
o E= {P1→ R1, P2→R3, R1→P2, R2→P2, R2→P1,
R3→P3}
 Thank You !!!
Click to Edit