A Hierarchical Method for Verifying Software Transactional Memory Implementations Serdar Tasiran...

A Hierarchical Method for Verifying A Hierarchical Method for Verifying Software Transactional Memory ImplementationsSoftware Transactional Memory Implementations

Serdar TasiranKoç University Istanbul, Turkey

joint work with

Tim HarrisMicrosoft Research,

Cambridge, UK

Thanks: Rustan Leino, Tim Harris, Shaz Qadeer, Mike Barnett, Dave Detlefs, Mike Magruder, Yossi Levanoni, Kapil Vaswani

TransactionsTransactions

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 interactionTypical program-STM interaction Thread i STM .

BEGIN(TRANSACTION)

OpenForRead(O1)Read(O1.f1)Read(O1.f2)

Local computationOpenForRead(O2)Read(O2.f3)

Local computationOpenForUpdate(O2)Write(O2.f3)Read(O1.f2)

Local computationOpenForUpdate(O3)Write(O3.f4)

COMMIT(TRANSACTION) ValidateRead(O1) ValidateRead(O2) CloseUpdatedObject(O2) CloseUpdatedObject(O3)

Thread i continues ...

Typical program-STM interactionTypical program-STM interaction Thread i STM .

BEGIN(TRANSACTION)

OpenForRead(O1)Read(O1.f1)Read(O1.f2)

Local computationOpenForRead(O2)Read(O2.f3)

Local computationOpenForUpdate(O2)Write(O2.f3)Read(O1.f2)

Local computationOpenForUpdate(O3)Write(O3.f4)

COMMIT(TRANSACTION) ValidateRead(O1) ValidateRead(O2) CloseUpdatedObject(O2) CloseUpdatedObject(O3)

Thread i continues ...

Write O1 metadatasnapshot into read log

Modify O2 metadataBecome 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 ImplementationSTM 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


“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

KOS + SEMCON

SEMALG, ABSSEMALG,CON

KOSABS + SEMCON

ATOMIC BLOCKS,STRONG, SEQUENTIALLY CONSISTENT SEMANTICS

sr THM. 1

(I)

(I)

Sec. 4.3

Sec. 4.4

(II)

Sec. 4.5

THM. 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) : SyntaxOur” Transactional Featherweight Java (OTFJ) : Syntax

P ::= 0 | P|P | t[p]

L :: = Class C{f1,f2,...,fn; M1, M2,...,Mk}

M :: = m(x1,x2, ..., xp){ p; }

s :: = x | v | s.f | s.m(s1,...,sn) | s.f := s | s; s | new C() | null

p :: = spawn p | lbl: onacid; s; commit | p; p

v :: = v | v.f | v.m(v1,...,vn) | v.f := v | v; v

OTFJ: Algorithm-level semantics

Algorithm-Level OTFJ Semantics

21

OTFJ ProgramAbstract

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 State STM State

P1, 1 1

2

2

read r.fi

Open4Read(r)

Abstract STM:This transitionleft unspecified

P1, 1

P2, 2

23

OTFJ Algorithm-Level Semantics: Read Field


1

2

2

read r.fi

Open4Read(r)

In actual implementation,”read r.fi” added to transaction read log

P1, 1

P1, 1

P2, 2

24

OTFJ Semantics: Successful Field Write


1

2

2

v.fi:= rnew

Open4Update(v)

OK2Write(v)

Abstract STM:This transitionleft unspecified

P1, 1

P1, 1

P2, 2

25

OTFJ Semantics: Successful Field Write


1

2

2

v.fi:= rnew

Open4Update(v)”write (v.fi, rnew, rold)” added to transaction write/undo log

OK2Write(v)

P1, 1

P1, 1

P2, 2

26

OTFJ Semantics: Failed Field Write


1

2

Open4Update(v)

OK2Write(v)

Invalid(s2)

P1, 1

P1, 1

27

OTFJ Semantics: Transaction Successful Commit


1

2

2

OK2Commit(1) Logs • appended to parent transaction’s logs• discarded if top-level transaction

Commit

P1, 1

P1, 1

P2, 2

28

OTFJ Semantics: Transaction Failed Commit


1

2 OK2Commit(1)

Commit

Invalid(s2)

P1, 1

P1, 1

29

OTFJ Semantics: Transaction Rollback


1

2

Invalid(1)

Program rewound to beginning of transaction • Program variable transitions unspecified

P1, 1

P1, 1

Algorithm-level semantics: What is atomic?

• Atomic actions at this level

– Open4Read, Open4Write, CommitTransaction

– Field Read, Field Write, Commit, Rollback

