CH 6 Synchronization

Chapter 6: Synchronization
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
Chapter 6: Synchronization Tools
OBJECTIVES
● To present the concept of process
● 6.1 Background
synchronization.
● 6.2 The Critical-Section Problem
● To introduce the critical-section
● 6.3 Peterson’s Solution problem, whose solutions can be used to
● 6.4 Synchronization Hardware ensure the consistency of shared data
● 6.5 Mutex Locks ● To present both software and hardware
● 6.6 Semaphores 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
Operating System Concepts – 9th Edition 6.2 Silberschatz, Galvin and Gagne ©2013
Operating Systems
Introduction Recall
• Independent process
– A process that does not share data with other processes.
– cannot affect or be affected by the execution of another
process.
• Cooperating process
– can affect or be affected by the execution of another
process.
– processes directly share logical address space (code
& data) or processes share data through files or
Chapter 3
messages.
_______________________________________________________________________________
Silberschatz, A., Galvin, P.B., and Gagne, G. Operating System Concepts (9th Edition). John Wiley & Sons: Asia. (2014) Page 120.
3
6.1 Background
● Concurrent access: accessing of the same data at the

same time by more than one process, thus:
● Concurrent access to shared data may result in data
inconsistency
● Maintaining data consistency requires mechanisms to ensure
the orderly execution of cooperating processes
● Race Condition: problem in concurrent execution
● The synchronization mechanism is usually provided by both
hardware and the operating system
● Illustration of the problem – The producer-Consumer problem.
● Basic assumption – load and store instructions are atomic.
6.1 Background
Why a Race Condition Occurs?
Two processes may be :

 executing simultaneously, and
 trying to access the same global variable.
6.5
5
Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition
6
http://undergraduate.csse.uwa.edu.au/units/CITS2230/handouts/Lecture09/lecture9.pdf
7
Critical section
Mutual exclusion
Operating Systems
Producer-Consumer Problems
• Several processes work together to complete
common task – Process Cooperation
• Common paradigm for cooperating processes,
producer process produces information that is
consumed by a consumer process.
Examples:
 The compiler produces an assembly code which is consumed
by an assembler.
 The web server provides HTML files which is consumed by the
Chapter 3
client web browser requesting the resource.
8
Operating Systems
6.1
• Suppose that we wanted to provide a solution that fills all

the buffers where we allow the producer and consumer
processes to increment and decrement the same variable.
• We can do so by adding another integer variable –
a counter that keeps track of the number of full buffers.
Initially, counter = 0.
• The variable counter, is incremented by the producer after
it produces a new buffer and is decremented by the
consumer after it consumes a buffer.
• The code is shown in the next two slides
Chapter 3
Operating Systems
• To enable producer and consumer to be executed

concurrently, a buffer (shared memory) is used for
producer to put data while consumer access it.
 unbounded-buffer provides unlimited buffer size.

 bounded-buffer assumes that there is a fixed buffer size.
Chapter 3
10
Operating Systems
• Producer puts data in one slot while consumer

retrieve data from another slot.
• Producer and consumer need to be
synchronized so that consumer will not retrieve
data before producer puts the data into the
buffer.
• Therefore,
Chapter 3
– producer needs to wait if buffer is full

– consumer needs to wait if buffer is empty
11
Producer Process
while (true) {
/* produce an item in next produced */
while (counter == BUFFER_SIZE) ;

/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter = counter +1;
}
Consumer Process
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter = counter - 1;
/* consume the item in next consumed */
Operating Systems
Bounded-Buffer Problems
• Shared Variables
– in, out, counter and buffer[ ]
– Initial values for in, out, counter =0
• Both routines are correct if executed independently.
• However, it may give problem if run concurrently

when the processes are not synchronized properly.
Chapter 3
(For Slide page 21-24:_________________________________________________________________

14
15
Buffer [6]
Producer Consumer
● If current counter = 5 and statements:

counter ++  (producer)
counter --  (consumer)
are executed concurrently . . .
● Then the counter maybe 4, 5 or 6.
● The correct value is 5 (synchronized properly)
16
● Each statement consists of several machine instructions:
Race Condition
● counter = counter + 1 could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1
● counter = counter -1 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}
Synchronize problem (race condition)
Operating Systems
Race Condition - Definition

• Def 1: A situation whereby at least two processes perform some
operations on shared data and the outcome depends on the order
of data access.
• Result of process must be independent of the speed of
execution of other concurrent processes;
– Depend on the control / data synchronization mechanisms.
• Def 2: A situation whereby multiple threads access a data item
without coordination in a multithreaded application.
• possibly causing inconsistent results (depending on which thread
reaches the data item first).
Chapter 3
* (Multithread normally access / used shared variables)

