Chapter 3
The Critical Section
Problem
1
Producer - Consumer Problem
Producer Process
Consumer Process
Produce
Get from buffer
Put in buffer
Consume
BUFFER

Buffer is shared (ie., it is a shared variable)
2
Progress in time…..
Producer
p1
1
p2
2
p3
3
Buffer
p4
4
3 instead of 2!
Consumer
1

c1
2
c2
t
Both processes are started at the same time and
consumer uses some old value initially
3
A Race Condition



Because of the timing and which process starts first
There is a chance that different executions may end up
with different results
That is, because of interleaving, we can not predict
what will happen next when processes are executing
4
Why Processes Need to
Communicate?

To synchronize their executions

To exchange data and information
5
Critical Sections

Critical Section


A section of code in which a process accesses and
modifies shared variables
Mutual Exclusion

A method of prevention to ensure that one (or a
specified number) of process(es) is/are in a critical
section
6
Mutual Exclusion Problem
Program producerconsumer;
Procedure producer;
begin
repeat
produce;
putinbuffer;
critical section
until false;
End;
Procedure consumer;
Begin
repeat
getfrombuffer;
consume;
critical section
until false;
End;
Begin (* main program *)
cobegin producer; consumer coend
End.
7
Critical Section


A critical section in the procedure of a process is
the section in which the process refers and changes
common variables (which are shared by other
processes)
There may be several critical sections operating on
the same or different common variables in a process
8
Rules to Form Critical Sections

No two processes may be simultaneously inside their CS -

No assumptions are made about relative process speeds or
number of CPUs - (Race Conditions)
No process can remain inside a CS indefiniely (CS must be
small in code and it’s execution must take minimal time) -

(Rule of Mutual Exclusion)
(Rule of Deadlock and Starvation)

A process outside a CS should not block other processes -

No process should wait forever before entering its CS (When a
process leaves a CS, the process manager must activate a
waiting process to enter its CS. Processes waiting to enter a
CS usually wait in a queue maintained in a FIFO manner or
by a priority rule) - (Rule of Starvation)
(Rule of Deadlock and Starvation)
9
Correctness Specification

Correctness specifications required for a solution are :
Mutual exclusion : Statements from the critical sections
of two or more processes must not be interleaved
 Freedom from Deadlock : If some processes are trying to
enter their critical sections, then one of them must
eventually succeed
 Freedom from Starvation : If any process tries to enter its
critical section, then that process must eventually succeed

10
Synchronization


A synchronization mechanism (synchronization primatives)
must be provided to handle the critical section problem
This synchronization mechanism consists of additional
statements that are placed before and after a critical section
(preprotocol and postprotocol)
11
First Attempt
(Critical Section Problem for two processes)
Program mutualexclusion;
Var turn : integer;
Procedure P;
begin
repeat
non-critical section;
repeat (* do nothing *) until turn = 1;
critical section;
turn := 2;
(* busy wait while P2 is in CS*)
until false;
End;
Procedure Q;
Begin
repeat
non-critical section;
repeat (* do nothing *) until turn = 2;
critical section;
turn := 1;
(* busy wait while P1 is in CS *)
until false;
End;
Begin (* main program *)
turn := 1; (* we start with P1 *)
cobegin P; Q coend
End.
12
Comments




Do (* nothing *) is implemented by timeslicing (process
loops in the while instruction )
Solution satisfies mutual exclusion, since only one process
can be in CS
Deadlock is not possible. Both processes can never be stuck
at the while statement
Process starvation is possible, if a process spends a lot of
time in its non-critical section. Here we assume that the
other process is busy waiting to enter the critical section. If
processes spend finite times in non-critical sections then
there will be no starvation
13
Drawback


The processes are not loosely connected. That is, the
right to enter a CS is being explicitly passed from
one process to another
Suppose process P is waiting to enter the CS. If
something happens to process Q while inside the
non-critical section, process P is hopelessly
deadlocked after the next pass
14
First Attempt Using Book’s Convention

Await is blocking wait not a busy wait loop
15
Proving Correctness with
State Diagrams



In the first attempt, states are triples of the form (pi,qj,turn)
Variables used in the non-critical and critical sections are
assumed to be distinct from the variables used in the
protocols so that they have no effect at the correctness of
the solution. So, they are left out of the states
The mutual exclusion correctness property holds if the set of
all accessible states does not contain a state of the form
(p3,q3,turn) for some value of turn, because p3 and q3 are
the labels of the critical sections
16
State Diagrams

How many states can be in a state diagram?
Suppose the algorithm has N processes with ni statements
in process i, and M variables where variable j has mj
possible values.
 The number of possible states is

n1 x ... x nN x m1 x ... x mM

For the first attempt, the number of states is 4x4x2=32
since we have 4 statements per process and turn can be 1
or 2
17
State Diagram of the First Attempt




The initial state is (p1,q1,1)
Lefthand side is P executing,
righthand side is Q executing
The incremental construction
terminates after 16 of the 32
possible states have been
constructed
We do not have states
(p3,q3,1) or (p3,q3,2) so
mutual exclusion property
for correctness holds for
the first attempt
18
Abbreviating the State Diagram


Statements executed in the non-critical and critical sections
are irrelevant to the correctness of the synchronization
algorithm. So, they are eliminated
In fact, you can think of p as



p1: non-critical section; await turn = 1
p2: critical section; turn <- 2
Now we have 4 states to consider
19
Correctness of the First Attempt



Mutual exclusion property holds (see the state
diagram)
Is the algorithm deadlock free?
Which means : If some processes are trying to enter
their critical sections, then one of them must
eventually succeed
20
Is it Deadlock Free?






