UNIT-2

Process Synchronization
Shyam B. Verma
(Assistant Professor)
 SYLLABUS [UNIT-2]
Concurrent Processes: Process Concept,
Principle of Concurrency, Producer / Consumer
Problem
Mutual Exclusion, Critical Section Problem,
Dekker’s solution, Peterson’s solution,
Semaphores, Test and Set operation;
Classical Problem in Concurrency- Dining
Philosopher Problem, Sleeping Barber
Problem;
Inter Process Communication models and
Schemes, Process generation.
 Objectives
To present the concept of process
synchronization.
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
To examine several classical process-
synchronization problems
To explore several tools that are used to
solve process synchronization problems
 Process Concept
 A process is a program in execution. The execution of a
process progresses in a sequential fashion. A program
is a passive entity while a process is an active entity. A
process includes much more than just the program code.
 A process includes the text section, stack, data
section, program counter, register contents and so
on.
 The text section consists of the set of instructions to be
executed for the process.
 The data section contains the values of initialized and
uninitialized global variables in the program.
 The stack is used whenever there is a function call in
the program.
 The program counter has the address of the next
instruction to be executed in the process.
 Principle of Concurrency
 Concurrency is the execution of multiple instruction
sequences at the same time.
 It happens in the operating system when there are several
process threads running in parallel. The running process
threads always communicate with each other through
shared memory or message passing. Concurrency
results in the sharing of resources resulting in problems
like deadlocks and resource starvation.
 Technology, like multi-core processors and parallel
processing, allows multiple processes and threads to be
executed simultaneously. Multiple processes and threads
can access the same memory space, the same declared
variable in code, or even read or write to the same file.
 The Processes executing in the OS is one of the two types:
Independent Processes
Cooperating Processes
 Principle of Concurrency
Independent Processes
 Its state is not shared with any other process.
 The result of execution depends only on the input
state.
 The result of the execution will always be the same for
the same input.
 The termination of the independent process will not
terminate any other.
Cooperating System
 Its state is shared along other processes.
 The result of the execution depends on relative
execution sequence and cannot be predicted in
advanced(Non-deterministic).
 The result of the execution will not always be the same
for the same input.
 The termination of the cooperating process may affect
other process.
 Problems in Concurrency
There are various problems in concurrency.
Some of them are as follows:
Sharing Global Resources
Sharing global resources is difficult. If two
processes utilize a global variable and both alter
the variable's value, the order in which the many
changes are executed is critical.
Locking the channel
It could be inefficient for the OS to lock the
resource and prevent other processes from using
it.
Optimal Allocation of Resources
It is challenging for the OS to handle resource
allocation properly.
 Issues of Concurrency
 Non-atomic operations may be interrupted by several
processes. A non-atomic operation depends on other processes,
and an atomic operation runs independently of other processes.
 Deadlock may happen in concurrent computing. Software and
hardware locks are commonly used to arbitrate shared
resources and implement process synchronization in parallel
computing, distributed systems, and multiprocessing.
 Blocking may happen when a process is waiting for some
event, like the availability of a resource or completing an I/O
operation.
 Race Conditions problem may occurs when the output of a
process is determined by the timing or sequencing of other
uncontrollable events.
 Starvation problem may arise where a process is continuously
denied the resources it needs to complete its work.
 Data inconsistency may occur. Maintaining data consistency
requires mechanisms to ensure the orderly execution of
cooperating processes.
 Producer Consumer Process
 Producer is a process which is able to produce data.
Consumer is a process that is able to consume the
data produced by the Producer.
 Both Producer and Consumer share a common
memory buffer. This buffer is a space of a certain
size in the memory of the system which is used for
storage. The producer produces the data into the buffer
and the consumer consumes the data from the buffer.
 So, what are the Producer-Consumer Problems?
 Producer Process should not produce any data when
the shared buffer is full.
 Consumer Process should not consume any data when