_______________________________________________________________________________
18
Operating Systems
Solution to Race Condition

• Ensure that only one process at a time can
manipulate the shared variable (eg. Counter)
• Therefore process synchronization is needed.

– means coordinating the activities of two or more
processes.
• Synchronization is necessary to ensure that

interdependent code is executed in the proper
Chapter 3
sequence.
19
Race Condition (Cont.)
● How do we solve the race condition?
● We need to make sure that:

● The execution of
counter = counter + 1
is executed as an “atomic” action. That is, while it is being
executed, no other instruction can be executed concurrently.
● Similarly for
counter = counter - 1
● The ability to execute an instruction, or a number of instructions,

atomically is crucial for being able to solve many of the
synchronization problems.
Atomic means one operation at a time

Operating Systems
Ex
tr a
Exercise 6.1:
Based on a several machine instructions below that

has synchronization problem, give your suggestion on
how to overcome that race condition situation.
Chapter 3
21
Operating Systems
Ex
tr a
Solution 6.1:
Producer should update the counter just before

consumer read the value of counter.
Chapter 3
22
6.2 Critical Section Problem
● Part of a program (segment of code for each process)
● Consider system of n processes {P0, P1, … Pn-1}
● Each process has critical section segment of code
● Process may be changing common variables, updating table,
writing file, etc
● When one process in critical section, no other may be in its
critical section
● Critical section problem is to design protocol to solve this.
● Each process must ask permission to enter critical section in entry
section code; it than executes in the critical section; once it
finishes executing in the critical section it enters the exit section
code. The process then enters the remainder section code.
General structure of Process Entering the Critical Section
● General structure of process Pi
Figure 6.1 General structure of Process Entering the Critical Section
Operating Systems
CS – Process Structure
Chapter 3
25
Algorithm for Process Pi
● Entry section to critical section is to “disable interrupts.

● Execute in the critical section
● Exit section is to “enable interrupts”.
● Implementation issues:
● Uniprocessor systems
4 Currently running code would execute without preemption
● Multiprocessor systems.
4 Generally too inefficient on multiprocessor systems
4 Operating systems using this not broadly scalable
● Is this an acceptable solution?
● This is impractical if the critical section code is taking a long
time to execute.
Have a variable “turn” to indicate which process is next
do {
while (turn == j);

critical section
turn = j;
remainder section
} while (true);
Figure 6.2
• Algorithm is correct. Only one process at a time in the critical

section.
• The other process will do Busy waiting for until the current process
finish its critical section.
6.2
Requirements for CS solutions
Assumptions:
⚫ Assume that each process executes at a non-zero speed
⚫ No assumption concerning relative speed of the n
processes or #number of CPU.
Mutual Exclusion
The algorithm does satisfy
the three essential criteria
to solve the CS problems. Progress
Bounded Waiting
6.28
28
Solution to Critical-Section Problem
Must satisfy the following three requirements:
1. Mutual Exclusion - If process Pi is executing in its critical section,
then no other processes can be executing in their critical sections
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
Operating Systems
4 Types of locking mechanisms to solve CS problem:
1. Software defined (Strict Alternation, Flagging and Peterson)
2. Hardware support (Test-and-set and swap)
3. Support from the Operating System (Semaphore)
4. Support the programming language (Ada – rendevous)

Chapter 3
30
6.3 Software Solution: Peterson’s Algorithm
● Good algorithmic software solution

● 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 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!
do { ● Provable that the three CS

flag[i] = true; requirements are met:
turn = j; 1. Mutual exclusion is preserved
while (flag[j] && turn = = j);
Pi enters CS only if:
critical section
flag[i] = false; either flag[j] =
remainder section false or turn = i
} while (true); 2. Progress requirement is
satisfied
Figure 6.2 The structure of Process Pi in 3. Bounded-waiting
Peterson’s Solution requirement is met
Operating Systems
Exercises 1
• Rewrite the Peterson's algorithm for CS solution
for process 0 (P0).
• Rewrite the Peterson's algorithm for CS solution
for process 1 (P1).
P1
Chapter 3
P0
33
Operating Systems
Initial SHARED values:

