Bakery Algorithm - Proof

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. Does not guarantee uniqueness! Use process Ids: Process need to know that somebody perhaps chose a smaller number: Choosing a ticket OS Winter’03

4. Bakery algorithm for n processes OS Winter’03

5. Bakery algorithm for n processes R T D 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: • 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):453-455, 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. boolean test-and-set(boolean &lock) { temp=lock; lock=TRUE; return temp; } reset(boolean &lock) { lock=FALSE; } Test-and-Set (TS) 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