A process is trying to enter its CS if it
is executing p1 or q1
Consider the initial state. Turn is 1,
which means p1 passes through and
q1 loops on
Next state is the lower right. Here p2
executes CS and eventually sets turn to
2. While it is in the CS, Q is executing
q1
Next state is upper left in which Q
enters its CS.
Turn value decides which process
should enter the CS
Both processes eventually enter their
CS in a mutually exclusive manner.
Hence, the property of freedom from
deadlock is satisfied
21
Is it Starvation Free?





Consider a section of the
original state diagram. NCS
stands for a non-critical section
The state on the lower left is
the one in which p2 is waiting
to enter its CS and q1 is in the
NCS
If process Q decides to stay in
its NCS (or broken down), P
can not enter its CS so starve
Hence,
freedom
from
starvation property does not
hold for this solution
Second attempt tries to solve it
22
Second Attempt



Each process has its own flag which is true when process is in CS (p3,
q3 and p5, q5)
The other process waits until this process leaves the CS (p2, q2)
If a process halts in its NCS then the other proceeds independently.
23
Second Attempt (Abbreviated)
24
State Diagram for Abbreviated
Algorithm


The last state (p3,q3, true,true) means that both processes enter CS at the same time
Mutual exclusion property does not hold
25
A Scenario Showing that Mutual
Exclusion Does Not Hold
26
Second Attempt (for jBACI)
Program secondattempt;
Var c1, c2 : integer;
Procedure p;
Begin
repeat
while c2 = 0 do;
c1 := 0;
CS;
c1 := 1;
NCS;
until false;
End;
Procedure q;
Begin
repeat
while c1 = 0 do;
c2 := 0;
CS;
c2 := 1;
NCS;
until false;
End;
Begin (* main program *)
c1:= 1; c2:= 1; (* Both processes are not in their CS *)
cobegin p; q coend
End.
loop on while p2 is in CS
process is entering the CS
process leaves the CS
if p2 breaks down here,
p1 can still execute since it has its own flag c1
27
Comments & Correctness



Each
process
periodically
checks the other’s common
variable cx. If the other process
is not in CS (ie., cx = 1); the
other process enters its CS, sets
its flag c to 0 to indicate that it
will enter its CS
This program may not work
correctly if events are as shown
in the table
We have no mutual exclusion so
deadlock!
c1
c2
initially
1
1
P1 checks c2
1
1
P2 checks c1
1
1
P1 sets c1
0
1
P2 sets c2
0
0
P1 enters CS
0
0
P2 enters CS
0
0
Both processes are in CS
0
0
28
Third Attempt



This algorithm is a modification of the second attempt
Here, “await” statements become a part of the CS
Algorithm satisfies mutual exclusion (prove it yourself!)
29
Scenario for a Deadlock


Both processes are locked at p3 and q3
The situation is a deadlock case but we may call it a livelock since processes are
actively executing statements but nothing useful is done
30
Third Attempt (In jBACI)
Program thirdattempt;
Var c1, c2 : integer;
Procedure p1;
Begin
repeat
c1 := 0;
while c2 = 0 do;
CS;
c1 := 1;
NCS;
until false;
End;
Procedure p2;
Begin
repeat
c2 := 0;
while c1 = 0 do;
CS;
c2 := 1;
NCS;
until false;
End;
Begin (* main program *)
c1:= 1; c2:= 1; (* Both processes are not in their CS *)
cobegin p1; p2, coend
End.
loop on while p2 is in CS
process is entering its CS
process leaves the CS
31
Comments & Correctness


The third solution is a
modification of the 2’nd
attempt. Here, the variable
cx (request to enter CS) is
set before checking the
other process whether it is
in CS or not
The solution is not correct
as shown in the events of
the table
c1
c2
initially
1
1
P1 sets c1
0
1
P2 sets c2
0
0
P1 enters CS
0
0
P2 enters CS
0
0
Both processes are in CS
0
0
32
Dekker’s Algorithm
33
Dekker’s Algorithm (in jBACI)
Program Dekker;
Var turn
: integer;
wantp, wantq
:boolean;
Procedure p;
Begin
repeat
wantp := true;
while wantq do if turn = 2 then begin wantp:= false; repeat until turn = 1; wantp:=true end;
CS;
turn := 2;
wantp:= false;
NCS;
until false;
End;
Procedure q;
Begin
repeat
wantq2 := true;
while wantp do if turn = 1 then begin wantq:= false; repeat until turn = 2; wantq:=false end;
CS;
turn := 1;
wantq := false;
NCS;
until false;
End;
Begin (* main program *)
turn:= 1; wantp:= false; wantq:= false;
cobegin p; q coend
End.
34
Explanation of the Algorithm
Procedure p;
Begin
repeat
wantp := true;
(* 1 *)
while wantq do if turn = 2 then begin wantp:= false; repeat until turn = 1; wantp:=true end;
CS;
turn := 2;
(* 3 *)
wantp := false;
(* 4 *)
NCS;
until false;
End;
1.
2.
3.
4.
(* 2 *)
Process makes a request to enter CS
If the other process had made a request to enter CS before and if it is its turn then

Take back the request to enter CS by setting the “want” variable to false”

Wait for the other process to exit CS and change the turn variable

Make a new request to enter CS and then enter CS
Flip the turn variable so that now the other process can enter CS
Set “want” variable to false to indicate that the process is now out of CS
35
Comments



Explicit control of transfer by a turn variable.
Hence; turn = 1 means P’s turn, turn = 2 Q’s turn
If a process is blocked, the other process can still go
Dekker’s algorithm is correct (prove it!)
It satisfies the mutual exclusion property
 It is free from deadlock and starvation

36