A Hierarchical Method for Verifying Software Transactional Memory Implementations Serdar Tasiran Koç University Istanbul, Turkey joint work with Tim Harris Microsoft Research, Cambridge, UK Thanks: Rustan Leino, Tim Harris, Shaz Qadeer, Mike Barnett, Dave Detlefs, Mike Magruder, Yossi Levanoni, Kapil Vaswani

Transactions

The STM Verification Problem Software transactional memory (STM): –Code blocks marked “atomic” –STM implementation guarantees atomic, serialized, non-blocking execution, composability Complexity shifted to STM implementer –Complicated, tricky code: Conflict detection, rollback, ordering,... TM will be used widely –Correctness as critical as the rest of the computing platform Runtime, compiler, processor,... Real STM implementations are ~10K lines –Interact with the runtime, garbage collector,... Goal: Devise modular, re-usable method for proving correctness –Mechanically check most error-prone parts

Typical program-STM interaction Thread i STM. BEGIN(TRANSACTION) OpenForRead(O1) Read(O1.f1) Read(O1.f2) Local computation OpenForRead(O2) Read(O2.f3) Local computation OpenForUpdate(O2) Write(O2.f3) Read(O1.f2) Local computation OpenForUpdate(O3) Write(O3.f4) COMMIT(TRANSACTION) ValidateRead(O1) ValidateRead(O2) CloseUpdatedObject(O2) CloseUpdatedObject(O3) Thread i continues...

Typical program-STM interaction Thread i STM. BEGIN(TRANSACTION) OpenForRead(O1) Read(O1.f1) Read(O1.f2) Local computation OpenForRead(O2) Read(O2.f3) Local computation OpenForUpdate(O2) Write(O2.f3) Read(O1.f2) Local computation OpenForUpdate(O3) Write(O3.f4) COMMIT(TRANSACTION) ValidateRead(O1) ValidateRead(O2) CloseUpdatedObject(O2) CloseUpdatedObject(O3) Thread i continues... Write O1 metadata snapshot into read log Modify O2 metadata Become exclusive owner Write field update into log

Approach At the algorithm-level, STM’s are well understood –Key ideas in correctness proof known Algorithm level: Large-grain atomic actions –Field write, read –Transaction commit, roll back Example: Bartok STM, a write-in-place, lazy-invalidate STM Idea/earlier work: –Do algorithm-level proof once –Boil down to properties STM must satisfy: EW, VR, CU Sufficient condition for correctness –Check if STM implementation satisfies EW, VR, CU Formulate each as sequential assertion check, verify with Boogie

Not so simple! Implementation-level executions  Algorithm-level executions Problem 1: More variables at implementation level –STM implementation variables: Logs, per-object metadata, … Problem 2: Finer-grain, smaller actions  more interleavings –Atomic action: One instruction in an STM function implementation

STM Implementation

Not so simple! Reasoning at implementation level more difficult –Serializability proofs messy to write, check Approach: 1.Define algorithm-level semantics, prove serializability. Extract necessary conditions that STM must satisfy. 2.Define, prove correspondence between algorithm- and implementation-level executions  Algorithm-level proof carries over to implementation-level executions.

Proof Approach Implementation-level execution Algorithm-level execution satisfying NOWS +VRS + CU

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read operations Verify NOWS, VRS properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undoLastLogEntry” Algorithm-level execution satisfying NOWS + VRS + CU

  K OS + S EM CON SEM ALG, ABS SEM ALG,CON  K OS ABS + S EM CON ATOMIC BLOCKS, STRONG, SEQUENTIALLY CONSISTENT SEMANTICS  sr  T HM. 1   (I) Sec. 4.3 Sec. 4.4  (II) Sec. 4.5 T HM. 1

Intuition for proof steps Abstract some actions Prove non-interference Commute Prove larger blocks atomic Abstract some actions Prove non-interference Commute Prove larger blocks atomic

Outline OTFJ: “Our” Transactional Featherweight Java –Algorithm-level semantics Correctness –Serializability –Algorithm-level proof Distill to three required properties Relating implementation and algorithm levels –OTFJ: Implementation-level semantics –What to abstract, verify at implementation level? Discussion

19 “Our” Transactional Featherweight Java (OTFJ) : Syntax P ::= 0 | P|P | t[p] L :: = Class C{f 1,f 2,...,f n ; M 1, M 2,...,M k } M :: = m(x 1,x 2,..., x p ){ p; } s :: = x | v | s.f | s.m(s 1,...,s n ) | s.f := s | s; s | new C() | null p :: = spawn p | lbl: onacid; s; commit | p; p v :: = v | v.f | v.m(v 1,...,v n ) | v.f := v | v; v