flag[0] = FALSE Answer
flag[1] = FALSE
do { do {
flag[0] = TRUE; flag[1] = TRUE;
turn = 1; turn = 0;
while(flag[1] && turn == 1) while(flag[0] && turn == 0)
; /* do nothing */ ; /* do nothing */
critical section critical section
flag[0] = FALSE; flag[1] = FALSE;
remainder section remainder section
} while (TRUE); } while (TRUE);
P0 P1
Initially the flags are false. When a process wants to execute it’s critical section, it sets
it’s flag to true and turn as the index of the other process. This means that the
Chapter 3
process wants to execute but it will allow the other process to run first. The process
performs busy waiting until the other process has finished it’s own critical section.
After this the current process enters it’s critical section and adds or removes a
random number from the shared buffer. After completing the critical section, it sets
it’s own flag to false, indication it does not wish to execute anymore.
34
Operating Systems
"I am ready to enter CS" flag[0]=true;

“But you can execute your own CS" turn=1;
"If you are ready to enter and while(flag[1]==true&&turn==1){
it's your turn I'll wait.“ P0 wait*/ }
/*P0
Otherwise, I’ll enter my CS CS
"I don't want to enter any more." flag[0]=false;
Entrance to the CS is granted for process P0
• if P1 does not want to enter its CS,

flag[1]=FALSE
or
Chapter 3
• if P1 has given priority to P0 by setting turn=0.
35
Operating Systems
Exercises 2
• What is the event for each ti if 2 concurrent
processes wishing to enter their CSs.
• Check if the following

is preserved:
– Mutual exclusion
Chapter 3
– Progress
– Bounded Waiting
36
Operating Systems
Answer: Execution of algorithm

P0 P1
time flag[0] flag[1] turn Events

t0 TRUE FALSE 1 P0 request to enter CS0
t1 TRUE FALSE 1 P0 enters CS0
t2 TRUE TRUE 0 P1 requests to enter CS1
t3 FALSE TRUE 0 P0 executes RS0
t4 FALSE TRUE 0 P1 enters CS1
t6 FALSE FALSE 0 P1 executes RS1
Chapter 3
t7 FALSE FALSE 0 P0 executes RS0 1
t8 FALSE TRUE 0 P1 requests to enter CS1 2
37
Operating Systems
Answer: Execution of algorithm

P0 P1
Mutual
Exclusion
t0 TRUE FALSE 1 P0 request to enter CS0
t2 TRUE TRUE 0 P1 requests to enter CS1
t6 FALSE FALSE 0 P1 executes RS1
Chapter 3
t7 FALSE FALSE 0 P0 executes RS0 1
t8 FALSE TRUE 0 P1 requests to enter CS1 2
38
Operating Systems
Peterson’s algorithm :
Table shows a process that can enter its CS for

different values of flag[] and turn
flag[0] flag[1] turn Process that can

enter its CS
TRUE FALSE 1 P0
FALSE TRUE 0 P1
TRUE TRUE 0 P0
Chapter 3
4
TRUE TRUE 1 P1
2
39
Operating Systems
Exercise 3:
Continue from previous example
t10 TRUE FALSE 1 P0 requests to enter CS0
t11 TRUE TRUE 0 P1 request to enter CS1
t12 TRUE TRUE 0 P0 enters CS0
t13 TRUE TRUE 0 P1 busy waiting in loop
t16 TRUE TRUE 1 P0 request to enter CS0 3

Chapter 3
t18 TRUE FALSE 1 P1 executes RS1

40
Operating Systems
Exercise 3:
Continue from previous example
t10 TRUE FALSE 1 P0 requests to enter CS0
t11 TRUE TRUE 0 P1 request to enter CS1
t12 TRUE TRUE 0 P0 enters CS0
t14
ProgressFALSE TRUE 0 P0 executes RS0
t15 FALSE TRUE 0 Bounded
P1 enters CS 1
t16 TRUE TRUE 1 P0 request toWaiting

enter CS0 3

Chapter 3
t18 TRUE FALSE 1 P1 executes RS1

41
Solution to Critical-section Problem Using Locks
● Software-based solutions such as Peterson’s are not guaranteed

to work on modern computer architectures.
● Many systems provide hardware support for implementing the
critical section code.
● All solutions are based on idea of locking
● Protecting critical regions via locks
● Code:
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
Synchronization Hardware
● Modern machines provide special atomic hardware instructions to

implement locks
● Atomic = non-interruptible
● Two types instructions:

● Test memory word and set value
● Swap contents of two memory words
Operating Systems
Test-and-Set Instruction
• Test-and-Set is a single indivisible machine instruction
known simply as TS and was introduced by IBM for its
multiprocessing System 360/370 computers.
• In a single machine cycle, it tests to see if the key is

available and if it is, sets it to unavailable.
• The key is a single bit in a storage location that can contain

• 0 (if it is free) or
• 1 (if busy).
Chapter 3
44
test_and_set Instruction
● Definition:
boolean test_and_set (boolean *target)
{
boolean rv = *target;
*target = TRUE;
return rv:
}
Figure 6.3 The definition of the test_and_set()
instruction
● Properties:
● Executed atomically
● Returns the original value of passed parameter
● Set the new value of passed parameter to “TRUE”.
Operating Systems
Test-and-Set for CS Application

• a process (P1) would test the condition code using Test-and-Set
instruction before entering a CS.
• If no other process was in the CS, then P1 would be allowed to

proceed and the condition code is would be changed from 0 to 1.
• Later, when P1 exits the CS, the condition code is reset to 0 so

that another process can enter its CS.
• On the other hand, if P1 finds a busy condition code, then it is

placed in a waiting loop where it continues to test the condition
Chapter 3
code and wait until it is free.
46
Solution using test_and_set()
● Shared Boolean variable lock, initialized to FALSE
● Each process, wishing to execute CS code:
do {
while (test_and_set(&lock))
; /* do nothing */
/* critical section */
lock = false;
/* remainder section */
} while (true);
Figure 6.4 Mutual exclusion implementation with test_and_set()
● Solution results in busy waiting.

