Bakery Algorithm - Proof OS Winter’06

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

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

Bakery algorithm for n processes OS Winter’03

Bakery algorithm for n processes D T-D C E OS Winter’03

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

Basic Lemma Lemma 1: OS Winter’03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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