the shared buffer is empty.
 The access to the shared buffer should be mutually
exclusive i.e at a time only one process should be able
to access the shared buffer and make changes to it.
 For consistent data synchronization between Producer
and Consumer, the above problem should be resolved.
 Producer Consumer Process

Problem: Suppose that we wanted to provide a

solution to the consumer-producer problem that fills
the buffer completely. We can do so by having an
integer counter that keeps track of the number of
items in the buffers. Initially, counter is set to 0. It
is incremented by the producer after it produces a
new item and is decremented by the consumer
after it consumes an item.
 Producer

while (true) {
/* produce an item in next_produced */

while (counter == BUFFER_SIZE) ;

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

Note: These two routines are correct if they run

independently. But if the initial value of counter
is 5 and they executes concurrently. The
possible values of counter variable are: 4,5 or
6.
 Race Condition
A Race condition is a scenario that occurs in a
multithreaded environment due to multiple threads
sharing the same resource or executing the same piece
of code. If not handled properly, this can lead to an
undesirable situation, where the output state is
dependent on the order of execution of the threads.

Consider the above logic diagram, the output z is always

false.
Let A changes its state from false to true. If there is a
propagation delay to the not gate, its output will still
be true (since A was initially false). This will result in
a true output which is undesirable.
 Types of Race Conditions in
OS
A Read-Modify-Write race condition occurs
when multiple processes or threads attempt to
read, modify, and write the same shared
resource concurrently, leading to unexpected
behavior and inconsistencies in the final result.
A Check-Then-Act race condition occurs when
multiple processes or threads are checking for
the same condition and then acting upon it
without any synchronization mechanism to
prevent race conditions.
 Security Vulnerabilities due to
Race Condition
Race situations have a chance to introduce several
bugs that are affecting the system's dependability
and security.
Locking conditions are not accurate: There are
chances when codes are not protected or if locks
are not properly implemented, race conditions can
occur.
Resource deadlocks: When multiple threads
compete for resources such as files, memory or
locks and these resources are not managed race
conditions lead to deadlock.
Information leakage: When sensitive data is
exposed to unauthorized access, secure information
is leaked due to improper synchronization.
 Example of Race Condition
counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
counter-- could be implemented as

register2 = counter
register2 = register2 - 1
counter = register2

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

S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}
 Mutual Exclusion
Mutual exclusion is a frequently used method
for synchronizing processes or threads that
want to access some shared resource. If a
thread operates on a resource, another thread
that wants to do tasks on it must wait until the
first one is done with its process.
Mutual exclusion also known as Mutex is a unit
of code that postpone concurrent access to
shared resources. Mutual exclusion is
concurrency control’s property that is installed
for the objective of averting race conditions.
 Critical Section
The critical section refers to a specific part of a
program where shared resources are accessed, and
concurrent execution may lead to conflicts or
inconsistencies.
It is essential for the operating system to provide
mechanisms like locks and semaphores to ensure
proper synchronization and mutual exclusion in the
critical section. These safeguards prevent concurrent
processes from interfering with each other, maintaining
the integrity of shared resources.
The critical section problem in operating systems is an
issue that arises when shared resources are accessed
by concurrent processes.
The role of the operating system here is to ensure that
when two or more processes require to access the
shared resource concurrently, only one process gets
the access at a time.
 Critical Section
General structure of process Pi
 Critical Section Problem
Consider system of n processes {p , p , … p }
0 1 n-1
Each process has critical section segment of code
in which the processes may be changing shared
variables, updating a table, writing a file, and so on.
 When one process in critical section, no other may be
in its critical section i.e Mutual exclusion
 When there is more than one process accessing or
modifying a shared resource at the same time, then
the value of that resource will be determined by the
last process. This is called the race condition.
The objective is to design a protocol to solve this
problem.
Each process must ask permission to enter critical
section in entry section, may follow critical section
with exit section, then remainder section.
 Solution to Critical-Section
