1. Bakery Algorithm - Proof
OS Winter’06

2. Bakery algorithm of Lamport
Critical section algorithm for any n>1
Each time a process is requesting an entry to CS, assign it a ticket which is
Unique and monotonically increasing
Let the process into CS in the order of their numbers
OS Winter’03

3. Choosing a ticket Does not guarantee uniqueness! Use process Ids:
Process need to know that somebody perhaps
chose a smaller number:
OS Winter’03

4. Bakery algorithm for n processes
OS Winter’03

5. Bakery algorithm for n processesD
T-D C E
OS Winter’03

6. Structure of the algorithm
R – code prior to using Bakery algorithm
T – creating of a ticket and awaiting for permission to enter critical section
D – creation of a number (first part of a ticket)
T-D – awaiting for the permission to enter critical section
C – critical section itself
E – code executed upon exit from critical section
OS Winter’03

7. Basic Lemma
Lemma 1:
OS Winter’03

8. Lemma 1 - proof Denote ‘s’ time point where lemma’s conditions hold
At time ‘s’, is in C (critical section)
number[i] has been selected and still exists
number[j] has been selected and still exists
Exist time point ‘t1’<‘s’, where performs a check (choosing[j]==0) and passes it
Exists time point ‘t2’, t1<t2<s, where performs a check
(number[j]!=0) and (number[i],i)<(number[j],j)
OS Winter’03

9. Lemma 1 – proof (cont)
Since at time ‘t1’ exists (choosing[j]==0) one of the following has to be true
CASE A: number[j] was chosen after time ‘t1’ and before time ‘s’
CASE B: number[j] was chosen before ‘t1’
OS Winter’03

10. Lemma 1 – proof – CASE A
Since at time ‘t1’ already checks for permission to enter critical section, computation of number[i] was computed before that and persists until ‘s’
Thus, at the time starts to compute its number[j], it has to take into account of ‘max’ value of number[i]. So it creates a value which is greater then number[i] at least by 1, and it persists until time ‘s’
That is (number[i],i)<(number[j],j) at time ‘s’
OS Winter’03

11. Lemma 1 – proof – CASE B
Both number[i] and number[j] were computed before ‘t1’, thus also before time ‘t2’ and persisted until ‘s’
At time ‘t2’ performed check (number[j]!=0) & (number[j],j)<(number[i],i), which failed, since is in C at time ‘s’
number[j] was chosen before ‘t2’ and persisted, thus first part of the check could not fail, also ‘i’ and ‘j’ are different, so
(number[i],i)<(number[j],j) at time ‘s’
OS Winter’03

12. Lemmata 2,3,4 Lemma 2 – mutual exclusion: Lemma 3 – progress
Bakery Algorithm satisfies mutual exclusion property
Lemma 3 – progress
Bakery Algorithm guarantees progress
Lemma 4 – fairness
Bakery Algorithm guarantees lockout-freedom
OS Winter’03

13. Lemma 2 – Proof
Assume in contradiction that there are two different processes that have entered critical section
Then conditions of Lemma 1 are true for both processes simmetrically that is (number[i],i)<(number[j],j]) and (number[j],j)<(number[i],i) : contradiction
We conclude that mutual exclusion is satisfied
OS Winter’03

14. Lemma 3 – Proof Suppose progress is not guaranteed
Then eventually a point is reached after which all processes are in T or R
By the code, all the processes in T eventually complete D and reach T-D
Then the process with the lowest (number,ID) pair is not blocked from reaching C, that is enters critical section
We conclude that Bakery algorithm satisfies Progress
OS Winter’03

15. Lemma 4 – Proof
Consider a particular process in T and suppose it never reaches C
The process eventually completes D and reaches T-D
After that any new process that enters D perceives number[i] and chooses a higher number
Thus, since does not reach C, none of these new processes reach C either
But by Lemma 3 there must be continuing progress, that is infinitely many entries to C
Contradiction: blocks the entry to C
OS Winter’03

16. Remark on Fairness
A process that obtained a ticket (number[k],k) will wait at most for (n-1) turns, when other processes will enter the critical section
For example if all the processes obtained their tickets at the same time they will look like (q,1),(q,2)…(q,n)
In which case process will wait for processes
… to complete the critical section
OS Winter’03

17. Bibliography Nancy Ann Lynch, “Distributed Algorithms”, JMC 243.9 LY53
Leslie Lamport
“A new solution of Dijkstra’s concurrent programming problem”
Communications of the ACM
17(8): , 1974
OS Winter’03

18. Hardware primitives
Elementary building blocks capable of performing certain steps atomically
Should be universal to allow for solving versatile synchronization problems
Numerous such primitives were identified:
Test-and-set
Fetch-and-add
Compare-and-swap
OS Winter’03

19. Test-and-Set (TS) boolean test-and-set(boolean &lock) { temp=lock;
lock=TRUE;
return temp; }
reset(boolean &lock)
lock=FALSE;
OS Winter’03

20. Critical section using TS
Shared boolean lock, initially FALSE
do {
while(test-and-set(&lock));
critical section;
reset(&lock);
reminder section;
} while(1);
Check yourself!
Is mutual exclusion satisfied?
Is progress satisfied?
Is fairness satisfied?
OS Winter’03

21. Discussion Satisfies Mutual Exclusion and Progress
Does not satisfies Fairness
Provides exclusion among unbounded number of processes
Process IDs and number are unknown
Busy waiting
Burning CPU cycles while being blocked
OS Winter’03

22. Fetch-and-Add (FAA) s: shared, a: local int FAA(int &s, int a) {
temp=s;
s=s+a;
return temp; }
FAA can be used
as a ticket machine
OS Winter’03

23. Critical section using FAA
Shared: int s, turn;
Initially: s = 0; turn=0;
Process Pi code:
Entry:
me = FAA(s,1);
while(turn < me); // busy wait for my turn
Critical section
Exit:
FAA(turn,1);
Check yourself!
Is mutual exclusion satisfied?
Is progress satisfied?
Is fairness satisfied?
OS Winter’03

24. Discussion Satisfies all three properties
Supports unbounded number of processes
Unbounded counter
Busy waiting
OS Winter’03

25. Problems with studied synchronization methods
Critical section framework is inconvenient for programming
Performance penalty
Busy waiting
Too coarse synchronization
Using hardware primitives directly results in non-portable code
OS Winter’03