OTFJ: Algorithm-level semantics

Algorithm-Level OTFJ Semantics 21 OTFJ Program Abstract STM Begin Transaction Field write Field read Can I commit? OK2Commit  Invalidate Tx  - Rollback - Undo using log Configuration: P, , 

22 OTFJ Algorithm-Level Semantics: Read Field Program StateSTM State P 1,  1 11 22 22 read r.f i Open4Read(r) Abstract STM: This transition left unspecified P 1,  1 P 2,  2

23 OTFJ Algorithm-Level Semantics: Read Field Program StateSTM State 11 22 22 read r.f i Open4Read(r) In actual implementation, ”read r.f i ” added to transaction read log P 1,  1 P 2,  2

24 OTFJ Semantics: Successful Field Write Program StateSTM State 11 22 22 v.f i := r new Open4Update(v) OK2Write(v)  Abstract STM: This transition left unspecified P 1,  1 P 2,  2

25 OTFJ Semantics: Successful Field Write Program StateSTM State 11 22 22 v.f i := r new Open4Update(v) ”write (v.f i, r new, r old )” added to transaction write/undo log OK2Write(v)  P 1,  1 P 2,  2

26 OTFJ Semantics: Failed Field Write Program StateSTM State 11 22 Open4Update(v) OK2Write(v)  Invalid(s 2 ) P 1,  1

27 OTFJ Semantics: Transaction Successful Commit Program StateSTM State 11 22 22 OK2Commit(  1 )  Logs appended to parent transaction’s logs discarded if top-level transaction Commit P 1,  1 P 2,  2

28 OTFJ Semantics: Transaction Failed Commit Program StateSTM State 11 22 OK2Commit(  1 )  Commit Invalid(s 2 ) P 1,  1

29 OTFJ Semantics: Transaction Rollback Program State STM State 11 22 Invalid(  1 ) Program rewound to beginning of transaction Program variable transitions unspecified P 1,  1

Algorithm-level semantics: What is atomic? Atomic actions at this level –Open4Read, Open4Write, CommitTransaction –Field Read, Field Write, Commit, Rollback 30

Outline OTFJ: “Our” Transactional Featherweight Java –Algorithm-level semantics Correctness –Serializability –Algorithm-level proof Distill to three required properties Relating implementation and algorithm levels –OTFJ: Implementation-level semantics –What to abstract, verify at implementation level? Discussion

Correctness: Equivalence of Executions Equivalence: Executions ξ and ξ’ equivalent according to a semantics SEM if ξ and ξ’ –are both consistent with SEM –have the same set of threads –have the same end state –For each thread: Same sequence of actions Alternative view: –Commuting movers in the right direction yields equivalent execution –Dependent: Access same program variable, at least one is a write 32

Correctness: Serializability Serial execution: Conflict-free: No transaction is rolled-back Serializability –Is each execution equivalent to a serial execution? Action by transaction Tx... Action by transaction Tx Must belong to Tx, or a child of Tx

The Life of a Transaction First read successfully validated

Non-interference properties   STM implementation code must ensure that these properties hold 1.Exclusive writes (EW) 2.Valid reads (VR) 3.Correct undo (CU)

Write and Read Spans Execution ξ =  0,  1,...,  n Write span of an object o within transaction Tx: Interval [i, j] ξ =  0,...,  i,...,  j,...,  n –  i : First write by Tx to a field of o –  j : Completion action (commit or undo) of Tx Read span of an object o within transaction Tx: Interval [i, j] ξ =  0,...,  i,...,  j,...,  n –  i : First read of o by Tx –  j : Completion action (commit or undo) of Tx

Algorithm-Level Serializability: Sufficient Conditions 1.Non-Overlapping Write Spans (NOWS) For any obj, Tx  Tx’ WriteSpan(Tx,obj) and WriteSpan(Tx’,obj) do not overlap. 2.Valid Read Spans (VRS) For succeeding Tx, for all obj, Tx  Tx’ ReadSpan(Tx,obj) does not overlap WriteSpan(Tx’,obj) 3.Correct Undo’s (CU) Open4Update(Tx, obj) Undo(Tx) Theorem: NOWS + VRS + CU ==> Pure serializability State of obj same at these two points