● What about bounded waiting?
● However, this algorithm does not satisfy bounded waiting. Read textbook
for the solution.
6.5 Mutex Locks
● Previous solutions are complicated and generally inaccessible to

application programmers
● OS designers build software tools to solve critical section

problem.
● Simplest tools is the mutex lock, which has a Boolean variable

“available” associated with it to indicate if the lock is available or
not.
● However, there is a more robust tool that can behave similarly to

a mutex lock but can also provide more sophisticated ways for
processes to synchronize their activities.
Semaphores
Overview
A method of visual signaling, usually by means of flags or

lights.
They are used in :

– railways ( raise arm  track is clear,
lowered arm track is busy and train must
wait)
– between foreign navy ships to

communicate messages over long
distances.
6.49
49
Semaphores
Similar function in OS i.e it signals if and when a

resource is free and can be used by a process.
6.50
50
Semaphores
Semaphore in OS:
● Protocol mechanism for task communication.
● Specifically, semaphores are used to:

● Control access to a shared resource (mutual exclusion).
● Signal the occurrence of an event.
● Allow two tasks to synchronize their activities.
6.51
51
Semaphores
● Synchronization tool that provides more sophisticated
ways (than Mutex locks) for processes to synchronize
their activities.
● Semaphore S – integer variable
● Can only be accessed via two indivisible (atomic)
operations
● when one process modify semaphore variable S,
then no other process can modify the variable
concurrently  mutual exclusion
● wait() is called P()
● and signal() called V()
Semaphores
● Definition of the wait() operation
wait(S)
{ while (S <= 0) ; // busy waiting
S = S - 1;
}
(S <= 0 implies busy critical section/region or a process in CS)
(Process calling on wait() operation must wait until S > 0 (+ve value))
● Definition of the signal() operation

signal(S)
{
S = S + 1;
}
Types of Semaphores
● 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 implement a counting semaphore S as a binary semaphore
Semaphore Usage
Can solve various synchronization problems
● A solution to the CS problem.
● Create a semaphore “synch” initialized to 1
wait(synch)
CS
signal(synch);
Semaphore Usage
Consider P1 and P2 that require code segment S1 to happen before code
segment S2
Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
Because synch is initialized to 0, P2

is executed only after P1 has invoked
signal(sync), which is after statement S1
has been executed.
S <= 0 implies busy critical section/region or a process in CS
Semaphore Implementation: Busy waiting
● 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
● This implementation is based on busy waiting in critical section

implementation (that is, the code for wait() and signal())
● But implementation code is short
● Little busy waiting if critical section rarely occupied
● Can we implement semaphores with no busy waiting? YES. The

textbook has the answer.
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
typedef struct{
int value;
struct process *list;
} semaphore;
● 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
Operating Systems
Exercise:
Chapter 3
Continue… 59
Chapter 3 Operating Systems
60
Chapter 3 Operating Systems
61
Operating Systems
Example: Producer-Consumer
Initial values: mutex = 1, empty = n, full = 0 Problem
Producer Consumer
do { do {
…. wait(full); //dec full cnt
wait(mutex);
produce an item in nextp
…..
…. remove an item from buffer to nextc
wait(empty); //dec empty cnt ….
wait(mutex); signal(mutex);
…. signal(empty); //inc empty cnt
add nextp to buffer ….
…. consume the item in nextc
signal(mutex); ….
} while (TRUE);
Chapter 3
signal(full);//inc full cnt

} while (TRUE);
62
Operating Systems
Exercise:
Based on the previous example, fill in the

following table with the value of those
variables used.
Assume that initial value:

