Dayananda Sagar Academy of Technology and Management

(Affiliated to VTU, Belagavi & Approved by AICTE, New Delhi)

OPP. ART OF LIVING, UDAYAPURA, KANAKAPURA Road, BENGALURU- 560082

Department of Computer Science & Engineering

OPERATING SYSTEMS
(18CS43)
Synchronization

Dr. Nagaraj M. Lutimath

Associate Professor
Dept. of CS&E
 Contents
• Introduction
• Producer Consumer Problem
• Critical Section Problem
• Peterson’s Solution
• Synchronization Hardware
• Semaphore
• Classic Problems of Synchronization
• Monitors
• Summary

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 2

 Introduction
• To introduce the critical section problem, whose solutions can be used to
ensure the consistency of shared data
• To present both software and hardware solutions of the critical section problem
• A cooperating process is one that can affect or affected by other processes
executing in the system.
• Cooperating processes can either directly share a logical address space.
• Concurrent access to shared data may result in data inconsistency
• To maintain data consistency various mechanisms are required to ensure the
orderly execution of cooperating processes

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 3

Producer Consumer Problem
• A Producer process produces information that is consumed by Consumer
process.
• To allow Producer and Consumer process to run concurrently, A Bounded
Buffer can be used where the items are filled in a buffer by the producer and
emptied by the consumer.
• The number of items allowed in buffer is BUFFER_SIZE-1
• An integer count that keeps track of the number items in the buffer.
• Initially, count is set to 0.
• Count is incremented every time when a new item is added to the buffer and it
is decremented when one item is removed from the buffer.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 4

 Producer Consumer Problem
• Producer