30

Outline


– Algorithm-level semantics

• Correctness

– Serializability



– OTFJ: Implementation-level semantics


• 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?

33

. . . . . . . . .

Action by transaction Tx

. . .

Action by transaction Tx

Must belong to Tx, ora child of Tx

The Life of a TransactionThe Life of a Transaction

First read successfully validated

Non-interference properties 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

transactions41

Outline


– Algorithm-level and implementation-level semantics

• Correctness

– Pure serializability




• Discussion

Proof Approach







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.fi, rnew, rold) in

Tx’s undo log, in reverse chronological order• v.fi = rold

– Clear log44

Semantics: Implementation-level Executions

45

High Level

Implementation Level

(th1,1 )

(th2,2 )

……

1

2

m

1

2

n

…

…

1

2

m

1

2

n

……

1

2

3

45

6

7

8

9

10

11

Implementation-level Atomic Actions

123

Implementation-level Atomic Actions

Atomic read

The rest: Localvariableaccesses:

All movers

Atomic read

Atomic compare and swap

The rest:Localvariableaccesses:Bothmovers

Desired: STM Methods Acting on Single Objects are AtomicDesired: 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

Valid

ateR

ead(

Tx1,o

bj 1)

Ope

n4W

rite(

Tx2,o

bj 2)

Valid

ateR

ead(

Tx3,o

bj 3)

Valid

ateR

ead(

Tx1,o

bj 4)

Ope

n4W

rite(

Tx2,o

bj 5)

Valid

ateR

ead(

Tx3,o

bj 6)

Proof Approach




Verify NOWSI, VRSI properties



Insert marker actions: “commit”, “undo”


Proof Approach




Verify NOWSI, VRSI properties





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 NOWSI 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);


if (*) OpenForUpdate(Tx,obj);


ValidateRead(Tx,obj);

assert(interferedWith ==> Tx.invalid);

61









62


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









64


• 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


• 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


• 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

– NOWSI

– VRSI

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)

ImplementationAlgorithm-level: Committed Transactions

Valid

ateR

ead(

Tx,o

bj 1)

Valid

ateR

ead(

Tx,o

bj 2)

Valid

ateR

ead(

Tx,o

bj 3)

. . . Valid

ateR

ead(

Tx,o

bj n)

. . .Commit(Tx)

Commute all of Tx’s actions here

Implementation Algorithm Level: Rolled Back Transactions

Writ

eFie

ld(T

x, o

bj 1.f 1

)

Writ

eFie

ld(T

x, o

bj 2.f 2

)W

riteF

ield

(Tx,

obj 3

.f 3)

. . . Writ

eFie

ld(T

x, o

bj n.f n

)

. . .

Tx being rolled back

Implementation Algorithm Level: Rolled Back Transactions

Writ

eFie

ld(T

x, o

bj 1.f 1

)

Writ

eFie

ld(T

x, o

bj 2.f 2

)W

riteF

ield

(Tx,

obj 3

.f 3)

. . . Writ

eFie

ld(T

x, o

bj 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, NOWSI

– If is a read by Tx’, Tx’ rolled back is a non-det read

Need for abstraction

Writ

eFie

ld(T

x, o

bj 1.f 1

)

Writ

eFie

ld(T

x, o

bj2.f 2

)W

riteF

ield

(Tx,

obj 3

.f 3)

. . . Writ

eFie

ld(T

x, o

bj n.f n

)

. . .


Rea

d(Tx

_oth

er, o

bj2.f 2

)

ND

Rea

d(Tx

_oth

er, o

bj2.f 2

)

Need for abstraction

Writ

eFie

ld(T

x, o

bj 1.f 1

)

Writ

eFie

ld(T

x, o

bj2.f 2

)W

riteF

ield

(Tx,

obj 3

.f 3)

. . . Writ

eFie

ld(T

x, o

bj n.f n

)

. . .


• 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 NOWSI and VRSI properties

– Equivalent (according to abstracted implementation-levelsemantics) to an atomic, serial one.

• Can show correct undo’s property using sequential analysis only

– By NOWSI, 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



Abstract Read Operations





Algorithm-level execution satisfying EW +VR + CU

Proof Approach



Abstract Read Operations





Algorithm-level execution with serial undo’sNOWSI ==> NOWS, VRSI ==>VRS, CU ==> CU

Straightforwardmanualproofs

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++?

A Hierarchical Method for Verifying Software Transactional Memory Implementations Serdar Tasiran...

Documents

Transcript of A Hierarchical Method for Verifying Software Transactional Memory Implementations Serdar Tasiran...