Download presentation

Presentation is loading. Please wait.

Published byLauren Pardue Modified over 3 years ago

1
CIS 540 Principles of Embedded Computation Spring 2015 http://www.seas.upenn.edu/~cis540/ Instructor: Rajeev Alur alur@cis.upenn.edu

2
Asynchronous Execution 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 in x P1 out P2 y P CIS 540 Spring 2015; Lecture Feb 23

3
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

4
Shared Memory Processes 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 x.write1 P1 xy P2 y.write1 y.read2 y.write2 x.read2 x.write2 y.read1 x.read1 CIS 540 Spring 2015; Lecture Feb 23

5
Atomic Registers 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 x.write1 P1 xy P2 y.write1 y.read2 y.write2 x.read2 x.write2 y.read1 x.read1 CIS 540 Spring 2015; Lecture Feb 23

6
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

7
Data Races AtomicReg nat x := 0 Process P1 nat y1:=0 R1: y1 := x W1: x := y1 +1 Process P2 nat y2:=0 R2: y2 := x 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

8
Puzzle AtomicReg nat x := 1 What possible values can the shared register 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 CIS 540 Spring 2015; Lecture Feb 23

9
Mutual Exclusion Problem 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 Process P1 Entry Code Critical Section To be designed Process P2 Entry Code Critical Section CIS 540 Spring 2015; Lecture Feb 23

10
Mutual Exclusion Problem 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 Process P1 Entry Code Critical Section To be designed Process P2 Entry Code Critical Section CIS 540 Spring 2015; Lecture Feb 23

11
Mutual Exclusion: First Attempt AtomicReg bool flag1 := 0; flag2 := 0 Process P1 Idle flag1 := 1 Try flag2=0 ? Crit else flag1 := 0 Process P2 Idle flag2 := 1 Try flag1=0 ? Crit else flag2 := 0 Is this correct? CIS 540 Spring 2015; Lecture Feb 23

12
Peterson’s 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 Process P2 Idle flag2 := 1 Try1 turn=1 ? Crit else flag2 := 0 turn := 2 Try2 Try3 flag1=1? else CIS 540 Spring 2015; Lecture Feb 23

13
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

14
Mutual Exclusion using Test&Set Register Test&SetReg free:= 0 Process P1 IdleTry t&s(free)=0 ? Crit else reset(free) Is this correct? Process P2 Idle Try t&s(free)=0 ? Crit else reset(free) CIS 540 Spring 2015; Lecture Feb 23

15
Another Look at Asynchronous Execution Model nat x:=0; y:=0 A x : x := x+1 A y : y :=y+1 Tasks A x and A y 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) - A x -> (1,0) - A x -> (2,0) - A x -> (3,0) … - A x -> (105,0) - A x -> … (0,0) - A x -> (1,0) - A x -> (2,0) - A y -> (2,1) - A y -> (2,2) … - A y -> (2,105) - A y ->… 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

16
Fairness Assumption nat x:=0; y:=0 A x : x := x+1 A y : 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 A y : (0,0) - A x -> (1,0) - A x -> (2,0) - A x -> (3,0) … - A x -> (105,0) … Unfair to A x : (0,0) - A x -> (1,0) - A x -> (2,0) - A y -> (2,1) - A y -> (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

17
Formalizing Fairness 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 B y of P2? (0,0) - B x -> (1,0) - B x -> (2,0) - B x -> (3,0) - B x -> … (105,0) - B x -> … After first step, the task B y 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 nat x:=0; y:=0 A x : x := x+1 A y : y :=y+1 Process P1 nat x:=0; y:=0 B x : x := x+1 B y : x=0 y :=y+1 Process P2 CIS 540 Spring 2015; Lecture Feb 23

18
Weak vs Strong Fairness Is this fair to task A y of P3? (0,0) - A x -> (1,0) - A x -> (2,0) - A x -> (3,0) … - A x -> (105,0) - A x -> … Task A y 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 A y, but not strongly-fair nat x:=0; y:=0 A x : x := x+1 A y : even(x) y :=y+1 Process P3 CIS 540 Spring 2015; Lecture Feb 23

19
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

20
Requirements under Fairness Assumptions nat x:=0; y:=0 A x : x := x+1 A y : 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 A x, P3 with weak-fairness for B x Requirement: Eventually (y > 10) P1 with weak-fairness for A y, P3 with strong-fairness for B y Requirement: Eventually (x > y) Not satisfied, no matter what fairness assumption we make! nat x:=0; y:=0 B x : x := x+1 B y : even(x) y :=y+1 Process P3 Process P1 CIS 540 Spring 2015; Lecture Feb 23

Similar presentations

Presentation is loading. Please wait....

OK

Concurrency in Distributed Systems: Mutual exclusion.

Concurrency in Distributed Systems: Mutual exclusion.

© 2018 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google