The document discusses the critical section problem in operating systems where multiple processes need exclusive access to shared resources. It defines the requirements of mutual exclusion, progress, and bounded waiting. It then analyzes several algorithms to solve the problem for two processes, finding that Peterson's algorithm satisfies all requirements. The document also presents the Bakery algorithm to generalize the solution to n processes using ticket numbers. It notes software solutions have drawbacks like busy waiting and discusses how failures could impact the solutions.

1. A. Frank - P. Weisberg
Operating Systems
The Critical-Section
Problem

2. 2 A. Frank - P. Weisberg
Cooperating Processes
• Introduction to Cooperating Processes
• Producer/Consumer Problem
• The Critical-Section Problem
• Synchronization Hardware
• Semaphores

3. 3 A. Frank - P. Weisberg
The Critical-Section Problem
• n processes competing to use some shared data.
• No assumptions may be made about speeds or
the number of CPUs.
• Each process has a code segment, called
Critical Section (CS), in which the shared data
is accessed.
• Problem – ensure that when one process is
executing in its CS, no other process
is allowed to execute in its CS.

4. 4 A. Frank - P. Weisberg
CS Problem Dynamics (1)
• When a process executes code that manipulates
shared data (or resource), we say that the
process is in it’s Critical Section (for that
shared data).
• The execution of critical sections must be
mutually exclusive: at any time, only one
process is allowed to execute in its critical
section (even with multiple processors).
• So each process must first request permission
to enter its critical section.

5. 5 A. Frank - P. Weisberg
CS Problem Dynamics (2)
• The section of code implementing this request is
called the Entry Section (ES).
• The critical section (CS) might be followed by a
Leave/Exit Section (LS).
• The remaining code is the Remainder Section (RS).
• The critical section problem is to design a protocol
that the processes can use so that their action will not
depend on the order in which their execution is
interleaved (possibly on many processors).

6. 6 A. Frank - P. Weisberg
General structure of process Pi (other is Pj)
do {
entry section
critical section
leave section
remainder section
} while (TRUE);
• Processes may share some common variables
to synchronize their actions.

7. 7 A. Frank - P. Weisberg
Solution to Critical-Section Problem
• There are 3 requirements that must stand for a
correct solution:
1. Mutual Exclusion
2. Progress
3. Bounded Waiting
• We can check on all three requirements in
each proposed solution, even though the
non-existence of each one of them is enough
for an incorrect solution.

8. 8 A. Frank - P. Weisberg
Solution to CS Problem – Mutual Exclusion
1. Mutual Exclusion – If process Pi is executing
in its critical section, then no other processes
can be executing in their critical sections.
• Implications:
 Critical sections better be focused and short.
 Better not get into an infinite loop in there.
 If a process somehow halts/waits in its critical
section, it must not interfere with other processes.

9. 9 A. Frank - P. Weisberg
Solution to CS Problem – Progress
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 process that will enter the
critical section next cannot be postponed
indefinitely:
• If only one process wants to enter, it should be
able to.
• If two or more want to enter, one of them should
succeed.

10. 10 A. Frank - P. Weisberg
Solution to CS Problem – Bounded Waiting
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.

11. 11 A. Frank - P. Weisberg
Types of solutions to CS problem
• Software solutions –
– algorithms who’s correctness does not rely on any
other assumptions.
• Hardware solutions –
– rely on some special machine instructions.
• Operating System solutions –
– provide some functions and data structures to the
programmer through system/library calls.
• Programming Language solutions –
– Linguistic constructs provided as part of a language.

12. 12 A. Frank - P. Weisberg
Software Solutions
• We consider first the case of 2 processes:
– Algorithm 1 and 2/3 are incorrect.
– Algorithm 4 is correct (Peterson’s algorithm).
• Then we generalize to n processes:
– The Bakery algorithm.
• Initial notation:
– Only 2 processes, P0 and P1
– When usually just presenting process Pi (Larry, I, i),
Pj (Jim, J, j) always denotes other process (i != j).

13. 13 A. Frank - P. Weisberg
Initial Attempts to Solve Problem
• General structure of process Pi (other is Pj) –
do {
entry section
critical section
leave section
remainder section
} while (TRUE);
• Processes may share some common variables
to synchronize their actions.

14. 14 A. Frank - P. Weisberg
Algorithm 1 – Larry/Jim version
• Shared variables:
– string turn; initially turn = “Larry” or “Jim” (no matter)
– turn = “Larry”  Larry can enter its critical section
• Process Larry
do {
while (turn != “Larry”);
critical section
turn = “Jim”;
remainder section
} while (TRUE);
• Jim’s version is similar but “Larry”/“Jim” reversed.

15. 15 A. Frank - P. Weisberg
Algorithm 1 – Pi/Pj version
• Shared variables:
– int turn; initially turn = 0
– turn = i  Pi can enter its critical section
• Process Pi
do {
while (turn != i);
critical section
turn = j;
remainder section
} while (TRUE);
• Satisfies mutual exclusion and bounded waiting, but
not progress.

