advertisement

CIS 540 Principles of Embedded Computation Spring 2015 http://www.seas.upenn.edu/~cis540/ Instructor: Rajeev Alur [email protected] Asynchronous Execution P P2 P1 in x out y What can happen in a single step of this asynchronous model P? P1 synchronizes with the environment to accept input on in P2 synchronizes with the environment to send output on out P1 performs some internal computation (one of its internal tasks) P2 performs some internal computation (one of its internal tasks) P1 produces output on channel x, followed by its consumption by P2 P2 produces output on channel y, followed by its consumption by P1 CIS 540 Spring 2015; Lecture Feb 23 Shared Memory Programs AtomicReg nat x := 0 Process P1 nat y1:=0 y1 := x x := y1 +1 Process P2 nat y2:=0 y2 := x x := y2 +1 Declaration of shared variables + Code for each process Key restriction: Each statement of a process either changes local variables, reads a single shared var, or writes a single shared var Execution model: execute one step of one of the processes Can be formalized as asynchronous processes CIS 540 Spring 2015; Lecture Feb 23 Shared Memory Processes x.write2 x.write1 x.read1 P1 x y.write2 y.write1 y.read1 x.read2 y P2 y.read2 Processes P1 and P2 communicate by reading/writing shared variables Each shared variable can be modeled as an asynchronous process State of each such process is the value of corresponding variable In implementation, shared memory can be a separate subsystem Read and write channel between each process and each shared variable To write x, P1 synchronizes with x on “x.write1” channel To read y, P2 synchronizes with y on “y.read2” channel CIS 540 Spring 2015; Lecture Feb 23 Atomic Registers x.write2 x.write1 x.read1 P1 x y.write2 y.write1 y.read1 x.read2 y P2 y.read2 By definition of our asynchronous model, each step of above is either internal to P1 or P2, or involves exactly one synchronization: either read or write of one shared variable by one of the processes Atomic register: Basic primitives are read and write To “increment” such a register, a process first needs to read and then write back incremented value But these two are separate steps, and register value can be changed in between by another process CIS 540 Spring 2015; Lecture Feb 23 Shared Memory Programs AtomicReg nat x := 0 Process P1 nat y1:=0 y1 := x x := y1 +1 Process P2 nat y2:=0 y2 := x x := y2 +1 Declaration of shared variables + Code for each process Key restriction: Each statement of a process either changes local variables, reads a single shared var, or writes a single shared var Execution model: execute one step of one of the processes Can be formalized as asynchronous processes CIS 540 Spring 2015; Lecture Feb 23 Data Races AtomicReg nat x := 0 Process P1 Process P2 nat y1:=0 nat y2:=0 R1: y1 := x R2: y2 := x W1: x := y1 +1 W2: x := y2 +1 What are the possible values of x after all steps are executed? x can be 1 or 2 Possible executions: R1, R2, W1, W2 R1, W1, R2, W2 R1, R2, W2, W1 R2, R1, W1, W2, R2, W2, R1, W1 R2, R1, W2, W1 Data race: Concurrent accesses to shared object where the result depends on order of execution, Should be avoided!! CIS 540 Spring 2015; Lecture Feb 23 Puzzle AtomicReg nat x := 1 Process P2 Process P1 nat u2,v2 nat u1,v1 u2 := x u1 := x x := u2 + v2 x := u1 + v1 v1 := x v2 := x What possible values can the shared register x take? CIS 540 Spring 2015; Lecture Feb 23 Mutual Exclusion Problem Process P2 Process P1 To be designed Entry Code Critical Section Entry Code Critical Section Critical Section: Part of code that an asynchronous process should execute without interference from others Critical section can include code to update shared objects/database Mutual Exclusion Problem: Design code to be executed before entering critical section by each process Coordination using shared atomic registers No assumption about how long a process stays in critical section A process may want to enter critical section repeatedly CIS 540 Spring 2015; Lecture Feb 23 Mutual Exclusion Problem Process P1 Process P2 To be designed Entry Code Critical Section Entry Code Critical Section Safety Requirement: Both processes should not be in critical section simultaneously (can be formalized using invariants) Absence of deadlocks: If a process is trying to enter, then some process should be able to enter CIS 540 Spring 2015; Lecture Feb 23 Mutual Exclusion: First Attempt AtomicReg bool flag1 := 0; flag2 := 0 Process P1 else Idle flag1 := 1 flag2=0 ? Try Crit flag1 := 0 Is this correct? Process P2 else Idle flag2 := 1 Try flag1=0 ? Crit flag2 := 0 CIS 540 Spring 2015; Lecture Feb 23 Peterson’s Mutual Exclusion Protocol AtomicReg bool flag1 := 0; flag2 := 0; {1,2} turn Process P1 else Idle flag1 := 1 Try1 turn := 1 Try2 flag2=1? Try3 turn=2 ? Crit else flag1 := 0 Process P2 else Idle flag2 := 1 Try1 turn := 2 Try2 flag1=1? Try3 else flag2 := 0 CIS 540 Spring 2015; Lecture Feb 23 turn=1 ? Crit Test&Set Register Beyond atomic registers: In one (atomic) step, can do more than just read or write Stronger synchronization primitives Test&Set Register: Holds a Booleans value Reset operation: Changes the value to 0 Test&Set operation: Returns the old value and changes value to 1 If two processes are competing to execute Test&Set on a register with value 0, one will get back 0 and other will get back 1 Modern processors support strong “atomic” operations Compare-and-swap Load-linked-store-conditional Implementation is expensive (compared to read/write operations)! CIS 540 Spring 2015; Lecture Feb 23 Mutual Exclusion using Test&Set Register Test&SetReg free:= 0 Process P1 else Idle t&s(free)=0 ? Try Crit reset(free) Is this correct? Process P2 else Idle Try t&s(free)=0 ? Crit reset(free) CIS 540 Spring 2015; Lecture Feb 23 Another Look at Asynchronous Execution Model nat x:=0; y:=0 Ax: x := x+1 Ay: y :=y+1 Tasks Ax and Ay execute in an arbitrary order Motivation: If we establish that all possible executions of this asynchronous design satisfy some requirement, then this will hold in every implementation of this Are the following realistic executions? (0,0) -Ax-> (1,0) -Ax-> (2,0) -Ax-> (3,0) … -Ax-> (105,0) -Ax-> … (0,0) -Ax-> (1,0) -Ax-> (2,0) -Ay-> (2,1) -Ay-> (2,2) … -Ay-> (2,105) -Ay->… Does the system satisfy the following requirement: “In every execution, values of both x and y eventually exceed 10” CIS 540 Spring 2015; Lecture Feb 23 Fairness Assumption nat x:=0; y:=0 Ax: x := x+1 Ay: y :=y+1 Fairness assumption for a task Assumption about the underlying platform/scheduler Informally, an infinite execution is unfair for a task if the task does not get a chance to execute Unfair to Ay: (0,0) -Ax-> (1,0) -Ax-> (2,0) -Ax-> (3,0) … -Ax-> (105,0) … Unfair to Ax: (0,0) -Ax-> (1,0) -Ax-> (2,0) -Ay-> (2,1) -Ay-> (2,2) … (2,105)… Fairness assumptions restrict the set of “possible” executions to realistic ones without putting concrete bounds on relative speeds CIS 540 Spring 2015; Lecture Feb 23 Formalizing Fairness Process P1 Process P2 nat x:=0; y:=0 nat x:=0; y:=0 Ax: x := x+1 Bx: x := x+1 Ay: y :=y+1 By: x=0 y :=y+1 Definition 1: An infinite execution is fair to a task A, if the task A is executed repeatedly (i.e. infinitely often) during this execution Is this fair to task By of P2? (0,0) -Bx-> (1,0) -Bx-> (2,0) -Bx-> (3,0) -Bx-> … (105,0) -Bx-> … After first step, the task By is not enabled, and thus, cannot be executed. So this execution is a possible execution, and so should be considered fair Definition 2: An infinite execution is fair to a task A, if repeatedly, either task A is executed or is disabled CIS 540 Spring 2015; Lecture Feb 23 Weak vs Strong Fairness Process P3 nat x:=0; y:=0 Ax: x := x+1 Ay: even(x) y :=y+1 Is this fair to task Ay of P3? (0,0) -Ax-> (1,0) -Ax-> (2,0) -Ax-> (3,0) … -Ax-> (105,0) -Ax-> … Task Ay is not continuously enabled, and thus, this is fair according to definition 2 (called weak fairness) Definition 3 (Strong fairness): An infinite execution is fair to a task A, if task A is either executed repeatedly, or disabled from a certain step onwards Above execution is weakly-fair to task Ay, but not strongly-fair CIS 540 Spring 2015; Lecture Feb 23 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 execution must be weakly-fair for task A If strong-fairness is assumed for a task A, then the execution 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 23 Requirements under Fairness Assumptions Process P1 Process P3 nat x:=0; y:=0 nat x:=0; y:=0 Ax: x := x+1 Bx: x := x+1 Ay: y :=y+1 By: even(x) y :=y+1 Under what fairness assumptions do P1 and P3 satisfy following? Requirement: Eventually (x+y > 10) Both satisfy this without any fairness assumption Requirement: Eventually (x > 10) P1 with weak-fairness for Ax, P3 with weak-fairness for Bx Requirement: Eventually (y > 10) P1 with weak-fairness for Ay, P3 with strong-fairness for By Requirement: Eventually (x > y) Not satisfied, no matter what fairness assumption we make! CIS 540 Spring 2015; Lecture Feb 23