The S emantics of Concurrent Programming , 3

1. The SemanticsofConcurrentProgramming, 3 K. V. S. Prasad Deptof Computer Science Chalmers University February – March 2013

2. Recap • What do *you* think we have established?

3. Processesrevisited • Wedidn’treallysaywhat ”waiting” was • Define it as ”blocked for resource” • Ifrunwillonlybusy-wait • If not blocked, it is ”ready” • Whetheractuallyrunningdepends on scheduler • Running -> blockedtransitiondone by process • Blocked -> readytransitiondue to external event • Nowsee B-A slide 6.1 • Define ”await” as a non-blocking check of booleancondition

4. Deadlock? • With higherlevel of process • Processescanhave a blockedstate • If all processes are blocked, deadlock • So require: no pathleads to such a state • With independent machines (alwaysrunning) • Can have livelock • Everyonerunsbut no onecanentercriticalsection • So require: no pathleads to such a situation

5. Semaphore definition • Is a pair < value, set of blockedprocesses> • Initialised to <k, empty> • k depends on application • For a binarysemaphore, k=1 or 0, and k=1 at first • Two operations. Whenproc p callssem S • Wait (S) = • if k>0 then k:=k-1 else block p and add it to set • signal (S) • Ifempty set then k:=k+1 elsetake a q from set and unblock it • Signal undefined on a binarysemwhen k=1

6. CriticalSection with semaphore • See alg 6.1 and 6.2 (slides 6.2 through 6.4) • Semaphore is like alg 3.6 • The second attempt at CS without special ops • There, the problem was • P checks wantq • Finds it false, enters CS, • but q entersbefore p can set wantp • Wecanprevent that by compare-and-swap • Semaphores are high level versions of this

7. Correct? • Look at state diagram (p 112, s 6.4) • Mutex, becausewedon’thave a state (p2, q2, ..) • No deadlock • Of a set of waiting (or blocked) procs, one gets in • Simpler definition of deadlocknow • Bothblocked, no hope of release • No starvation, with fair scheduler • A waitwill be executed • A blocked process will be released

8. Invariants • Do you knowwhatthey are? • Help to prove loops correct • Game example • Semaphore invariants • k >= 0 • k = k.init + #signals - #waits • Proof by induction • Initiallytrue • The onlychanges are by signals and waits

9. CS correctness via sem invariant • Let #CS be the number of procs in theirCS’s. • Then #CS + k = 1 • True at start • Waitdecrements k and increments #CS; onlyonewaitpossiblebefore a signal intervenes • Signal • Eitherdecrements #CS and increments k • Or leavesbothunchanged • Since k>=0, #CS <= 1. So mutex. • If a proc is waiting, k=0. Then #CS=1, so no deadlock. • No starvation – seebook, page 113

10. Whytwoproofs? • The state diagram proof • Looks at eachstate • Will not extend to large systems • Except with machineaid (model checker) • The invariant proof • In effect deals with sets of states • E.g., all states with oneproc is CS satisfy #CS=1 • Better for human proofs of larger systems • Foretaste of the logicalproofswewillsee (Ch. 4)

11. TowardsDekker: the problem, again • Specification • Both p and q cannot be in their CS at once (mutex) • If p and q bothwish to entertheir CS, one must succeedeventually (no deadlock) • If p tries to enterits CS, it willsucceedeventually (no starvation) • GIVEN THAT • A process in its CS willleaveeventually (progress) • Progress in non-CSoptional

12. Different kinds of requirement • Safety: • Nothing bad everhappens on anypath • Example: mutex • In no state are p and q in CS at the same time • Ifstate diagram is beinggeneratedincrementally, weseemoreclearly that this says ”in everypath, mutex” • Liveness • A goodthinghappenseventually on everypath • Example: no starvation • If p tries to enterits CS, it willsucceedeventually • Oftenbound up with fairness • Wecansee a path that starves, butsee it is unfair