Problem
 To effectively address the Critical Section Problem in OS,
any solution must meet three key requirements:
Mutual Exclusion - This means that when one process is
executing within its critical section, no other process
should be allowed to enter its own critical section. This
ensures that shared resources are accessed by only one
process at a time, preventing conflicts and data
corruption.
Progress - When no process is currently executing in its
critical section, and there is a process that wishes to
enter its critical section, it should not be kept waiting
indefinitely. The system should enable processes to make
progress, ensuring that they eventually get a chance to
access their critical sections.
Bounded Waiting - There must be a limit on the number
of times a process can execute in its critical section after
another process has requested access to its critical
section but before that request is granted. This ensures
fairness and prevents any process from being starved of
critical section access.
 Various solutions have been developed to meet these requirements
and manage the Critical Section Problem. These solutions primarily
use software-based locks for synchronization. Here are some
common approaches:
 Test-and-Set: Uses a shared boolean variable, typically called
"lock," and the "test_and_set" instruction, which atomically sets
the lock to true.
 Compare-and-Swap: Uses a shared boolean variable “lock” and a
"compare_and_swap" instruction. It sets the lock to true only if the
value passed to it matches an expected value.
 Mutex Locks: Provide functions like "acquire()" and "release()" that
execute atomically. These locks ensure that only one process can
acquire the lock at a time.
 Semaphores: Semaphores are more advanced synchronization
tools. They use "wait()" and "signal()" operations, executed
atomically on a semaphore variable (typically an integer).
Semaphores can manage access to resources more flexibly.
 Condition Variables: This approach maintains a queue of
processes waiting to enter their critical sections. It ensures orderly
access by managing the waiting processes based on certain
conditions.
 Two Process Solution [Algorithm-1]
Code for Process Pi
do {
while (turn == j);

Critical Section

turn = j;

Remainder Section

} while (true);
The two processes are numbered P and P .
0 1
For convenience, when presenting P , we use P
i j
to represent other process.
Let the processes share a common integer
variable turn initialized to 0 (or 1).
If turn = i, then process P is allowed to
i
execute in its critical section.
The above solution ensures Mutual exclusion.
It requires strict alteration of processes in
critical section. So, no progress. If turn=0 and
P1 wants to enter its critical section, P 1 can not
do so.
No bounded waiting, because if a process do
not want to enter its critical section then the
turn of other process will no come.
 Algorithm-2
Replace the turn variable by a Boolean array
flag[2] 0 0
Initially array flag is initialized to zero. i.e. flag
If flag[i] is true then Pi is ready to enter the
critical section.
In this algorithm, process Pi sets flag[i] to
be true, signaling that it is ready to enter
its critical section.
Then, Pi checks if Pj is not ready to enter
critical section.
This solution satisfies mutual exclusion
requirement.
This solution does not satisfy Progress
requirement.
 Algorithm-3 [Peterson’s
Solution]
Good algorithmic description of solving the
problem
Two process solution
Assume that the load and store machine-
language instructions are atomic; that is,
cannot be interrupted
The two processes share two variables:
 int turn;
 Boolean flag[2]

The variable indicates whose turn it is to

turn
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.
Algorithm for Process Pi
 Peterson’s Solution (Cont.)
Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Each process Pi is giving a chance to
process Pj to enter the critical section in its entry
section. So, the Progress requirement is satisfied
3. Process Pi can be prevented from entering
the critical section only if it stuck in the while loop
with the condition:
flag[j]=true && turn[j]
i.e Pj is in its critical section. While exiting Pj will
reset flag[j]=false, allows Pi to enter its critical
section. So, Bounded-waiting requirement is met
 Multiple Process Solution