while (true) {
/* produce an item and put in nextProduced
*/
while (count == BUFFER_SIZE)
; // do nothing
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
count++;
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 5

Producer Consumer Problem
• Consumer

while (true) {
while (count == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
/* consume the item in nextConsumed
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 6

Producer Consumer Problem
• Race Condition : A situation where several processes access and manipulate
the same data concurrently and the outcome of the execution depends on the
particular order in which the access takes place is called Race Condition.
• count++ could be implemented as
register1 = count
register1 = register1 + 1
count = register1

• count-- could be implemented as

register2 = count
register2 = register2 - 1
count = register2

• Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = count {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = count {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute count = register1 {count = 6 }
S5: consumer execute count = register2 {count = 4}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 7

Critical Section Problem
• Consider a system consisting of n processes [P0, P1, … Pn-1].

• Each process has a segment of code, called a critical section in which the process
may be changing common variables, updating a table, writing a file, and soon.

• The important feature of the system is that, when one process is executing in its
critical section, no other process is to be allowed to execute in its critical section.

• No two processes are executing in their critical sections at the same time.

• The critical section problem is to design a protocol that the processes can use to
cooperate.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 8

Critical Section Problem
The general structure of a typical process P i,
do{
entry section

critical section
exit section

remainder section
}while (TRUE);

Fig 1.1 :General Structure of a typical Process P i

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 9

Critical Section Problem
Critical Section problem must satisfy the following requirements:
1. Mutual Exclusion - If process Pi is executing in its critical section, then no other processes can
be executing in the critical section.
2. Progress - If no process is executing in its critical section and there exist some processes that
wish to enter their critical section, then the selection of the processes that will enter the critical
section next cannot be postponed indefinitely.
3. 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.
• Assume that each process executes at a nonzero speed
• No assumption concerning relative speed of the N processes

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 10

Peterson’s Solution
• This is a classical software solution to critical section problem.
• Two process solution
• Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted.
• The two processes share two variables:
– int turn;
– Boolean flag[2]
• The variable turn indicates whose turn it is to enter the critical section.
• The flag array is used to indicate if a process is ready to enter the critical section. flag[i] =
true implies that process Pi is ready.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 11

Peterson’s Solution
The Structure of Process Pi in Peterson’s Solution,

do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);

Fig 1.2 :General Structure of a typical Process Pi in Peterson’s Solution

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 12

Peterson’s Solution
Proof for the requirements of Critical Section Problem.
To prove Mutual exclusion is preserved

• Each Pi enter its critical section only if either flag[j]==false or turn ==i.

• If both processes can be executing in their critical sections at the same time, then flag[0] ==
flag [1]==true.

• These two observations imply that Pi and Pj could not have successfully executed their while
statements at about the same time, since the value of turn can be either 0 or 1 but cannot be both.
Hence, one of the processes (Pj) must have successfully executed the while statement, whereas Pi had
to execute at least one additional statement ("turn==j").

• However, at that time, flag [j] == true and turn == j, and this condition will persist as long as Pi is in its
critical section, as a result, mutual exclusion is preserved.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 13

Peterson’s Solution
Proof for the requirements of Critical Section Problem.

To prove Progress

• A Process Pi can be prevented from entering the critical section only if it is stuck in the while loop

with the condition flag [j] ==true and turn=== j; this loop is the only one possible.

• If Pj is not ready to enter the critical section, then flag [j] ==false, and Pi can enter its critical section.

• If Pj has set flag [j] = true and is also executing in its while statement,

then either turn === i or turn == j.

– If turn == i, then Pi will enter the critical section.

– If turn== j, then Pj will enter the critical section.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 14

Peterson’s Solution
Proof for the requirements of Critical Section Problem.

To prove Bounded Waiting is preserved

• However, once Pj exits its critical section, it will reset flag [j] = false, allowing Pi

to enter its critical section.

• If Pj resets flag [j] to true, it must also set turn to i.

• Thus, since Pi does not change the value of the variable turn while executing the

while statement, Pi will enter the critical section (progress) after at most one entry

by Pj (bounded waiting).

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 15

Synchronization Hardware
• The solution to the critical section problem requires a simple tool a lock.

• Race conditions are prevented by requiring that critical regions be protected by locks.

• That is a process must acquire a lock before entering a critical section and it releases the lock

when it exits the critical section.

do{
acquire ‘lock
critical Section
release lock
remainder Section
}while (TRUE);
Fig 1.3 :Solution to the critical section problem using locks

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 16

Synchronization Hardware
• Many systems provide hardware support for critical section code

• Critical section problem can be solved by uniprocessors if could

prevent interrupts.

• We could be sure that currently running code would execute without

preemption

• Generally this approach is inefficient on multiprocessor systems.

• Modern machines provide TestAndSet and Swap instructions.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 17

Synchronization Hardware
• Solution Using TestAndSet Instruction
• Solution:
boolean TestAndSet (boolean *target)
{
boolean rv = *target;
*target = TRUE;
return rv;
}

Fig 1.4 :The definition of the TestAndSet() instruction

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 18

Synchronization Hardware
• Solution Using TestAndSet Instruction
• If two TestAndSet () instructions are executed simultaneously, they will be executed
sequentially in some arbitrary order.
• If the machine supports the TestAndSet () instruction, then implementation of
mutual exclusion can be done by declaring a Boolean variable lock, initialized to
false.
do {
while ( TestAndSet (&lock ))
; // do nothing
// critical section
lock =FALSE;
// remainder section
} while (TRUE);

Fig 1.5 :Mutual-Exclusion implementation with TestAndSet()

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 19

Synchronization Hardware
• Solution Using Swap Instruction
• The Swap() instruction, operates on the contents of two words, it is
defined as shown below
void Swap (boolean *a, boolean *b)
{
boolean temp = *a;
*a = *b;
*b = temp:
}

Fig 1.6 :The definition of the Swap() instruction

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 20

Synchronization Hardware
• Solution Using Swap Instruction
• Shared Boolean variable lock initialized to FALSE;
• Each process has a local Boolean variable key
• Solution:
do {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// critical section
lock = FALSE;
// remainder section
} while (TRUE);
Fig 1.7 :Mutual-Exclusion implementation with Swap instruction

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 21

Synchronization Hardware
• Bounded-waiting Mutual Exclusion with TestandSet()
do {
waiting[i] = TRUE;
key = TRUE;
while (waiting[i] && key)
key = TestAndSet(&lock);
waiting[i] = FALSE;
// critical section
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = FALSE;
else
waiting[j] = FALSE;
// remainder section
} while (TRUE);
Fig 1.8 :Bounded Waiting Mutual Exclusion with TestAndSet

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 22

Synchronization Hardware
To prove the mutual exclusion requirement

• Note that process Pi can enter its critical section only if either waiting [i] ==
false or key ==false.

• The value of key can become false only if the TestAndSet( ) is executed.

• The first process to execute the TestAndSet( ) will find key== false; all
others must wait.

• The variable waiting[i] can become false only if another process leaves its
critical section; only one waiting[i] is set to false, maintaining the mutual
exclusion requirement.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 23

Synchronization Hardware
To prove the progress requirement

• Note that, the arguments presented for mutual exclusion also apply here,
since a process exiting the critical section either sets lock to false or sets
waiting[j] to false.

• Both allow a process that is waiting to enter its critical section to proceed.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 24

Synchronization Hardware
To prove the bounded-waiting requirement

• Note that, when a process leaves its critical section, it scans the array waiting
in the cyclic ordering (i + 1, i + 2, ... , n 1, 0, ... , i 1).

• It designates the first process in this ordering that is in the entry section
(waiting[j] ==true) as the next one to enter the critical section.

• Any process waiting to enter its critical section will thus do so within n - 1
turns.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 25

Semaphore
• Another synchronization tool for critical section problem
• Semaphore S – integer variable
• Two standard operations modify S: wait() and signal()
– Originally called P() and V()
• Less complicated
• Can only be accessed via two indivisible (atomic) operations
– wait (S) {
while S <= 0
; // no-op
S--;
}
– signal (S) {
S++;
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 26

Semaphore
Binary semaphore
• The value of a binary semaphore can range only between 0 and1.
• Binary semaphores are known as mutex locks, as they are locks that provide mutual exclusion.
Binary semaphores to deal with the critical-section problem for multiple processes.
• Then processes share a semaphore, mutex, initialized to 1.
• Each process Pi is organized as shown in below figure

do {
wait (mutex);
// Critical Section
signal (mutex);
// remainder section
} while (TRUE);

Fig 1.9: Mutual-exclusion implementation with semaphores

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 27

Semaphore
Counting semaphore
• The value of a counting semaphore can range over an unrestricted domain.
• Counting semaphores can be used to control access to a given resource
consisting of a finite number of instances.
• The semaphore is initialized to the number of resources available. Each process
that wishes to use a resource performs a wait() operation on the semaphore.
• When a process releases a resource, it performs a signal()operation.
• When the count for the semaphore goes to 0, all resources are being used.
• After that, processes that wish to use a resource will block until the count becomes
greater than 0.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 28

Semaphore
Implementation
• The main disadvantage of the semaphore definition requires busy waiting.

• While a process is in its critical section, any other process that tries to enter its critical
section must loop continuously in the entry code.

• This continual looping is clearly a problem in a real multiprogramming system,

where a single CPU is shared among many processes.

• Busy waiting wastes CPU cycles that some other process might be able to use
productively.

• This type of semaphore is also called a spinlock because the process "spins" while
waiting for the lock.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 29

Semaphore
Implementation with no busy waiting
• A process that is blocked, waiting on a semaphore S, should be restarted

when some other process executes a signal() operation.

• The process is restarted by a wakeup( ) operation, which changes the process

from the waiting state to the ready state.

• The process is then placed in the ready queue.

• To implement semaphores under this definition, we define a semaphore as a

"C’ struct:

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 30

Semaphore
Implementation with no busy waiting
typedef struct {

int value;

struct process *list;

} semaphore;

• Each semaphore has an integer value and a list of processes list. When a
process must wait on a semaphore, it is added to the list of processes.

• A signal() operation removes one process from the list of waiting processes
and awakens that process.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 31

Semaphore
Implementation with no busy waiting
• The definition of the wait() and signal() semaphore operations is modified.

• When a process executes the wait () operation and finds that the semaphore
value is not positive, it must wait.

• However, rather than engaging in busy waiting, the process can block itself.

• The block operation places a process into a waiting queue associated with the
semaphore, and the state of the process is switched to the waiting state.

• Then control is transferred to the CPU scheduler, which selects another

process to execute.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 32

Semaphore
Implementation with no busy waiting
• A process that is blocked, waiting on a semaphore S, should be restarted

when some other process executes a signal() operation.

• The process is restarted by a wakeup( ) operation, which changes the process

from the waiting state to the ready state.

• The process is then placed in the ready queue.

• To implement semaphores under this definition, we define a semaphore as a

"C’ struct:

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 33

Semaphore
Implementation with no busy waiting
The wait() semaphore operation can now be defined as:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 34

Semaphore
Implementation with no busy waiting
The signal () semaphore operation can now be defined as:
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 35

Semaphore
Implementation with no Busy waiting
• The block() operation suspends the process that invokes it.
• The wakeup(P) operation resumes the execution of a blocked
process P.
• These two operations are provided by the operating system as basic
system calls.
• In this implementation semaphore values may be negative.
• If a semaphore value is negative, its magnitude is the number of
processes waiting on that semaphore.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 36

Semaphore
Deadlock and Starvation
• Deadlock – two or more processes are waiting indefinitely for an event that
can be caused by only one of the waiting processes
• Let S and Q be two semaphores initialized to 1
P0 P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
. .
signal (S); signal (Q);
signal (Q); signal (S);
• Starvation – indefinite blocking. A process may never be removed from the
semaphore queue in which it is suspended
• Priority Inversion – Scheduling problem when lower-priority process holds
a lock needed by higher-priority process

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 37

Semaphore
Deadlock and Starvation
• Suppose that Po executes wait (S) and then P1 executes wait (Q).

• When Po executes wait (Q), it must wait until P1 executes signal (Q).

• Similarly, when P1 executes wait (S), it must wait until Po executes

signal(S).

• Since these signal() operations cannot be executed, Po and P1 are

deadlocked.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 38

Classical Problems of Synchronization

• Bounded-Buffer Problem

• Readers and Writers Problem

• Dining-Philosophers Problem

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 39

Classical Problems of Synchronization

Bounded-Buffer Problem

• N buffers, each can hold one item

• Semaphore mutex initialized to the value 1

• Semaphore full initialized to the value0

• Semaphore empty initialized to the value N.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 40

Classical Problems of Synchronization

Bounded-Buffer Problem
• A data set is shared among a number of concurrent processes
• Readers – only read the data set; they do not perform any updates
• Writers – can both read and write.
• Problem – allow multiple readers to read at the same time. Only one single writer can
access the shared data at the same time.
– Shared Data
– Dataset
– Semaphore mutex initialized to 1.
– Semaphore wrt initialized to1.
– Integer read count initialized to 0
– Semaphore empty is initialized to n

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 41

Classical Problems of Synchronization

Bounded-Buffer Problem

• The structure of the producer process

do {
// produce an item in nextp
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
} while (TRUE);

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 42

Classical Problems of Synchronization

Bounded-Buffer Problem

• The structure of the Consumer process

do {
wait (full);
wait (mutex);
// remove an item from buffer to nextc
signal (mutex);
signal (empty);
// consume the item in nextc
} while (TRUE);

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 43

Classical Problems of Synchronization

• Readers and Writers Problem

• A data set is shared among a number of concurrent processes.
– Readers – only read the data set; they do not perform any updates
– Writers – can both read and write
• Problem – allow multiple readers to read at the same time. Only one single
writer can access the shared data at the same time.
• Shared Data
– Data set
– Semaphore mutex initialized to 1 (controls access to readcount)
– Semaphore wrt initialized to 1 (writer access)
– Integer readcount initialized to 0 (how many processes are reading
object)

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 44

Classical Problems of Synchronization

• Readers and Writers Problem

• A data set is shared among a number of concurrent processes.
– Readers – only read the data set; they do not perform any updates
– Writers – can both read and write
• Problem – allow multiple readers to read at the same time. Only one single
writer can access the shared data at the same time.
• Shared Data
– Data set
– Semaphore mutex initialized to 1 (controls access to readcount)
– Semaphore wrt initialized to 1 (writer access)
– Integer readcount initialized to 0 (how many processes are reading
object)

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 45

Classical Problems of Synchronization

• Readers and Writers Problem

The structure of a writer process

do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 46

Classical Problems of Synchronization

• Readers and Writers Problem

The structure of a writer process
do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;
} while (TRUE);

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 47

Classical Problems of Synchronization

• Dining-Philosophers Problem
• Shared data
– Bowl of rice (data set)
– Semaphore chopstick [5] initialized to 1

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 48

Classical Problems of Synchronization

• Dining-Philosophers Problem
• The structure of Philosopher i:
do {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 49

Classical Problems of Synchronization

• Dining-Philosophers Problem
• Relies too much on programmers not making mistakes
(accidental or deliberate)
• Incorrect use of semaphore operations:
– signal (mutex) …. wait (mutex)
– wait (mutex) … wait (mutex)
– Omitting of wait (mutex) or signal (mutex) (or
both)

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 50

Monitors
• A high-level abstraction that provides a convenient and effective mechanism
for process synchronization
• Only one process may be active within the monitor at a time
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
…
procedure Pn (…) {……}
Initialization code ( ….) { … }
…
}
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 51

Monitors

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 52

Monitors

• To have a powerful Synchronization schemes a condition

construct is added to the Monitor.
• So synchronization scheme can be defined with one or more
variables of type condition Two operations on a condition
variable:
• condition x, y;
• Two operations on a condition variable:
– [Link] () – a process that invokes the operation is suspended.
– [Link] () – resumes one of processes (if any) that
invoked [Link] ()

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 53

Monitors
Solution to Dining Philosophers
Each philosopher I invokes the operations pickup() and putdown() in the following

monitor DP
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
void pickup (int i) {
state[i] = HUNGRY;
test(i);
if (state[i] != EATING) self [i].wait;
}
void putdown (int i) {
state[i] = THINKING;
// test left and right neighbors
test((i + 4) % 5);
test((i + 1) % 5);
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 54

Monitors

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 55

Monitors
void test (int i) {
if ( (state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING ;
self[i].signal () ;
}
}

initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 56

Monitors
monitor DP
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];

void pickup (int i) {

state[i] = HUNGRY;
test(i);
if (state[i] != EATING) self [i].wait;
}

void putdown (int i) {

state[i] = THINKING;
// test left and right neighbors
test((i + 4) % 5);
test((i + 1) % 5);
}

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 57

Summary

• Critical Section Problem is introduced

• Peterson’s Solution for the Critical Section Problem is

introduced.

• Classical Problems for synchronization is introduced.

• Monitors is introduced.

• Dining Philosopher’s Problem is solved using Monitors.

Dept. of CS&E Synchronization Dr. Nagaraj M. Lutimath 58