13. Language, logic and machines • Evolution • Language fits life – why? • What is language? • What is logic? • Special language • What are machines? • Whydoeslogic work with them? • What kind of logic?

14. Logic Review • How to check that our programs are correct? • Testing • Can show the presence of errors, butneverabsence • Unlesswe test everypath, usuallyimpractical • Howdo you show maththeorems? • For *every* triangle, … (wow!) • For *every* run • Nothing bad everhappens (safety) • Somethinggoodeventuallyhappens (liveness)

15. Propositionallogic • Assignment – atomic props mapped to T or F • Extended to interpretation of formulae (B.1) • Satisfiable – f is true in some interpretation • Valid - f is true in all interpretations • Logicallyequal • same value for all interpretations • P -> q is equivalent to (not p) or q • Material implcation • p -> q is trueif p is false

16. Proofmethods • State diagram • Largescale: ”modelchecking” • A logicalformula is true of a set of states • Deductiveproofs • Includinginductiveproofs • Mixture of English and formulae • Like mostmathematics

17. Atomic Propositions (true in a state) • wantpis true in a state • iff (boolean) var wantp has valuetrue • p4 is trueiff the program counter is at p4 • p4 is the commandabout to be executed • Thenpj is false for all j =/= 4 • turn=2 is trueiffinteger var turn has value 2 • not (p4 and q4) in alg 4.1, slide 4.1 • Should be true in all states to ensuremutex

18. Mutex for Alg 4.1 • Invariant Inv1: (p3 or p4 or p5) -> wantp • Base: p1, so antecedent is false, so Inv1 holds. • Step: Process q changesneitherwantp nor Inv1. Neither p1 nor p3 nor p4 change Inv1. p2 makes both p3 and wantptrue. p5 makes antecedentfalse, so keeps Inv1. So by induction, Inv1 is alwaystrue.

19. Mutex for Alg 4.1 (contd.) • Invariant Inv2: wantp -> (p3 or p4 or p5) • Base: wantp is initialised to false , so Inv2 holds. • Step: Process q changesneitherwantp nor Inv1. Neither p1 nor p3 nor p4 change Inv1. p2 makes both p3 and wantptrue. p5 makes antecedentfalse, so keeps Inv1. So by induction, Inv2 is alwaystrue. Inv2 is the converse of Inv1. Combining the two, wehave Inv3: wantp <-> (p3 or p4 or p5) and wantq <-> (q3 or q4 or q5)

20. Mutex for Alg 4.1 (concluded) • Invariant Inv4: not (p4 and q4) • Base: p4 and q4 is false at the start. • Step: Only p3 or q3 canchange Inv4. p3 is ”await (not wantq)”. But at q4, wantq is true by Inv3, so p3 cannotexecute at q4. Similarly for q3. So wehavemutex for Alg 4.1

21. Proof of Dekker’sAlgorithm (outline) • Invariant Inv2: (turn = 1) or (turn = 2) • Invariant Inv3: wantp <-> p3..5 or p8..10 • Invariant Inv4: wantq <-> q3..5 or q8..10 • Mutexfollows as for Algorithm 4.1 • Will show neither p nor q starves • Effectively shows absence of livelock

22. Liveness via Progress • Invariants canprovesafetyproperties • Somethinggood is alwaystrue • Something bad is alwaysfalse • But invariants cannotstateliveness • Somethinggoodhappenseventually • Progress A to B • ifwe are in state A, wewill progress to state B. • Weakfairnessassumed • to ruleout trivial starvationbecause process neverscheduled. • A scenario is weakly fair if • B is continuallyenabled at state Ain scenario -> B willeventuallyappear in the scenario

23. Box and Diamond • A request is eventuallygranted • For all t. req(t) -> exists t’. (t’ >= t) and grant(t’) • New operators indicate time relationshipimplicitly • box (req -> diam grant) • If ”successorstate” is reflexive, • box A -> A (if it holdsindefinitely, it holdsnow) • A -> diam A (if it holdsnow, it holdseventually) • If ”successorstate” is transitive, • box A -> box box A • if not transitive, A mighthold in the nextstate, but not beyond • diamdiam A -> diam A

