Safety and Liveness. Thread Synchronization: Too Much Milk. Critical Sections. A Really Cool Theorem

Transcription

1 Safety and Liveness Properties defined over an execution of a program Thread Synchronization: Too Much Milk Safety: nothing bad happens holds in every finite execution prefix Windows never crashes No patient is ever given the wrong medication A program never terminates with a wrong answer Liveness: something good eventually happens no partial execution is irremediable Windows always reboots Medications are eventually distributed to patients A program eventually terminates A Really Cool Theorem s Every property defined on an execution of a program is a combination of a safety property and a liveness property (Alpern and Schneider, 1987) A critical section is a segment of code involved in reading and writing a shared data area Critical sections are used profusely in an OS to protect data structures (e.g., queues, shared variables, lists, ) Key assumptions: Finite Progress Axiom: Processes execute at a finite, but otherwise unknown, speed. Processes can halt only outside of the critical section (by failing, or just terminating)

2 concurrently in the critical section the critical section will eventually succeed the critical section will eventually succeed (Liveness)

3 the critical section will eventually succeed (Liveness) Bounded waiting: If a thread i is in entry section, then there is a bound on the number of times that other threads are allowed to enter the critical section before thread i s request is granted the critical section will eventually succeed (Liveness) Bounded waiting: If a thread i is in entry section, then there is a bound on the number of times that other threads are allowed to enter the critical section before thread i s request is granted (Safety+ Liveness) : General Program Structure Entry section Lock before entering critical section Wait if already locked code Exit section Unlock when leaving the critical section OO programming style Associate a lock with each shared object Methods that access shared objects are critical section Acquire/release locks when entering/exiting a method that defines a critical section Too Much Milk! Jack Look in the fridge: out of milk Leave for store Arrive at store Buy milk Arrive at home: put milk away Jill Look in fridge: out of milk Leave for store Arrive at store Buy milk Arrive at home: put milk away Oh no!

4 Formalizing Too Much Milk Solution #0: Taking Turns Shared variables Look in the fridge for milk - check a variable Put milk away - update a variable Safety At most one person buys milk Liveness Someone buys milk when needed while(turn! Jack) relax; while (Milk) relax;" turn := Jill while(turn! Jill) relax; while (Milk) relax; turn := Jack Solution #0: Taking Turns Solution #0: Taking Turns while(turn! Jack) relax; while (Milk) relax;" turn := Jill while(turn! Jill) relax; while (Milk) relax; turn := Jack while(turn! Jack) relax; while (Milk) relax;" turn := Jill while(turn! Jill) relax; while (Milk) relax; turn := Jack Safe? Why? True, False Live? Why? True, False Bounded waiting? True, false Safe? Yes! it is either Jack s or Jill turn Live? No what if the other guy stops checking milk? Bounded waiting? Yes... and the bound is 1!

5 Solution #1: Leave a note Solution #1: Leave a note Leave note = lock Remove note = unlock If you find a note from your roommatedon t buy! if (nonote) { leave Note; remove Note Leave note = lock Remove note = unlock If you find a note from your roommatedon t buy! if (nonote) { leave Note; remove Note Safe? Live? Bounded waiting? Why? Safe? Live? Bounded waiting? Why? This solution is worse than the previous one! It works sometime and does not some other time Solution #2: Colors Solution #3 (Peterson s): combine ideas from #0 & #2 Jack Leave Blue note if (nopinknote) { Remove Blue note Jill Leave Pink note if (nobluenote) { Remove Pink note We introduce two variables: in i : thread T i is executing in CS, or trying to do so turn i : id of thread allowed to enter CS under contention Claim: If the following invariant holds when T i " enters the critical section, so does mutual exclusion How do we prove it? Safe? Live? Bounded waiting? Why? BTW, what if a note has no color? in i " ini wants to enter CS ( in j (in j turn = i) ) " inj does not desire " inj wants to enter to enter CS CS, but it is ini s turn

6 Towards a solution We hit a snag The problem then boils down to establishing the following: in i ( in j (in j turn = i)) = in i ( in j turn = i) How can we do that? entry i : in i := true while (in j turn i) Thread T 0 Thread T 1 in 0 := true {in 0 {in 0 ( in 1 turn = 0)... {in 1 {in 1 ( in 0 turn = 1)... The assignment to in 0 invalidates the invariant A first fix A dirty trick Add assignment to turn to establish the second disjunct To establish the invariant, we add an auxiliary variable α that tracks the position of the PC Thread T 0 Thread T 1 in 0 := true; turn := 1; {in 0 {in 0 ( in 1 turn = 0) in 0 := true; N ; turn := 0; {in 1 {in 1 ( in 0 turn = 1) ; N in 0 := true turn = 1; {in 0 {in 0 ( in 1 turn = 0 at(α 1 )) in 0 := false; N α 0 α 1 turn = 0; {in 1 {in 1 ( in 0 turn = 1 at(α 0 )) N

7 α 0 Is Peterson safe? in 0 := true turn = 1; {in 0 {in 0 ( in 1 turn = 0 at(α 1 )) in 0 := false; N If both in the critical section, then: α 1 = (turn = 0) (turn = 1) = false turn = 0; {in 1 {in 1 ( in 0 turn = 1 at(α 0 )) N in 0 ( in 1 turn = 0 at(α 1 )) in 1 ( in 0 turn = 1 at(α 0 )) at(α 0 ) at(α 1 ) = Live: Non-blocking {S 1 : in 1 (turn = 1 turn = 0) {S 2 : in 1 (turn = 1 turn = 0) α 0 turn = 0; {S 2 {S 3 : in 1 ( in 0 turn = 1 at(α 0 )) {S 3 {S 1 N {R 1 : in 1 (turn = 1 turn = 0) {R 2 : in 1 (turn = 1 turn = 0) α 1 turn = 0; {R 2 {R 3 : in 1 ( in 0 turn = 1 at(α 0 )) {R 3 {R 1 N Blocking Scenario: T 0 before N, T 1 stuck at while loop S 1 R 2 in 0 (turn = 0) = in 0 in 1 in 0 (turn = 0) = false Live: Deadlock-free {S 1 : in 1 (turn = 1 turn = 0) {S 2 : in 1 (turn = 1 turn = 0) α 0 turn = 0; {S 2 {S 3 : in 1 ( in 0 turn = 1 at(α 0 )) {S 3 {S 1 N {R 1 : in 1 (turn = 1 turn = 0) {R 2 : in 1 (turn = 1 turn = 0) α 1 turn = 0; {R 2 {R 3 : in 1 ( in 0 turn = 1 at(α 0 )) {R 3 {R 1 N Deadlock-scenario: T 1 and T 0 at while, before entering the critical section S 1 R 2 (in 0 (turn = 0)) (in 1 (turn = 1)) (turn = 0) (turn = 1) = false Too Much Milk: Lessons Last solution works, but it is really unsatisfactory Solution is complicated; proving correctness is tricky even for the simple example While thread is waiting, it is consuming CPU time How can we do better? Define higher-level programming abstractions to simplify concurrent programming Use hardware features to eliminate busy waiting