As we know that the Peterson’s solution solves the
critical section problem for two processes. The
solution to n-process critical section problem is
called bakery algorithm and it is based on
algorithm used in bakeries, ice-cream stores etc.
This algorithm solves a critical section problem,
following the fairest, first come, first serve
principle.
The Bakery Algorithm provides a way to make sure
that only one process can access the critical
section at a time to ensure
consistency. The Bakery Algorithm provides a
general solution to the critical section
problem, which means it provides a solution
when there are N processes that can access
the critical section.
This algorithm is adopted in bakeries where token
numbers are issued to set the order of customers.
When a customer enters a bakery store, he gets a
unique token number. The global counter displays
the number of customers currently being served,
and all other customers must wait at that time.
Once the baker finishes serving the current
customer, the next number is displayed. The
customer with the next token is now being served.
Similarly, in Lamport's bakery algorithm, processes
are treated as customers. In this, each process
waiting to enter its critical section gets a token
number, and the process with the lowest number
enters the critical section. If two processes have
the same token number, the process with a lower
process ID enters its critical section.
 Data Structure Used
Shared data – choosing is an array [0..n – 1]
of boolean values; & number is an array [0..n
– 1] of integer values. Both are initialized
to False & Zero respectively.
if i < j, Pi is served first; else Pj is served first.
(a, b) < (c, d) if a < c or if a == c and b < d
max(a [0], . . ., a [n-1]) is a number, k, such
that k >= a[i] for i = 0, . . ., n – 1
 // show interest in critical section

// get a token number

// busy wait until process Pj receives its token number

// token comparison
Firstly the process sets its “choosing” variable to be
TRUE indicating its intent to enter critical section.
Then it gets assigned the highest ticket number
corresponding to other processes. Then the
“choosing” variable is set to FALSE indicating that it
now has a new ticket number.
The next three lines is checks if a process is
modifying its TICKET value then at that time some
other process should not be allowed to check its old
ticket value which is now obsolete. This is why inside
the for loop before checking ticket value we first
make sure that all other processes have the
“choosing” variable as FALSE.
After that we proceed to check the ticket values of
processes where process with least ticket
number/process id gets inside the critical section.
The exit section just resets the ticket value to zero.
 Mutual Exclusion: A process with the lowest token
number is allowed to enter its critical section. Suppose
two processes have the same token number. In that
case, the process with the lower process ID among
these is selected, so at a particular time, there will be
only one process executing in its critical section. Thus
the requirement of mutual Exclusion is met.
 Progress: After selecting a token, a waiting process
checks whether any other waiting process has higher
priority to enter its critical section. If there is no such
process, Pi will immediately enter its critical section.
Thus meeting progress requirements.
 Bounded Waiting: As awaiting, the process will enter
its critical section when no other process is in its critical
section and
 If its token number is the smallest among other waiting
processes.
 If token numbers are the same, it has the lowest process ID
among other waiting processes.
 Synchronization Hardware
Hardware features can make the programming
task easier and improves system efficiency.
Some simple hardware instructions available on
many systems for implementing the critical
section code. This problem could be solved if
we could disable interrupts to occur while a
shared variable is being modified.
Currently running code would execute without
preemption. So, no unexpected modification
could be made to shared variable.
All solutions below based on idea of locking.
Protecting critical regions via locks.
Modern machines provide special atomic
hardware instructions
 Atomic = non-interruptible instructions
Solution to Critical-section Problem Using
Locks
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
 TestAndSet Instruction
Definition:
boolean test_and_set (boolean *target)
{
boolean rv = *target;
*target = TRUE;
return rv:
}
1.Executed atomically
2.Returns the original value of passed parameter
3.Set the new value of passed parameter to
“TRUE”.
4.If two TestAndSet instructions executed
simultenously (each on different CPUs), they will
be executed sequentially in some arbitrary order.
If a machine supports TestAndSet instruction,
then Mutual exclusion can be achieved by
following algorithm:
This solution satisfies Mutual exclusion,
progress but no bounded-waiting.
Another hardware instruction swap is
defined as:

It operates on the content of two words. It also

executed atomically.
 Bounded-waiting Mutual Exclusion with