24. Progress in (non-)criticalsection • Progress in criticalsection • box (p8 -> diam p9) • It is alwaystrue that ifwe are at p8, wewilleventually progress to p9 • Non-progress in non-criticalsection • diam (box p1) • It is possible that wewillstay at p1 indefinitely

25. Progress throughcontrolstatements • For ”p1: if A then s” to progress to s, need • p1 and box A • p1 and A is not enough • does not guarantee A holds by the time p1 is scheduled • So in Dekker’salgorithm • p4 and box (turn = 2) -> diam p5 • Butturn = 2 is not trueforever! • It doesn’thave to be. Only as long as p4.

26. Lemma 4.11 • box wantp and box (turn = 1) -> diam box (not wantq) • If it is p’sturn, and it wants to enterits CS, q willeventuallydefer • Note that at q1, wantq is alwaysfalse • Both at init and on looping • q will progress through q2..q5 and wait at q6 • Inv4: wantq <-> q3..5 or q8..10 • Implies box (not wantq) at q • Lemma follows

27. Progress to CS in Dekker’salgorithm • Suppose p2 and box (turn=2) • If p3 and not wantqthendiam p8 • p2 and box (turn=2 and wantq) -> diam box p6 <-> diam box (not wantp) • p6 and box (turn=2 and not wantp) -> diam q9 • p2 and box (turn=2) -> diam box (p6 and turn=1) • Lemma 4.11 nowyieldsdiam p8

28. waitC(cond) Append p to cond p.State <- blocked Monitor release

29. signalC(cond) Ifcond not empty q <- head of queue ready q

30. Correctness of semaphore • See p 151 • Exactly the same as fig 6.1 (s 6.4) • Note that state diagrams simplify • Whole operations are atomic

31. Producer-consumer • Alg 7.3 • All interestingcodegathered in monitor • Very simple usercode

32. Immediateresumption • So signallingproccannotagainfalsifycond • If signal is the last op, allowproc to leave? • How? Seeprotectedobjects • Manyotherchoicespossible • Check what your languageimplements

33. Readers and writers • Alg 7.4 • Not hard to follow, but lots of detail • Readers check for no writers • Butalso for no blockedwriters • Gives blockedwritersprioroty • Cascaded release of blockedreaders • Butonlyuntilnextwriter shows up • No starvation for eitherreader or writer • Shows up in longproof (sec 7.7, p 157) • Read at home!

34. Readers-writers invariants • Readers exclude writers but not other readers • Writers write alone • Invariants R >= 0 and W >= 0 • Theorem • (W <= 1) and (W=1 -> R=0) and (R>0 -> W=0) • Monitor operations are atomic! Check each one. • Don’t forget to check the Signal operations

35. Readers progress • i.e., Won’t block forever on OKtoRead • Invariants (lemma) • Not empty(OKtoRead) -> (W ne 0) or not empty(OKtoWrite) • not empty(OKtoWrite) -> (R ne 0) or (W ne 0) • not empty(OKtoRead)-> <> signalC(OKtoRead) • Case W ne 0 • Writer progresses, executes the signalC(OKtoRead) • Case R ne 0 • Last reader releases a writer, reduces to previous case

36. Exchange • ex(a,b) = atomic{local t; t:=a; a:=b; b:=t} • Seeslide 3.23, alg 3.12 • Provecorrect

37. Ex 2. 5 • Thereis i such that f(i)=0. An algorithm is correctif for all scenarios, bothprocessesterminate after one has found the zero. • For eachofalgorithms A – E, startingwithslide 2.40, either show the program correct or find a counterexample scenario.