Need for abstract algorithm-level semantics Concrete semantics –Serial execution: No conflicts, no rollbacks –No concurrent execution with conflicts and rollbacks can be equivalent to a serial one. Solution: Allow non-deterministic rollback of transaction Not enough! T1 T2 read(Tx1, v=0) read(Tx2, v=0) write(Tx2, v:=1) commit(Tx2) write(Tx1, v:=2) invalidate(Tx1) Cannot commute actions of T1 together Solution: Allow reads in rolled-back transactions to return non-deterministic values. 38

Algorithm-level serializability proof sketch Show actions to be movers of certain types –α is a right mover if for every ξ = ……. α β ……. ξ’ = ……. β α ……. is equivalent to ξ –Left mover similar. Argue: Actions of a transaction have the following form RRRRR N LLLLLL Case split: (i) Successful transactions (ii) Rolled-back transactions Ordering of actions within transaction comes from semantics 39

Algorithm-level serializability proof sketch Right movers: –Open4Read, Open4Write: STM state update left non-det –Field Write: Because of NOWS property –Field Read: Because of VRS property (Successful transactions) Non-deterministic (Rolled-back transactions) Non-movers: –Commit action (Successful tx) –Undo action (Rolled-back tx) Left movers: –Thread-local bookkeeping actions after commit, rollback Correct Undo (CU) property trivially implies pure serializability 40

Algorithm-level serializability proof NOWS + VRS + CU imply pure serializability –For abstract algorithm-level semantics What does serializability of an abstract model mean? –Extreme case: Completely non-deterministic program trivially serializable –Must limit how much non-determinism is added. RemRB(ξ) = ξ’ ξ’ same as ξ except actions by rolled back transactions removed Correct undos (CU) ξ crucial –Every execution ξ equivalent to a serial ξ* –RemRB( ξ*) is consistent with strong semantics for transactions 41

Outline OTFJ: “Our” Transactional Featherweight Java –Algorithm-level and implementation-level semantics Correctness –Pure serializability –Algorithm-level proof Distill to three required properties Relating implementation and algorithm levels –What to abstract, verify at implementation level? Discussion

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read operations Verify NOWS, VRS properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undoLastLogEntry” Algorithm-level execution satisfying EW +VR + CU

Implementation-Level Semantics Open4Read: Bartok’s OpenForRead function Open4Update: Bartok’s OpenForUpdate function Commit: Bartok’s DTMCommit(Tx) function –For all objects o in Tx’s read log ValidateRead(o) –If all succeed For all o in write log –CloseUpdatedObject(o) Clear all logs –Otherwise, invalidate Tx, roll back Rollback: Bartok’s DTMAbort function –For all entries (v.f i, r new, r old ) in Tx’s undo log, in reverse chronological order v.f i = r old –Clear log 44

Semantics: Implementation-level Executions 45 High Level Implementation Level ( th 1,  1 ) ( th 2,  2 ) … … 11 22 mm 11 22 nn … … 11 22 mm 11 22 nn … …

11 22 33 44 55 66 77 88 99  10  11 Implementation-level Atomic Actions

11 22 33

Atomic read The rest: Local variable accesses: All movers

Atomic read Atomic compare and swap The rest: Local variable accesses: Both movers Desired: STM Methods Acting on Single Objects are Atomic

Read CAS The need for abstraction: Actions do not commute CAS If CAS fails, can’t commute Read or CAS across CAS.

NDRead CAS The need for abstraction: Actions do not commute CAS NDRead: –for succeeding CAS: works like regular read –for failing CAS: reads non-deterministic value NDRead for failing CAS commutes with all actions But how do you “implement” NDRead: Prophecy variable: CASWillFail Similar trick for reads within failing transactions Prophecy variable: willInvalidate(Tx) Read returns non-deterministic value if willInvalidate(Tx) is true.

Every execution is equivalent to a coarse atomic one Abstract read actions Prove non-interference Commute Prove larger blocks atomic ValidateRead(Tx 1,obj 1 ) Open4Write(Tx 2,obj 2 ) ValidateRead(Tx 3,obj 3 ) ValidateRead(Tx 1,obj 4 ) Open4Write(Tx 2,obj 5 ) ValidateRead(Tx 3,obj 6 )

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read operations Verify NOWS I, VRS I properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undo” Algorithm-level execution satisfying NOWS +VRS + CU

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read operations Verify NOWS I, VRS I properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undo” Algorithm-level execution satisfying NOWS +VRS + CU Boogie!

