Process Synchronization

CSE-331

Prepared by-
Mst. Rashida Akhtar
Asst. Professor,
Dept of CSE, VU
 Process Synchronization

Process

Independent Process Cooperating process

[Execution of one process does not [Execution of one process affects
affect the execution of others] the execution of others]
Race Condition
 Process Synchronization

• Process Synchronization means a mechanism

to ensure the orderly execution of cooperating
processes that share and manipulate a same
logical address space or data in order to
minimize the chance of inconsistent data.
 Critical Section Problem

• A Critical Section is a code segment that

accesses shared variables
• It means that in a group of cooperating
processes, at a given point of time, only one
process must be executing its critical section.
• If any other process also wants to execute its
critical section, it must wait until the first one
finishes.
Critical Section Problem
 A Critical Section Environment contains:

Entry Section Code requesting entry into the

critical section.

Critical Section Code in which only one process can

execute at any one time.

Exit Section The end of the critical section,

releasing or allowing others in.

Remainder Section Rest of the code AFTER the critical

section.
 Solution to Critical Section Problem
• A solution to the critical section problem
must satisfy the following three conditions :
• Mutual Exclusion
• Progress
• Bounded Waiting
 Solution Requirements to Critical
Section Problem
• A solution Requirements to the critical section
problem must satisfy the following three conditions :
• Mutual Exclusion: only one process can be in its critical
section at a given point of time.
• Progress: If no process is in its critical section, Waiting
processes can participate in voting to enter in to critical
section
• 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
Solution Algorithms to Critical Section Problem

• Synchronization Hardware
• Peterson’s Solution (Mutex Locks)
• Semaphore
• Monitor
 Synchronization Hardware

• Many systems provide hardware support for critical section code.

The critical section problem could be solved easily in a single-
processor environment if we could disallow interrupts to occur
while a shared variable or resource is being modified.

• Disabling interrupt on a multiprocessor environment can be time

consuming as the message is passed to all the processors.

• message transmission lag, delays entry of threads into critical

section and the system efficiency decreases.
 Peterson’s Solution (Mutex Locks)

• A strict software approach called Mutex Locks was

introduced. In this approach,
• in the entry section of code, a LOCK is acquired over
the critical resources modified and used inside
critical section, and in the exit section that LOCK is
released.
 Semaphore
• A new and very significant technique for managing
concurrent processes by using the value of a simple
integer variable to synchronize the progress of
interacting processes.
• This integer variable is called semaphore a
synchronizing tool and is accessed only through two
atomic operations
• wait ()
• and signal()
 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++;
}
 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
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;
Semaphore Implementation with no Busy waiting

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);
}
}
 Limitations of Semaphores
• Priority Inversion is a big limitation os
semaphores
• With improper use, a process may block
indefinitely. Such a situation is called
Deadlock.
• Semaphores permit more than one thread to
access the critical section
 When to use Binary Semaphore?

• Quite obvious, binary semaphore can have a

value either 0 or 1. It means binary
semaphore protect the access to a SINGLE
shared resource, so the internal counter of
the semaphore can only take the values 1 or 0.
 Classical Problem
• Producer Consumer problem
• Reader writer problem
• Dining philosopher problem
 Monitor
• A Monitor is an object designed to be accessed from
multiple threads. The member functions or methods
of a monitor object will enforce mutual exclusion, so
only one thread may be performing any action on the
object at a given time
• To synchronize tasks within the monitor, a condition
variable is used to delay processes executing in a
monitor.
• a static module of data and procedure declarations.
 Monitor
• A monitor module encapsulates both a resource
definition and operations/ procedures that
exclusively manipulate it
• Only one call to a monitor procedure can be
active at a time and this protects data inside the
monitor from simultaneous access by multiple
users.
 Monitor
A PROCEDURE
P1
B
PROCEDURE
C
P2
Shared Data PROCEDURE

A Monitor is a module
• that encapsulates shared data structure
• Procedures that operate on shared data
• Synchronization between concurrent access
 Monitor
A PROCEDURE
P1
B
PROCEDURE
C block

P2
Shared Data PROCEDURE

A Monitor is a module
• that encapsulates shared data structure
• Procedures that operate on shared data
• Synchronization between concurrent access
Monitor
Single Shared Resource
 Monitor
class Account {
private lock myLock public method deposit(int
private int balance := 0
amount)
invariant balance >= 0 precondition amount >= 0
public method boolean withdraw(int {
amount)
precondition amount >= 0 myLock.acquire()
{ try {
myLock.acquire()
try { balance := balance + amount
if balance < amount {
return false
} finally {
} else { myLock.release()
balance := balance - amount
return true }
}
} finally {
}
myLock.release() }
}
}