38. Ex 7.2 • See alg 7.4 (slides 7.9, 7.10, readers-writers with monitors). Replaceintwriters by a boolean writers>0 • Thm 7.1 and 7.2 say R>=0, W>=0, R>0 -> W=0, and W=1 -> R=0 • So W=0 or W=1 is invariant: can be replaced by boolean. • Whydoes the bookproofuseintegers?

39. Whyarbitraryinterleaving? • Multitasking (2.8 is a picture of a contextswitch) • Contextswitches are quiteexpensive • Takeplace on time slice or I/O interrupt • Thousands of process instructionsbetweenswitches • Butwhere the cut falls depends on the run • Runs of concurrent programs • Depend on exact timing of external events • Non-deterministic! Can’t debug the usualway! • Does different thingseach time!

40. Arbitraryinterleaving (contd.) • Multiprocessors (see 2.9) • If no contentionbetweenCPU’s • Trueparallelism (looks like arbitraryinterleaving) • Contentionresolvedarbitrarily • Again, arbitraryinterleaving is the safestassumption

41. Butwhat is beinginterleaved? • Unit of interleavingcan be • Wholefunctioncalls? • High levelstatements? • Machineinstructions? • Largerunitslead to easierproofsbut make otherprocesseswaitunnecessarily • Wemightwant to change the units as wemaintain the program • Hence best to leavethingsunspecified

42. Why not rely on speed throughout? • Don’t get into the traincrash scenario • use speed and time throughout to design • everydayplanning is often like this • Particularly in older, simplermachineswithout sensors • For people, wealsoadd explicit synchronisation • For our programs, the input can come from the keyboard or broadband • And the broadband gets faster everyfewmonths • So allowarbitrary speeds

43. Atomic statements • The thing that happenswithoutinterruption • Can be implemented as high priority • Comparealgorithms 2.3 and 2.4 • Slides 2.12 to 2.17 • 2.3 canguarantee n=2 at the end • 2.4 cannot • hardware folk saythere is a ”race condition” • We must saywhat the atomicstatements are • In the book, assignments and booleanconditions • How to implementthese as atomic?

44. Atomic statements • The thing that happenswithoutinterruption • Can be implemented as high priority • Comparealgorithms 2.3 and 2.4 • Slides 2.12 to 2.17 • 2.3 canguarantee n=2 at the end • 2.4 cannot • hardware folk saythere is a ”race condition” • We must saywhat the atomicstatements are • In the book, assignments and booleanconditions • How to implementthese as atomic?

45. What are hardware atomicactions? • Setting a register • Testing a register • Is that enough? • Thinkabout it (or cheat, and read Chap. 3)

46. The standard Concurrencymodel • What world are weliving in, or choose to? • Synchronous or asynchronous? • Real-time? • Distributed? • Wechoose an abstraction that • Mimicsenough of the real world to be useful • Has niceproperties (canbuilduseful and good programs) • Can be implementedcorrectly, preferablyeasily

47. Obey the rules you make! • For almost all of this course, weassumesingle processor withoutreal-time (so parallelism is only potential). • Real life examplewhere it is dangerous to make time assumptionswhen the system is designed on explicit synchronisation – the train • And at leastknow the rules! (Therac).

48. Primitives and Machines • Wesee this repeatedly in Computer Science • Whether for primitives or wholemachines • Recognisepattern in nature or in use • Specify primitive or machine • Figureoutrange of use and problems • Figureout (efficient) implementation

49. CS problem for n processes • See alg 6.3 (p 113, s 6.5) • The same algorithmworks for n procs • The proofs for mutex and deadlock freedom work • Weneverused special properties of binarysems • Butstarvation is nowpossible • p and q can release eachother and leave r blocked • Exercise: If k is set to m initially, at most m processescan be in theirCS’s.

50. Mergesortusingsemaphores • See p 115, alg 6.5 (s 6.8) • The two halves can be sortedindependently • No need to synch • Merge, the third process, • has to wait for both halves • Notesemaphoresinitialised to 0 • Signal precedeswait • Done by process that did not do a wait • Not a CS problem, but a synchronisationone