55 Read and Write Spans at Implementation Level Execution ξ =  0,  1,...,  n Write span of an object o within transaction Tx: Interval [i, j] ξ =  0,...,  i,...,  j,...,  n –  i : First OpenForWrite(Tx,o) –  j : CloseUpdatedObject(Tx,o) Read span of an object o within transaction Tx: Interval [i, j] ξ =  0,...,  i,...,  j,...,  n –  i : First OpenForWrite(Tx,o) –  j : ValidateRead(Tx,o)

56 Non-Overlapping Write Spans – Impl. Level [OpenForUpdate(Tx, obj), CloseUpdatedObj(Tx, obj) ] does not overlap with [OpenForUpdate(Tx_bad, obj), CloseUpdatedObj(Tx_bad, obj) ] Approach: Assume Tx executed OpenForUpdate(Tx,obj) and not CloseUpdatedObj(Tx,obj) yet ExclusiveOwner(Tx,obj): A formula that says obj metadata indicates that Tx is the exclusive write owner and other good things. Prove: [Remember all STM methods are atomic] Any possible method execution by another thread Tx_bad leaves ExclusiveOwner(Tx,obj) unchanged.

57 Checking NOWS I with Boogie Havoc(obj’s state and metadata) OpenForUpdate(Tx_good, obj) assume( ExclusiveOwner(Tx_good, obj) );

58 Checking NOWS with Boogie Havoc(obj’s state and metadata) OpenForUpdate(Tx_good, obj) assume( ExclusiveOwner(Tx_good, obj) ); assume( Tx_bad != Tx_good); OpenForUpdate(Tx_bad, obj); assert(ExclusiveOwner(Tx_good, obj));

59 Valid Read Spans (VRS) ==> VR [OpenForRead(Tx1,obj), (Successful)ValidateRead(Tx1,obj) ] does not overlap with [OpenForUpdate(Tx2, obj), CloseUpdatedObj(Tx2, obj) ]

60 Checking VRS with Boogie InterfereWith(Tx, obj); OpenForRead(Tx,obj); InterfereWith(Tx, obj); if (*) OpenForUpdate(Tx,obj); InterfereWith(Tx, obj); ValidateRead(Tx,obj); assert(interferedWith ==> Tx.invalid);

61 Checking VRS with Boogie InterfereWith(Tx, obj); OpenForRead(Tx,obj); InterfereWith(Tx, obj); if (*) OpenForUpdate(Tx,obj); InterfereWith(Tx, obj); ValidateRead(Tx,obj); assert(interferedWith ==> Tx.invalid);

