Unit II Process Synchroniza on

In a mul programming opera ng system, mul ple processes are loaded into memory and executed
concurrently. The CPU switches rapidly between processes, giving the impression that they are
running at the same me. This improves CPU u liza on and system performance. However, when
mul ple processes execute simultaneously, they o en need to share common resources such as:
 Main Memory (shared variables, arrays, data structures)
 Files (reading and wri ng data)
 Databases (upda ng records)
 Printers and I/O Devices
 Network Resources
 Shared Counters or Buffers
Sharing resources increases efficiency but also introduces serious problems.

Core Problem: Concurrent Access to Shared Data

When two or more processes access and modify shared data at the same me, the outcome may
depend on the order in which processes execute. Since CPU scheduling is unpredictable, the result
may vary each me the program runs.
This situa on can lead to:
 Incorrect calcula ons
 Data corrup on
 Inconsistent files
 System crashes
 Unexpected output
What is a Race Condi on?
A Race Condi on occurs when:
 Two or more processes (or threads) access and modify shared data at the same me, and the
final result depends on the order in which they execute.
 Because the CPU switches very fast between processes, we cannot predict which process will
execute first. This may lead to incorrect or inconsistent results.

Example: Bank Account Withdrawal

Suppose a bank account has: Balance = ₹1000
Two people (P1 and P2) try to withdraw ₹500 at the same me using ATM machines.
What Should Happen?
If both withdrawals are successful:
Final Balance = 1000 – 500 – 500 = 0
What Actually Happens (Race Condi on Case)
Internally, withdrawal works like this:
 Read current balance
 Subtract amount
 Update balance
Now imagine this execu on order:
 P1 reads balance → ₹1000
 P2 reads balance → ₹1000
 P1 subtracts ₹500 → updates balance to ₹500
  P2 subtracts ₹500 → updates balance to ₹500

Final Balance = ₹500 (Incorrect)

Correct balance should be ₹0, but due to simultaneous access, the result became wrong.

Why Did This Happen?

Because:
 Both processes accessed the shared data at the same me.
 There was no control or synchroniza on.
 The system did not restrict one process from accessing the balance while the other was
upda ng it.
This situa on is called a Race Condi on, because the processes are "racing" to access and modify
shared data.

Race Condi on : A situa on where mul ple processes access and modify shared data concurrently,
and the final result depends on the order of execu on, leading to incorrect output.

Cri cal Sec on : A segment of a program in which shared resources such as shared variables, files, or
data structures are accessed or modified. Since these shared resources are common to mul ple
processes, improper access may lead to data inconsistency or incorrect results.
Execu on within the cri cal
sec on must be treated as an
atomic opera on, meaning that
once a process enters its cri cal
sec on, no other process should
be allowed to enter its own cri cal
sec on that accesses the same
shared resource. In other words,
only one process can execute in its
cri cal sec on at any given me.
If a process is already execu ng in
its cri cal sec on, all other
processes that wish to enter their
cri cal sec ons must wait un l the
current process completes its
execu on and exits the cri cal
sec on. This ensures proper
coordina on among processes and prevents race condi ons.
Thus, the main objec ve of managing the cri cal sec on is to maintain data consistency and ensure
mutual exclusion in a concurrent processing environment.
Explana on of Each Sec on
1. Entry Sec on
Code where the process requests permission to enter the cri cal sec on.
Example:
 Checking if resource is free
 Locking the resource

2. Cri cal Sec on

The part of the program where shared data is accessed or modified.
Example:
 Upda ng a shared variable
 Wri ng to a shared file
 Modifying database records

3. Exit Sec on
Code that releases the resource a er finishing execu on in the cri cal sec on.
Example:
 Unlocking a mutex
 Sending signal to other processes

4. Remainder Sec on
The rest of the program that does not use shared resources.

Solu on to the Cri cal Sec on Problem