mutex = 1, empty = 5, full = 0
Producer : Consumer :
wait() signal() wait() signal()
empty empty
Chapter 3
mutex mutex
full full
63
Operating Systems
• The producer will start first since wait(empty=5)

and consumer with wait(full=0)
• Once producer update full=1, then consumer

proceed with all updated value by producer.
empty empty
Chapter 3
mutex mutex
full full
64
Operating Systems
Initial value: mutex = 1, empty = 5, full = 0
wait(empty=5) wait(full=1)
empty=4 full=0
wait(mutex=1) wait(mutex=1)
mutex=0 mutex=0
signal(mutex=0) signal(mutex=0)
mutex=1 mutex=1
signal(full=0) signal(empty=4)
full=1 empty=5
empty 4 empty 5
Chapter 3
mutex 0 1 mutex 0 1
full 1 full 0
65
6.6.3 Deadlock and Starvation
● Incorrect use of semaphore operations can produced:
● Deadlock – two or more processes are waiting indefinitely for an

event that can be caused by only one of the waiting processes
● Starvation – indefinite blocking
 A process may never be removed from the semaphore queue in
which it is suspended
Operating Systems
Summary
• Mutual exclusion
– Prevents deadlock
– Maintained with test-and-set, WAIT and
SIGNAL, and semaphores (P, V, and mutex)
• Synchronize processes using hardware and

software mechanisms
Chapter 3
67
Operating Systems
EXERCISE (DIY!!!)
Figure 1 shows the implementation of Producer-Consumer using Semaphores.
Supposed the initial values of the buffer size, N=8, mutex=1, empty=6 and full=2.
Complete the value of the appropriate mutex variables in Table below if the following
sequence of order is executed: consumer, consumer, producer. [6 marks]
Process Wait(full) Wait(mutex) Signal (mutex) Signal (empty)

Initia Value 2 1 6
Consumer
Consumer
Process Wait(empty) Wait(mutex) Signal (mutex) Signal (full)
Chapter 3
Producer
68
End of Chapter 6
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013

CH 6 Synchronization

Uploaded by

Copyright:

Available Formats

CH 6 Synchronization

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 6 Synchronization

Uploaded by

Copyright:

Available Formats

Chapter 6: Synchronization

● Concurrent access: accessing of the same data at the

Why a Race Condition Occurs?

Two processes may be :

client web browser requesting the resource.

• Suppose that we wanted to provide a solution that fills all

• To enable producer and consumer to be executed

 unbounded-buffer provides unlimited buffer size.

• Producer puts data in one slot while consumer

– producer needs to wait if buffer is full

while (counter == BUFFER_SIZE) ;

/* consume the item in next consumed */

• Both routines are correct if executed independently.

• However, it may give problem if run concurrently

(For Slide page 21-24:_________________________________________________________________

● If current counter = 5 and statements:

● Each statement consists of several machine instructions:

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

Synchronize problem (race condition)

Race Condition - Definition

* (Multithread normally access / used shared variables)

Solution to Race Condition

• Therefore process synchronization is needed.

• Synchronization is necessary to ensure that

● We need to make sure that:

● The ability to execute an instruction, or a number of instructions,

Atomic means one operation at a time

Based on a several machine instructions below that

Producer should update the counter just before

● General structure of process Pi

Figure 6.1 General structure of Process Entering the Critical Section

● Entry section to critical section is to “disable interrupts.

while (turn == j);

• Algorithm is correct. Only one process at a time in the critical

4 Types of locking mechanisms to solve CS problem:

1. Software defined (Strict Alternation, Flagging and Peterson)

2. Hardware support (Test-and-set and swap)

3. Support from the Operating System (Semaphore)

4. Support the programming language (Ada – rendevous)

● Good algorithmic software solution

● The variable turn indicates whose turn it is to enter the critical

do { ● Provable that the three CS

Initial SHARED values:

"I am ready to enter CS" flag[0]=true;

Entrance to the CS is granted for process P0

• if P1 does not want to enter its CS,

• if P1 has given priority to P0 by setting turn=0.

• Check if the following

Answer: Execution of algorithm

time flag[0] flag[1] turn Events

t7 FALSE FALSE 0 P0 executes RS0 1

t8 FALSE TRUE 0 P1 requests to enter CS1 2

Answer: Execution of algorithm

t7 FALSE FALSE 0 P0 executes RS0 1

t8 FALSE TRUE 0 P1 requests to enter CS1 2

Table shows a process that can enter its CS for

flag[0] flag[1] turn Process that can

t17 TRUE TRUE 1 P0 busy waiting in loop

t18 TRUE FALSE 1 P1 executes RS1