CHAPTER 4

CONCURRENCY-SYNCHRONIZATION:
MUTUAL EXCLUSION, SEMAPHORES AND
MONITORS
 CONCURRENCY

• Concurrency - a property of systems - several processes are

executing at the same time
• Concurrent computing –
• the simultaneous execution of multiple interacting computational tasks
@
• a form which programs are designed as collections of interacting
computational processes that may be executed in parallel.
 KEY TERMS RELATED
TO CONCURRENCY
• Atomic operation
• Group of indivisible operations. No other process can see an
intermediate state or interrupt the operation.
• Critical section
• A section of process code - requires access to shared resources
must not be executed while another process is in a corresponding
section of code.
• Mutual exclusion (Mutex)
• Requirement - when one process is in a critical section that
accesses shared resources, no other process is in the critical
section (also accessing any of those shared resources).
 KEY TERMS RELATED
TO CONCURRENCY
• Deadlock
• Situation - two or more processes are unable to proceed because
each is waiting the others to do something.
• Semaphores
• Semaphore is simply a variable which is non-negative and
shared between threads/processes. This variable is used to solve
the critical section problem and to achieve process
synchronization in the multiprocessing environment.
• Livelock
• Situation - two or more processes continuously change their
state in response to changes in the other process(es) without
doing any useful work.
 KEY TERMS RELATED
TO CONCURRENCY
• Race condition
• When more than one processes are executing the same code or
accessing the same memory or any shared variable concurrently,
in that condition there is a possibility that the output or the value
of the shared variable is wrong.
• Starvation
• Situation - a runnable process is overlooked indefinitely by the
scheduler; although it is able to proceed, it is never been chosen
 PROCESS SYNCHRONIZATION

• Means sharing system resources by processes in a such a

way that, concurrent access to shared data is handled in
order to maintain the consistency of shared data.
• Maintaining data consistency demands mechanisms to
ensure synchronized execution of cooperating processes.
• Can be done using hardware and software solutions.
• Introduced to handle problems that arose while multiple
process executions.
 PROCESS SYNCHRONIZATION

• On the basis of synchronization, processes are categorized

as one of the following two types:
1. Independent Process : Execution of one process does not
affects the execution of other processes.
2. Cooperative Process : Execution of one process affects the
execution of other processes.
• Process synchronization problem arises in the case of
Cooperative process also because resources are shared in
Cooperative processes.
 PROCESS SYNCHRONIZATION

Critical Section Problem

• 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 executing its
critical section. If any other process also wants to execute
its critical section, it must wait until the first one finished.
CRITICAL SECTION PROBLEM
 CRITICAL SECTION PROBLEM
Any solution to the critical section problem must satisfy three
requirements:
• Mutual Exclusion : If a process is executing in its critical section,
then no other process is allowed to execute in the critical section.
• Progress : If no process is executing in the critical section and other
processes are waiting outside the critical section, then only those
processes that are not executing in their remainder section can
participate in deciding which will enter in the critical section next,
and the selection can not be postponed indefinitely.
• 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.
 SOLUTIONS FOR CRITICAL
SECTION PROBLEM
• Mutex

• Semaphore

• Monitors
 MUTUAL EXCLUSION (MUTEX)
• Mutex lock is essentially a variable that is binary nature that
provides code wise functionality for mutual exclusion. At times,
there maybe multiple threads that may be trying to access same
resource like memory or I/O etc. To make sure that there is no
overriding. Mutex provides a locking mechanism.

• Only one thread at a time can take the ownership of a mutex and
apply the lock. Once it done utilizing the resource and it may release
the mutex lock.
MUTEX
MUTEX
 MUTEX

Mutex in Operating System

 MUTEX

Mutex in Operating System

 MUTEX

Mutex in Operating System

 MUTEX

Mutex in Operating System

 SEMAPHORES

• Introduced/created by Edsger W. Dijkstra, mainly to solve the

Process Synchronization problem in OS.

• Most popular use to solve the Critical Section problem.

• It uses signaling mechanism to allow access to shared resource

namely by two –
 Wait()
 Signal()
 SEMAPHORES

A variable that has an • There is no way to inspect or

integer value on which
only three operations manipulate semaphores other than
are defined: these three operations

1) A semaphore may be initialized to a nonnegative integer value

2) The semWait operation decrements the semaphore value
3) The semSignal operation increments the semaphore value
SEMAPHORES
SEMAPHORES
SEMAPHORES
SEMAPHORES
 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

Semaphores in Operating System

 SEMAPHORES

There are two types of semaphores : Binary Semaphores and

Counting Semaphores
 BINARY SEMAPHORE

• Imagine that there are two processes A and B.

• At the beginning the value of semaphore is initialized as 1.
• Imagine process 1 wants to enter the critical section
 Before it can do that, it checks the value of semaphore which is 1 thus,
it can enter the CS and semaphore value is turned to 0
• Now imagine that process 2 wants to enter too
 It checks the semaphore value which is 0 thus it can’t enter and waits
until the value is non-zero/non-negative value
• Now, Process 1 finishes and signals semaphore which in turns changes
semaphore value to 1
• Thus, now process 2 can enter Critical section