1. Mutual Exclusion
 At most one process can be in the cri cal sec on at any me.
 If one process is execu ng its cri cal sec on, others must wait.

2. Progress
 If no process is inside the cri cal sec on and some processes want to enter, then one of them
must be selected without unnecessary delay.
 The decision should not be postponed indefinitely.

3. Bounded Wai ng
There must be a limit on the number of mes other processes can enter the cri cal sec on a er a
process has requested entry. This prevents starva on.

Semaphore : A synchroniza on mechanism used in opera ng systems to control access to shared

resources in a mul programming environment. It is a special integer variable that helps prevent race
condi ons and ensures proper coordina on between processes. A semaphore can be accessed only
through two atomic opera ons: wait() and signal(). The wait opera on decreases the semaphore
value and may block a process, while the signal opera on increases the value and wakes wai ng
processes, ensuring mutual exclusion and resource management.
Purpose of Semaphore Using :
1. Ensure Mutual Exclusion : It ensure mutual exclusion by allowing only one process to enter the
cri cal sec on at a me. This prevents simultaneous access to shared resources and maintains proper
coordina on among concurrent processes.

2. Control Access to Shared Resources : Regulate access to shared resources such as memory, files, or
devices by maintaining a count of available resources. They ensure that processes use resources in an
orderly and controlled manner.

3. Avoid Race Condi ons : Prevent race condi ons by synchronizing process execu on. They ensure
that shared data is accessed in a sequen al and controlled way, so that unpredictable and incorrect
results are avoided.

4. Synchronize Mul ple Processes : It help in synchronizing mul ple processes by coordina ng their
execu on order. They make processes wait when necessary and allow them to proceed only when
safe condi ons are sa sfied.

5. Prevent Data Inconsistency : It maintain data consistency by protec ng shared data from
concurrent modifica ons. They ensure that updates to shared variables are completed properly before
another process accesses them.

Types of Semaphore
1. Binary Semaphore : It is a semaphore whose value can be only 0 or 1.
 If the value is 1, the resource is free.
 If the value is 0, the resource is busy.
It is mainly used to achieve mutual exclusion, meaning only one process can enter the cri cal sec on
at a me. Because it works like a lock, it is also called a Mutex (Mutual Exclusion).
Example: If a process enters the cri cal sec on, the semaphore value becomes 0. Other processes
must wait un l the first process exits and the value becomes 1 again.

2. Coun ng Semaphore
A Coun ng Semaphore is a semaphore whose value can be any non-nega ve integer (0, 1, 2, 3, … n).
It is used when there are mul ple instances of a resource available.
The value of the semaphore represents the number of available resources.
Example: If there are 3 printers in a system:
 Semaphore value = 3
 Each me a process uses a printer, the value decreases by 1
 When a printer is released, the value increases by 1
Jist :
 Binary Semaphore → Used for mutual exclusion (0 or 1).
 Coun ng Semaphore → Used when mul ple resources are available (0 to n).
Both types help in controlling access to shared resources and maintaining proper synchroniza on
among processes.
Opera ons on Semaphore
Semaphore supports only two atomic opera ons:
1. wait( ) Opera on or (P Opera on)
The wait() opera on checks whether the resource is available.
If the value of semaphore is greater than 0:
 It decreases the value by 1.
 The process enters the cri cal sec on.
If the value is 0:
 The process must wait.
Representa on:
wait(S) {
while (S <= 0);
S = S - 1;
}

2. signal( ) Opera on or (V Opera on)

The signal( ) opera on is used when a process leaves the cri cal sec on.
 It increases the semaphore value by 1.
 It allows another wai ng process to enter.
Representa on:
signal(S) {
S = S + 1;
}