62 Checking VRS with Boogie InterfereWith: Represents effects of (  + Close) (Open. Close)* ( Open +  ) InterfereWith (Transaction Tx, Object obj) { while (*) { Tx_bad = non-deterministically chosen transaction assume(Tx_bad != Tx); if (*) OpenForUpdate(Tx_bad, obj); if (*) CloseUpdatedObj(Tx_bad, obj); }

63 Checking VRS with Boogie InterfereWith(Tx, obj); OpenForRead(Tx,obj); InterfereWith(Tx, obj); if (*) OpenForUpdate(Tx,obj); InterfereWith(Tx, obj); ValidateRead(Tx,obj); assert(interferedWith ==> Tx.invalid);

64 Checking VRS with Boogie Challenge: Finding pre- and post-conditions for InterfereWith() –Boogie has the loop invariant inference (using abstract interpretation) capability to automate this InterfereWith (Transaction Tx, Object obj) { while (*) { Tx_bad = non-deterministically chosen transaction assume(Tx_bad != Tx); if (*) OpenForUpdate(Tx_bad, obj); if (*) Close*Obj(Tx_bad, obj); }

65 Checking VRS with Boogie Wrote pre/post-condition pair, verified to be inductive, again using Boogie but on straightline code. –Post-condition: If object opened or closed by Tx_bad, –version number is bigger or –obj (metadata) is quiescent –or obj metadata has info related to Tx_bad in it. InterfereWith (Transaction Tx, Object obj) ensures (interferedWith ==> PostCondition(Tx, obj)); ensures (!interferedWith ==> Unchanged(Tx,obj)) { InterfereWith(Tx, obj); if (*) OpenForUpdate(Tx_bad, obj); if (*) Close*Obj(Tx_bad, obj); }

66 Checking VRS with Boogie Omissions in STM pseudocode showed up when checking this proof obligation with Boogie –Some interleavings had been overlooked in pseudocode –Tx_bad: opens for update –Tx_good: opens for read »Tx_bad: modifies object »Tx_bad: closes updated object –Tx_good: opens for update –Tx_good: validates read (shouldn’t have) –Transaction should be invalidated, it isn’t. After putting in fixes, check passed –Possible to make errors in STM design at this level Checks took ~5 minutes

What do we have so far? Implementation-level executions have the –NOWS I –VRS I properties These are enough to prove –OpenForWrite, Field Writes right movers –OpenForRead, Read right movers (in successful Tx) –CloseUpdatedObject left mover –ValidateRead left mover (in successful Tx)  Successful transactions can be made atomic What about rolled back transactions? –These can be made atomic/sequential after some abstraction (on implementation-level model)

Implementation  Algorithm-level: Committed Transactions ValidateRead(Tx,obj 1 ) ValidateRead(Tx,obj 2 ) ValidateRead(Tx,obj 3 )... ValidateRead(Tx,obj n )... Commit(Tx) Commute all of Tx’s actions here

Implementation  Algorithm Level: Rolled Back Transactions WriteField(Tx, obj 1.f 1 ) WriteField(Tx, obj 2.f 2 ) WriteField(Tx, obj 3.f 3 )... WriteField(Tx, obj n.f n )... Tx being rolled back

Implementation  Algorithm Level: Rolled Back Transactions WriteField(Tx, obj 1.f 1 ) WriteField(Tx, obj 2.f 2 ) WriteField(Tx, obj 3.f 3 )... WriteField(Tx, obj n.f n )... Move all WriteField’s here WriteField’s commute to left of all intervening actions  –  cannot be a write: Tx has object open for write, NOWS I –If  is a read by Tx’, Tx’ rolled back   is a non-det read

Need for abstraction WriteField(Tx, obj 1.f 1 ) WriteField(Tx, obj 2.f 2 ) WriteField(Tx, obj 3.f 3 )... WriteField(Tx, obj n.f n )... Commute all of Tx’s actions here Read(Tx_other, obj 2.f 2 )

NDRead(Tx_other, obj 2.f 2 ) Need for abstraction WriteField(Tx, obj 1.f 1 ) WriteField(Tx, obj 2.f 2 ) WriteField(Tx, obj 3.f 3 )... WriteField(Tx, obj n.f n )... Commute all of Tx’s actions here NDRead: Non-Deterministic Read –Acts like regular read, or –Reads arbitrary value Only if part of failing (rolled-back) transaction Commutes with any action Only adds to behaviors  safe for modeling 

Rolled Back Transactions Rolled-back implementation-level execution with NOWS I and VRS I properties –Equivalent (according to abstracted implementation-level semantics) to an atomic, serial one. Can show correct undo’s property using sequential analysis only –By NOWS I, transaction has exclusive write control of object until CloseUpdatedObj –Must show that updates entered to logs and undoing them in reverse chronological order has no net effect on program state.

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read Operations Verify NOWS, VRS properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undo” Algorithm-level execution satisfying EW +VR + CU

Proof Approach Implementation-level execution “Coarse-atomic” execution Abstract Read Operations Verify NOWS, VRS properties “Coarse-atomic” execution with serial undo’s Merge chains of STM internal state transitions Insert marker actions: “commit”, “undo” Algorithm-level execution with serial undo’s NOWS I ==> NOWS, VRS I ==>VRS, CU ==> CU Straightforward manual proofs

76 Discussion Correctness proof for STM’s involves quantification over –threads, transactions –all possible sequences of accesses in a transaction –objects This is taken care of –mostly in the manual part of proof –and by “Tx_bad”(s) in the mechanized part Initial focus: Do STM methods guarantee non-interference? –Most error prone part –Checked mechanically Checks with Boogie computationally manageable –Simple sequential scenarios: One object, one transaction, environment interfereWith models all other threads/transactions

Summary Formalizing correctness: –OTFJ language, “pure serializability” Proving correctness at high-level: –Reduced algorithm-level proof of pure serializability to three sufficient conditions: NOWS + VRS + CU Relating implementation and algorithm levels: –Provided low-level semantics for OTFJ –Devised sequence of steps to transform implementation-level executions to algorithm-level executions –Correctness of most error-prone step checked with Boogie Modeling tricks: –Identified abstractions in modeling required for approach to work

78 Future Work Mechanize more of proof Non-transactional accesses, buffered-write STM’s –Privatization problem, etc. –Strong isolation for non-transactional accesses –What is the correctness criterion? Formalizing relationship between model and implementation –What exactly is assumed of the GC and CLR? –How to establish correspondence between Spec# model and 10K lines of C++?