16. 16 A. Frank - P. Weisberg
Algorithm 2 – Larry/Jim version
• Shared variables
– boolean flag-larry, flag-jim;
initially flag-larry = flag-jim = FALSE
– flag-larry= TRUE  Larry ready to enter its critical
section
• Process Larry
do {
while (flag-jim);
flag-larry = TRUE;
critical section
flag-larry = FALSE;
remainder section
} while (TRUE);

17. 17 A. Frank - P. Weisberg
Algorithm 2 – Pi/Pj version
• Shared variables
– boolean flag[2]; initially flag [0] = flag [1] = FALSE
– flag [i] = TRUE  Pi ready to enter its critical section
• Process Pi
do {
while (flag[j]);
flag[i] = TRUE;
critical section
flag [i] = FALSE;
remainder section
} while (TRUE);
• Satisfies progress, but not mutual exclusion and
bounded waiting requirements.

18. 18 A. Frank - P. Weisberg
Algorithm 3 – Larry/Jim version
• Shared variables
– boolean flag-larry, flag-jim;
initially flag-larry = flag-jim = FALSE
– flag-larry= TRUE  Larry ready to enter its critical
section
• Process Larry
do {
flag-larry = TRUE;
while (flag-jim);
critical section
flag-larry = FALSE;
remainder section
} while (TRUE);

19. 19 A. Frank - P. Weisberg
Algorithm 3 – Pi/Pj version
• Shared variables
– boolean flag[2]; initially flag [0] = flag [1] = FALSE
– flag [i] = TRUE  Pi wants to enter its critical section
• Process Pi
do {
flag[i] = TRUE;
while (flag[j]);
critical section
flag [i] = FALSE;
remainder section
} while (TRUE);
• Satisfies mutual exclusion, but not progress and
bounded waiting (?) requirements.

20. 20 A. Frank - P. Weisberg
Algorithm 4 – Larry/Jim version
• Combined shared variables of algorithms 1 and 2/3.
• Process Larry
do {
flag-larry = TRUE;
turn = “Jim”;
while (flag-jim and turn == “Jim”);
critical section
flag-larry = FALSE;
remainder section
} while (TRUE);

21. 21 A. Frank - P. Weisberg
Algorithm 4 – Pi/Pj version
• Combined shared variables of algorithms 1 and 2/3.
• Process Pi
do {
flag [i] = TRUE;
turn = j;
while (flag [j] and turn == j);
critical section
flag [i] = FALSE;
remainder section
} while (TRUE);
• Meets all three requirements; solves the critical-section
problem for two processes.

22. 22 A. Frank - P. Weisberg
Algorithm 5 – Larry/Jim version
• Like Algorithm 4, but with the first 2 instructions of
the entry section swapped – is it still a correct solution?
• Process Larry
do {
turn = “Jim”;
flag-larry = TRUE;
while (flag-jim and turn == “Jim”);
critical section
flag-larry = FALSE;
remainder section
} while (TRUE);

23. 23 A. Frank - P. Weisberg
Bakery Algorithm (1)
• Critical Section for n processes:
– Before entering its critical section, a process
receives a number (like in a bakery). Holder of the
smallest number enters the critical section.
– The numbering scheme here always generates
numbers in increasing order of enumeration;
i.e., 1,2,3,3,3,3,4,5...
– If processes Pi and Pj receive the same
number, if i < j, then Pi is served first;
else Pj is served first (PID assumed unique).

24. 24 A. Frank - P. Weisberg
Bakery Algorithm (2)
• Choosing a number:
– max (a0,…, an-1) is a number k, such that k  ai for
i = 0, …, n – 1
• Notation for lexicographical order (ticket #, PID #)
– (a,b) < (c,d) if a < c or if a == c and b < d
• Shared data:
boolean choosing[n];
int number[n];
Data structures are initialized to FALSE and 0,
respectively.

25. 25 A. Frank - P. Weisberg
Bakery Algorithm for Pi
do {
choosing[i] = TRUE;
number[i] = max(number[0], …, number[n – 1]) +1;
choosing[i] = FALSE;
for (j = 0; j < n; j++) {
while (choosing[j]) ;
while ((number[j] != 0) &&
((number[j],j) < (number[i],i))) ;
}
critical section
number[i] = 0;
remainder section
} while (TRUE);

26. 26 A. Frank - P. Weisberg
What about process failures?
• If all 3 criteria (ME, progress, bounded waiting)
are satisfied, then a valid solution will provide
robustness against failure of a process in its
remainder section (RS).
– since failure in RS is just like having an infinitely
long RS.
• However, no valid solution can provide
robustness against a process failing in its
critical section (CS).
– A process Pi that fails in its CS does not signal that
fact to other processes: for them Pi is still in its CS.

27. 27 A. Frank - P. Weisberg
Drawbacks of software solutions
• Software solutions are very delicate .
• Processes that are requesting to enter their
critical section are busy waiting
(consuming processor time needlessly).
– If critical sections are long, it would be more
efficient to block processes that are waiting.