Advantages of Semaphore
1. Provides Mutual Exclusion : Semaphores ensure mutual exclusion by allowing only one process to
access the cri cal sec on at a me. This prevents simultaneous execu on and maintains proper
coordina on among concurrent processes in a system.
2. Prevents Race Condi ons : Semaphores prevent race condi ons by controlling the order in which
processes access shared data. They ensure that shared variables are modified in a controlled and
sequen al manner.
3. Controls Access to Shared Resources : Semaphores manage shared resources by maintaining a
count of available instances. They allow processes to access resources only when available, ensuring
organized and efficient resource alloca on.
4. Used in Solving Classical Problems like Producer-Consumer : Semaphores are widely used to solve
classical synchroniza on problems such as Producer-Consumer, Dining Philosophers, and Readers-
Writers, ensuring proper coordina on and avoiding conflicts between processes.

Disadvantages of Semaphore
1. Can Cause Deadlock
Improper use of semaphores may lead to deadlock, where two or more processes wait indefinitely for
resources held by each other, preven ng further execu on of the system.
2. Can Cause Starva on : Semaphores may cause starva on if some processes are con nuously
delayed because other processes repeatedly acquire the resource, preven ng wai ng processes from
ge ng execu on opportuni es.
3. Difficult to Debug : Semaphore-based synchroniza on can be difficult to debug because errors such
as missed signals or incorrect ordering may cause unpredictable behavior that is hard to trace and
iden fy.
4. Incorrect Use May Create Serious Problems : If semaphores are not implemented properly, they
may lead to data inconsistency, deadlocks, or system instability, making the program unreliable and
difficult to maintain.

Classical Problems of Process Synchroniza on

In Opera ng Systems, some standard synchroniza on problems are commonly used to explain the
concept of process coordina on and mutual exclusion. These are known as Classical Problems of
Process Synchroniza on.
They help in understanding how synchroniza on mechanisms like semaphores, mutex, and monitors
are used in real systems.
The three main classical problems are:
1. Producer – Consumer Problem
2. Dining Philosophers Problem
3. Readers – Writers Problem
----------------------------------------------------------********---------------------------------------------------------------
1. Producer – Consumer Problem
Problem Descrip on
The Producer – Consumer
problem involves:
 A Producer process that
produces data (items).
 A Consumer process that
consumes data.
 A shared Buffer of fixed
size.
The producer adds items to
the buffer, and the consumer
removes items from the
buffer.
Issues in This Problem
1. The producer should not
add items if the buffer is full.
2. The consumer should not remove items if the buffer is empty.
3. Only one process should access the buffer at a me (mutual exclusion).
Solu on Idea
This problem is solved using three semaphores:
 mutex → For mutual exclusion
 empty → To count empty buffer slots
 full → To count filled buffer slots
This ensures proper coordina on between producer and consumer.
2. Dining Philosophers Problem
Problem Descrip on
Five philosophers are si ng
around a circular table.
Each philosopher:
 Thinks
 Gets hungry
 Picks up two chops cks
(one le and one right)
 Eats
 Puts down chops cks
There are five chops cks, one
between each pair of
philosophers.
Issues in This Problem
 If all philosophers pick up
their le chops ck at the
same me, none can pick
up the right one.
 This situa on leads to deadlock.
 Some philosophers may also suffer from starva on.
Purpose of the Problem
This problem demonstrates:
 Deadlock
 Resource alloca on issues
 Need for proper synchroniza on
It can be solved using semaphores or monitors.

3. Readers–Writers Problem
Problem Descrip on
In this problem:
 Some processes only read
data (Readers).
 Some processes write data
(Writers).
 Shared resource is usually
a database or file.
Rules
1. Mul ple readers can read
simultaneously.
2. Only one writer can write
at a me.
3. When a writer is wri ng,
no reader should read.
Issues
 If readers are given more priority, writers may suffer from starva on.
 If writers are given priority, readers may suffer from starva on.
Different versions of the problem handle these priori es differently.

Why These Problems Are Important

These classical problems:
 Explain real-world synchroniza on issues
 Help understand deadlock and starva on
 Demonstrate the need for mutual exclusion
 Show prac cal use of semaphores and synchroniza on tools