================================= Lecture 8 of CS 6110, Spring 2011 Feb 3, 2011 ================================= . Things discussed so far: ================================= * Basic Murphi coding and familiarity with model checking * Basics of Invariants and Hoare Logic . Asg3 ================================= * Reinforces Hoare logic and weakest preconditions * Makes you read up a bit on Mathematical Logic . Things online now ================================= * Gordon prover Lisp code (so you can try and play with it) * Full set of notes so far * Project ideas sent thru email . Where we are headed ================================= * Let you mull over logic * Context-switch back and teach you SPIN / Promela * Assign problems already seen in Promela / SPIN - learn new syntax - learn expressive power of LTL * Come back to finish up discussing logic in detail - teach you Ocaml - ask you to write some Logic manipulation routines * Show you KLEE - Assign something in KLEE * At this point, you will be project-ready! . Things not gone over in full detail yet ================================= * Why locking protocols work * Comments on modeling the Bakery algorithm in Murphi * Bounded Bakery protocol versions Google for miha-dipl.ps Also Herlihy/Shavit has a discussion * Great set of slides by Jun-Feng Yang on the topic of Locking Google for l8-synch.ppt * Notes from UC Davis on why "choosing" is needed Look up Bakery under Wikipedia, that links to the UC Davis site * Bounded Lamport Bakery versions - reference will be kept online * Ideas for bounding, in Murphi - throttle arrivals simulates reality discussed in Lamport's paper (that a counter saturates perhaps over a year) --------------------------------- Today's lecture: * Discuss problems/issues/questions * Types : name and structural equivalence * Hoare logic - Gordon book "typo" ? ================================================================== TOPIC 1: Computers and Compute Memory and Instruction Sets, and COHERENCE Consider ordinary read/write instructions. I'll portray as if two threads are carrying out these. I'll use "r" to suggest registers. I'll use C syntax. All "registers" will be "r, r1, ...". Initially : B = 0 T1 T2 B = 10; B = 20; r1 = B; r2 = B; Finally : can r1 == r2 == 0 ? Not if the memory is coherent! Coherency is guaranteed by elaborate protocols called "cache coherency" protocols Lamport's claim in the Bakery protocol : if reads and writes overlap, even returning values "from thin air" can be tolerated! ======================================================= ATOMICITY : Things appear uninterrupted Example of non-atomic situation Your bank balance Bal T1 T2 r1 = Bal; r2 = Bal; r1 = r1 + 10; r2 = r2 - 2; Bal = r1; Bal = r2; outcomes? ---- Let us use Promela syntax to indicate atomicity: atomic{ Bal = Bal + 10; } atomic{ Bal = Bal - 2; } ======================================================= The grain of atomicity provided by a memory system that provides cache coherence is PER LOCATION READS / WRITES. If you need higher grains of atomicity, you have to implement it "yourself". Ways of obtaining higher levels of atomicity (called "ways of implementing critical sections" in OS parlance) - use hardware instructions Such as the x86 ADD instruction with a LOCK prefix (Google will find you the right reference.) * In effect, you get the functionality of atomic { Bal = Bal + 10 } "directly" - use "software programs" THAT RELY ON the right shared memory consistency protocols !! (what is that? we will discuss shortly, below) ======================================================= Shared memory consistency models: Define a view of the WHOLE MEMORY (not individual locations) Example: initially : A = B = 0 T1 T2 A = 1; B = 2; r1 = B; r2 = A; Outcomes under Sequential Consistency (SC): . Anything BUT r1 == r2 == 0 . No values "out of thin air" (all values are either written or in initial memory) Is this execution COHERENT? * YES! Coherence is per-location SC SC => Coherence Coherence == does not ==> SC Define SC: The outcomes are AS IF the programs interleaved in some fashion, but respecting their program order. ======================================================= The TSO memory model : allows the r1 == r2 == 0 outcome! Operational specification of TSO in Murphi: See Dill, Park, and Nowatzyk's paper Gives Murphi code to simulate TSO ======================================================= Proofs of correctness of various locking protocols, and how they depend on the memory model. The code in Figure 2.4 of Herlihy and Shavit is: Ta Tb flag[a] = true; flag[b] = true; while (flag[b]){}; while (flag[a]){}; Suppose both in CS, then w_a(f[a]=t) -> r_a(f[b]==f) CS_a w_b(f[b]=t) -> r_b(f[a]==f) CS_b We also have wlg r_b(f[b]==f) -> w_b(f[b]==t) Then we have, through transitivity w_a(f[a]=t) -> r_a(f[b]==f) -> w_b(f[b]==t) -> r_b(f[a]==f) Assuming a sequential consistent memory, this is not possible. This is possible in x86 (and TSO) for many location types. ======================================================= Proof of Peterson's : saying that mutex is satisfied. Suppose not. Then w_a(f[a]=t) -> w_a(v=a) -> r_a(f[b]) -> r_a(v) -> CS_a (2.8) w_b(f[b]=t) -> w_b(v=b) -> r_b(f[a]) -> r_b(v) -> CS_a (2.9) WLG assume A was the last to write victim. So we have w_b(v=b) -> w_a(v=a) (2.10) This means that r_a(v) is really r_a(v)==A in (2.8). w_a(f[a]=t) -> w_a(v=a) -> r_a(f[b]) -> r_a(v==A) -> CS_a (2.8) w_b(f[b]=t) -> w_b(v=b) -> r_b(f[a]) -> r_b(v) -> CS_a (2.9) Since A entered the CS, it must be the case that r_a(f[b]) must be r_a(f[b])==false. w_a(f[a]=t) -> w_a(v=a) -> r_a(f[b]==false) -> r_a(v==A) -> CS_a (2.8) w_b(f[b]=t) -> w_b(v=b) -> r_b(f[a]) -> r_b(v) -> CS_a (2.9) Then we can obtain from 2.9 and 2.10 w_b(f[b]=t) -> w_b(v=b) -> w_a(v=a) -> r_a(f[b])==false. This is not possible under SC. =======================================================