test_and_set

do {
waiting[i] = true;
key = true;
while (waiting[i] && key)
key = test_and_set(&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);
 Mutex Locks
 Previous solutions are complicated and
generally inaccessible to application
programmers
 OS designers build software tools to solve
critical section problem
 Simplest is mutex lock
 Protect a critical section by first acquire() a
lock then release() the lock
 Boolean variable indicating if lock is available
or not
 Calls to acquire() and release() must be atomic
 Usually implemented via hardware atomic
instructions
 But this solution requires busy waiting
 This lock therefore called a spinlock
 acquire() and release()
 acquire() {
while (!available);
/* busy wait */
available = false;
}
release() {
available = true;
}
 do {
acquire() lock
critical section
release() lock
remainder section
} while (true);
 Semaphore
 Semaphore is a Synchronization tool that provides more
sophisticated ways (than Mutex locks) for process to synchronize
their activities. It can solve various synchronization problems
 Semaphore S – integer variable. It 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 mutex can be used to solve n-
process critical section problem. The n-
processes share a semaphore mutex
initialized to 1.
 Semaphore Implementation
Must guarantee that no two processes can
execute the wait() and signal() on the same
semaphore at the same time
Thus, the implementation becomes the critical
section problem where the wait and signal code
are placed in the critical section
 Could now have busy waiting in critical section
implementation. Busy- waiting wastes CPU cycles.
This type of semaphore is also called spin-lock. The
advantage of a spin-lock is that no context switch
is required when a process must wait on a lock.
Note that applications may spend lots of time in
critical sections and therefore this is not a good
solution.
 Semaphore Implementation with no Busy
waiting
 To overcome the problem of busy waiting, when a process
execute a wait operation and its semaphore value is not
positive, the process must block itself. The blocked
processes must be placed into a waiting queue. The
scheduler will pick another process to execute.
 Two operations:
 block – place the process on the waiting queue
 wakeup – remove one of processes in the waiting queue and
place it in the ready queue.
 Each semaphore has an integer value and a list of processes.
When a process waits on a semaphore, it is added to the list of
processes. A signal operation removes one process from the list
and awakens.
 typedef struct{
int value;
struct process *list;
} semaphore;
 Implementation with no Busy waiting (Cont.)
* Initially value is initialized to 1.
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);
}
}
* If the semaphore value is negative, its magnitude is
the no. of processes waiting on that semaphore.
 Deadlock and Starvation
Deadlock – When two or more processes are
waiting indefinitely for an event (signal) that can
be caused by only one of the waiting processes. If
such a state is reached, these processes are said
to be deadlocked.
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
 Solved via priority-inheritance protocol
 Binary Semaphore
Above semaphore construct is known as
counting semaphore, since its value ranges
over unrestricted domain.
A Binary semaphore is an integer with value 0
or 1.
Let S be a counting semaphore. To implement
it in terms of Binary semaphore:
Binary semaphore S1, S2;
int C;
Initially, S1=1 and S2=0 and C is initialized to the
initial value of counting semaphore S.
wait(S) signal(S)
{ {
wait(S1); wait(S1);
C--; C++;
if(C<0) if(C<=0)
{ {
signal(S1); signal(S2);
wait(S2); }
} else
signal(S1); signal(S1);
} }
 Classical Problems of
Synchronization

Classical problems used to test newly-

proposed synchronization schemes
Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem
 Bounded-Buffer Problem
buffers, each can hold one
 There is pool of n

item. Semaphore mutex is initialized to the value

1 to provide Mutual Exclusion to access a
buffer.
Semaphore full initialized to the value 0
indicating buffer is not full.
Semaphore empty initialized to the value n
indicating all buffers are empty.
 Bounded Buffer Problem (Cont.)
 The structure of the producer process
do {
...
/* produce an item in next_produced */
...
wait(empty);
wait(mutex);
...
/* add next_produced to the buffer */
...
signal(mutex);
signal(full);
} while (true);
 Bounded Buffer Problem
