CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur

Fairness Assumption  Fairness assumption for an asynchronous process P: for each output and internal task:  No assumption,  Weak-fairness assumption, or  Strong-fairness assumption  Restricts the set of possible infinite executions  If weak-fairness is assumed for a task A, then the scheduler must be weakly-fair for task A  If strong-fairness is assumed for a task A, then the scheduler must be strongly-fair for task A  Affects whether the process meets a requirement:  Maybe not all executions satisfy the given requirement, but all fair executions satisfy the requirement CIS 540 Spring 2015; Lecture Feb 25

Asynchronous Merge What fairness assumptions should we make? msg in1 msg out queue(msg) x1 := null; x2 := null A1: ~Full(x1)  Enqueue(in1, x1) msg in2 A2: ~Full(x2)  Enqueue(in2, x2) B1: ~Empty(x1)  out := Dequeue(x1) B2: ~Empty(x2)  out := Dequeue(x2) Weak-fairness for output tasks B1 and B2 With this assumption, following requirement is satisfied: whenever an input message is received, it is eventually output Does not hold without fairness assumption, but weak-fairness suffices CIS 540 Spring 2015; Lecture Feb 25

Unreliable FIFO Tasks A and B1 model normal input/output behavior msg in msg out queue(msg) x := null A: Enqueue(in, x) B1: ~Empty(x)  out := Dequeue( x) B2: ~Empty(x)  Dequeue(x) B3: ~Empty(x)  out := Front(x) Task B2: Loss of message Task B3: Duplication of message What are “natural” fairness assumptions for these tasks? CIS 540 Spring 2015; Lecture Feb 25 Strong fairness for B1, no assumptions for B2 and B3

Fairness Assumptions for Mutual Exclusion Protocol AtomicReg bool flag1 := 0; flag2 := 0; {1,2} turn Process P1 Idle flag1 := 1 Try1 turn=2 ? Crit else flag1 := 0 turn := 1 Try2 Try3 flag2=1? else What fairness assumptions should we make? Weak-fairness for highlighted steps/tasks With this assumption, following requirement is satisfied: whenever a process wants to enter critical section, it eventually will. CIS 540 Spring 2015; Lecture Feb 25

Fairness Summary  Fairness assumption is an assumption made about the underlying platform or scheduler  Less the assumptions, the better  For each output and internal task, we can assume weak or strong fairness, as needed  Strong fairness needed if the task can switch between enabled and disabled due to execution of other tasks  Restricts the set of possible infinite executions, and allows satisfaction of more requirements  Does not affect the set of reachable states and safety properties  Fairness assumptions do not change underlying coordination  Key distinction: Fairness assumption for tasks (which ensure tasks get executed as expected) vs “fairness” requirements for protocols (which are about high-level goals of the problem being solved) CIS 540 Spring 2015; Lecture Feb 25

Puzzle AtomicReg nat x := 1 What possible values can x take? Process P1 nat u1,v1 u1 := x v1 := x x:=u1+v1 Process P2 nat u2,v2 u2 := x v2 := x x:=u2+v2 Every possible natural number ! u1:=1 v1:=1 x:=2 u1:=2 v1:=2 x:=4 u2:= 1 v2:=2 x:=3 u2:=3 v2:=4 x:=7 CIS 540 Spring 2015; Lecture Feb 25

Consensus  Each process starts with an initial preference value, known only to itself  Goal of coordination: Exchange information and arrive at a common decision value  Our focus: Two processes with Boolean preferences, and communicating by shared memory  Classical version: Byzentine Generals Problem communicating by messengers to decide on whether or not to attack  Processes P1 and P2 start with initial Boolean preferences v1 and v2, and arrive at Boolean decisions d1 and d2 so that 1.Agreement: d1 must equal d2 2.Validity: The decision value must equal either v1 or v2 3.Wait-freedom: At any time, if only one process is executed repeatedly, it reaches a decision (does not have to wait for the other, and thus, tolerant to failures) CIS 540 Spring 2015; Lecture Feb 25

First Attempt at Solving Consensus x1:= pref1 y1 := x2 AtomicReg {0,1,null} x1 := null; x2 := null Process P1 bool pref1, dec1 y1 := null if y1 != null then dec1 := (pref1 | y1) else dec1 := pref1 Process P2 bool pref2, dec2 x2 := pref2 y2 := x1 y2 := null if y2 != null then dec2 := (pref2 | y2) else dec2 := pref2 Write your value in a shared var, read other’s value, decide on OR of the values; but if the other has not written yet, choose your own initial value Agreement ? Validity ? Wait-freedom ? CIS 540 Spring 2015; Lecture Feb 25