• In this way mutual exclusion was achieved.

 BINARY SEMAPHORES EXAMPLE

Let there be two processes P1 and P2 and a

semaphore s is initialized as 1. Now if
suppose P1 enters in its critical section then
the value of semaphore s becomes 0. Now if
P2 wants to enter its critical section then it
will wait until s > 0, this can only happen
when P1 finishes its critical section and calls
V operation on semaphore s. This way
mutual exclusion is achieved.
 COUNTING SEMAPHORE

• Can have any value and are not restricted over a certain domain.
• They can be used to control access to a resource that has a limitation
on the number of simultaneous accesses.
• Whenever a process wants to use that resource, it checks if the number
of remaining instances is more than zero, i.e., the process has an
instance available. Then, the process can enter its critical section.
• After the process is over with the use of the instance of the resource, it
can leave the critical section.
For example, let us assume that the
semaphore value is 3.
• Process 1 enters critical section and
semaphore value is changed to 2
• Process 2 also enters critical section and
semaphore value is changed to 1
• Process 2 signals semaphore and
comes out of critical section and
Semaphore value is 2
• Note at this moment only 1 process that
is process 1 is in critical section
• Process 3 and 4 also enter critical
section simultaneously and semaphore
value is 0
• At this moment there are three
processes in Critical section which are
process 1, 3, 4
• Now imagine that process 5 wants to
enter the CS. It would not be able to
enter as semaphore value is 0
• It can only enter once any of the process
1, 3, 4 signals out of the critical section.
Mutex Vs. Semaphores
 MUTEX VS. SEMAPHORES
 The basic difference between semaphore and mutex is that
semaphore is a signalling mechanism i.e. processes
perform wait() and signal() operation to indicate whether
they are acquiring or releasing the resource.
 Mutex is locking mechanism, the process has to acquire
the lock on mutex object if it wants to acquire the resource.
Basis for Comparison Semaphore Mutex

Basic Semaphore is a signalling mechanism. Mutex is a locking mechanism.

Existence Semaphore is an integer variable. Mutex is an object.

Mutex allow multiple program

Semaphore allow multiple program
thread to access a single
Function threads to access a finite instance of
resource but not
resources.
simultaneously.

Semaphore value can be changed by any Mutex object lock is released

Ownership process acquiring or releasing the only by the process that has
resource. acquired the lock on it.

Semaphore can be categorized into

Mutex is not categorized
Categorize counting semaphore and binary
further.
semaphore.

Mutex object is locked or

Semaphore value is modified using unlocked by the process
Operation
wait() and signal() operation. requesting or releasing the
resource.

If all resources are being used, the If a mutex object is already

process requesting for resource performs locked, the process requesting
Resources Occupied wait() operation and block itself till for resources waits and queued
semaphore count become greater than by the system till lock is
one. released.
 MONITORS
• A Monitor type high-level synchronization construct.
• It is an abstract data type.
• The Monitor type contains shared variables and the set of
procedures that operate on the shared variable.
• When any process wishes to access the shared variables in the
monitor, it needs to access it through the procedures.
• These processes line up in a queue and are only provided
access when the previous process release the shared variables.
• Only one process can be active in a monitor at a time.
 MONITORS

monitor {

//shared variable declarations

data variables;
Procedure P1() { ... }
Procedure P2() { ... }
.
.
.
Procedure Pn() { ... }
}
MONITORS
 ADVANTAGES OF MONITORS
• Monitors are easy to implement than semaphores.
• Mutual exclusion in monitors is automatic while in semaphores, mutual
exclusion needs to be implemented explicitly.
• Monitors can overcome the timing errors, that occur while using
semaphores.
o A heavy load on the server is causing processes to be delayed
from releasing semaphores.
o A process has crashed while holding a semaphore, causing
other processes to block when trying to acquire the semaphore.
o Deadlock – Thread A wants a semaphore owned by thread B,
who wants a semaphore owned by thread C, who wants a
semaphore owned by thread A.
• Shared variables are global to all processes in the monitor while
shared variables are hidden in semaphores.
 CLASSICAL PROBLEMS OF
SYNCHRONIZATION
Readers Writers Problem
• The problem statement is, if a database or file is to be shared among several concurrent
process, there can be 2 types of users –
 Readers – Reader are those processes/users which only read the data
 Writers – Writers are those processes which also write, that is, they change the data .
• It is allowed for 2 or more readers to access shared data, simultaneously as they are not
making any change and even after the reading the file format remains the same.
• But if one writer(Say W1) is editing or writing the file then it should lock, and no other
writer(Say W2) can make any changes until w1 has finished writing the file.

• If writer W1 has begun writing process, then

• No additional writer can perform write function
• No reader is allowed to read
• If 1 or more readers are reading, then
• Other readers may read as well
• No writer may perform write function until all readers have finished reading
CLASSICAL PROBLEMS OF
SYNCHRONIZATION
CLASSICAL PROBLEMS OF
SYNCHRONIZATION
CLASSICAL PROBLEMS OF
SYNCHRONIZATION