(Cont.)
 The structure of the consumer process
Do {
wait(full);
wait(mutex);
...
/* remove an item from buffer to next_consumed */
...
signal(mutex);
signal(empty);
...
/* consume the item in next_consumed */
...
} while (true);
 Readers-Writers Problem
A data set (file or variable) is shared among a
number of concurrent processes. Some of them
wants to read the content and some of them
wants to write it.
 Readers – only read the data set; they do not
perform any updates
 Writers – can both read and write
Reader processes creates no adverse effects,
but a writer and some other processes
(reader/writer) want concurrent access of
shared object will create problem.
Writer processes will have exclusive access.
There are several variations of how readers and
writers are considered to access the shared
object involve some form of priorities.
Solution-1: No reader will be kept waiting
unless a writer has already obtained the
permission to use the shared object.
Solution-2: Once the writer is waiting to
access the object no new reader may start
reading.
Shared Data
Semaphore rw_mutex initialized to 1, common to
both reader and writer processes
Semaphore mutex initialized to 1, to ensure
mutual exclusion
Integer read_count initialized to 0, to count the no.
of reader processes
 Readers-Writers Problem (Cont.)
 The structure of a writer process

do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} while (true);
 Readers-Writers Problem (Cont.)
The structure of a reader process
do {
wait(mutex);
read_count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);
There is a possibility of starvation of writer
processes.
If a writer is in the critical section and n reader
processes are waiting, then one writer is
waiting on rw_mutex and (n-1) readers are
waiting on mutex.
When a writer executes signal(rw_mutex), we
may resume the execution of either the
waiting readers or a single writer.
This selection is made by scheduler.
Problem is solved on some systems by kernel
providing reader-writer locks.
 Dining-Philosophers Problem

 Philosophers spend their lives alternating thinking and

eating.
 Don’t interact with their neighbors, occasionally try to
pick up 2 chopsticks (one at a time) to eat from bowl.
 Need both to eat, then release both when done.
 In the case of 5 philosophers
 Shared data
 Bowl of rice (data set)
 Semaphore chopstick [5] initialized to 1
 Dining-Philosophers Problem Algorithm

 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);
 What is the problem with this
algorithm?
 Dining-Philosophers Problem Algorithm (Cont.)

This solution guarantees that no two

neighbors are eating simultaneously but the
possibility of deadlock.
Deadlock handling
 Allow at most 4 philosophers to be sitting
simultaneously at the table.
 Allow a philosopher to pick up the forks only if
both are available (picking must be done in a
critical section.
 Use an asymmetric solution -- an odd-
numbered philosopher picks up first the left
chopstick and then the right chopstick. Even-
numbered philosopher picks up first the right
chopstick and then the left chopstick.
 Sleeping Barber Problem
The analogy is based upon a hypothetical barber
shop with one barber. There is a barber shop
which has one barber, one barber chair, and n
chairs for waiting for customers if there are any
to sit on the chair.
If there is no customer, then the barber sleeps in
his own chair.
When a customer arrives, he has to wake up the
barber.
If there are many customers and the barber is
cutting a customer’s hair, then the remaining
customers either wait if there are empty chairs in
the waiting room or they leave if no chairs are
empty.
 Dekker’s Solution for Critical Section
Problem

* Satisfies all three requirements of CS problem

 GATE QUESTIONS

 CORRECT ANSWER: A
 GATE QUESTIONS

 CORRECT ANSWER: C
 GATE QUESTIONS

 CORRECT ANSWER: A
 GATE QUESTIONS

 CORRECT ANSWER: B
 GATE QUESTIONS

 CORRECT ANSWER: B
 GATE QUESTIONS

 CORRECT ANSWER: C
 GATE QUESTIONS

 CORRECT ANSWER: C
 GATE QUESTIONS

 CORRECT ANSWER: A