Second Attempt at Solving Consensus x1:= pref1 y1 := x2 AtomicReg {0,1,null} x1 := null; x2 := null Process P1 bool pref1, dec1 y1 := null y1 != null  dec1 := (pref1 | y1) Write your value in a shared var, read other’s value, decide on OR of the values; but if the other has not written yet, read again! Agreement ? Validity ? Wait-freedom ? else Process P2 bool pref2, dec2 x2:= pref2 y2 := x1 y2 := null y2 != null  dec2 := (pref2 | y2) else CIS 540 Spring 2015; Lecture Feb 25

Solving Consensus  Solving consensus using only atomic registers is impossible!!  Primitives of read and write are too weak to achieve desired coordination while satisfying all 3 requirements  Intuitive difficulty:  When a process writes a shared variable, it does not know whether the other process has read this value, so cannot decide right away  When a process reads a shared variable, it needs to communicate to other process that it has seen this value, so needs to continue  Solution: Use stronger primitives: Test&Set registers  Byzantine Generals Problem: Impossible to achieve coordination  Sending a message, and receiving a message are similar to write and read operations CIS 540 Spring 2015; Lecture Feb 25

Consensus using Test&Set Register x1:= pref1 y1 := test&set(y) AtomicReg bool x1, x2; Test&SetReg y :=0 Process P1 bool pref1, dec1 y1 := 0 if y1 =0 then dec1 := pref1 else dec1 := x2 Write your value in a shared var; execute test&set; if you win, choose your own initial value, else read other’s preference as decision value Agreement ? Validity ? Wait-freedom ? Process P2 bool pref2, dec2 x2:= pref2 y2 := test&set(y) y2 := 0 if y2 = 0 then dec2 := pref2 else dec2 := x1 CIS 540 Spring 2015; Lecture Feb 25

Impossibility of Consensus  Theorem: There is no protocol for two process consensus such that 1.Processes communicate using only shared atomic registers 2.Protocol satisfies all of agreement, validity, and wait-freedom  Proof by contradiction: suppose there is such a protocol  Let us look at the underlying transition system T  A state of T looks like  A transition of T can be  a step by P1, and such a transition depends only on the first two parts of the state, or  a step by P2, which depends only on the last two parts of the state P1’s local stateP2’s local stateShared variables CIS 540 Spring 2015; Lecture Feb 25

Execution Tree of Transition System T P1 Vertices are states Left-child: Step by P1 Right-child: Step by P2 Protocol execution = Path in this tree P2 01 Tree must be finite (why?) Leaf-vertex: Protocol has terminated Label leaf with 0/1 based on decision 01 0-committed vertex: All paths lead to 0-labled leaves 1-committed vertex: All paths lead to 1-labeled leaves Uncommitted: Both decisions still possible All 0’sAll 1’s CIS 540 Spring 2015; Lecture Feb 25

Uncommittedness of Initial State P1 pref = 0P2 pref = 1shared Initial state s P1 ? sameP2 pref = 0same Initial state s’ = Slight variant of s P1 0 Decision must be 0 due to validity! These two executions are identical from P1’s perspective, So these two decisions must be the same; ? = 0 ! By symmetric argument, if we let only P2 execute in state s, it must decide on 1 This means the initial state s is uncommitted CIS 540 Spring 2015; Lecture Feb 25

Existence of Critical Vertices P1 1.There is an initial uncommitted state 2.All leaves are 0-committed or 1-committed 3.Tree is finite P2 01 All 0’sAll 1’s s It follows that there must exist a “critical” decision vertex s such that left-child is 0-committed and right- child is 1-committed CIS 540 Spring 2015; Lecture Feb 25

Existence of Critical Vertices P1P2 01 All 0’sAll 1’s s Whether P1 or P2 takes the next step is the deciding factor in state s: what can such a step be? Possible cases: 1. P1’s step is local or is read of a shared var 2. P2’s step is local or is read of a shared var 3. Both steps are writes to different shared vars 4. Both steps are writes to same shared var Proof by case analysis: in each case show that such steps cannot be decisive! CIS 540 Spring 2015; Lecture Feb 25

Example Proof: Case 2 P1 local P2 local shared Critical state s P1 unchanged changed unchanged P2 takes internal step or reads a shared variable P1 These two executions are identical from P1’s perspective, So these two decisions must be the same! Contradiction ! P1P2 01 All 0’sAll 1’s s CIS 540 Spring 2015; Lecture Feb 25

Logistics  Homework 3:  Exercises , 4.5, 4.8, 4.13, 4.19 (25 pts total)  Due: Monday (March 2)  Monday’s lecture:  Leader election  Reliable transmission  Midterm: Wed, March 5, in-class, open book/notes  Topics: chapters 2,3,4  See course webpage for last year’s midterm  Recitation: Fri noon  Midterm review session: Mon 4.30 – 5.30 DRLB 3C4 CIS 540 Spring 2015; Lecture Feb 25