Verification of architectural memory models by model checking Shaz Qadeer Compaq Systems Research...

Post on 26-Mar-2015

217 views 4 download

Tags:

transcript

Verification of architectural memory models

by model checking

Shaz QadeerCompaq Systems Research Center

Shaz.Qadeer@compaq.com

Outline

• Introduction to shared-memory systems and models

• Model checking method for verifying models on systems

Compiler

Multiprocessor

Multithreaded program

Executable code

Languagememory model(Java, Modula-3, C with threads)

Multiprocessor

P P P

P P P

INTERCONNECT NETWORK

Architecturalmemory model(SC, Alpha, Sun)

Multiprocessor

Compiler

Multiprocessor

Multithreaded program

Executable code

Languagememory model(Java, Modula-3, C with threads)

Compiler

Multithreaded program

Executable code

Languagememory model(Java, Modula-3, C with threads)

Architecturalmemory model(SC, Alpha, Sun)

Verification Problem

Architecturalmemory model(SC, Alpha, Sun)

Multiprocessor ?

Uniprocessor

Memory

PA := 1;if (B = 0) { ...}

Initially A = B = 0

Shared-memory multiprocessor

Memory

PA := 1;if (B = 0) { ...}

Initially A = B = 0

PB := 1;if (A = 0) { ...}

Memory

PW(A, 1)

R(B, ?)

Initially A = B = 0

PW(B, 1)

R(A, ?)

Shared-memory model

Sequential consistency

Memory

PW(A, 1)

R(B, 1)

Initially A = B = 0

PW(B, 1)

R(A, 1)

Sequential consistency

Memory

PW(A, 1)

R(B, 0)

Initially A = B = 0

PW(B, 1)

R(A, 1)

Sequential consistency

Memory

PW(A, 1)

R(B, 1)

Initially A = B = 0

PW(B, 1)

R(A, 0)

Sequential consistency

Memory

PW(A, 1)

R(B, 0)

Initially A = B = 0

PW(B, 1)

R(A, 0)

Dekker’s algorithm

Memory

PA := 1;if (B = 0) { CS}

Initially A = B = 0

PB := 1;if (A = 0) { CS}

Interconnect network

P1

C1

Memory +Directory

P2

C2

state[A] = INV state[A] = EXC

WR_REQ(A)

RDEX(A) FWD_RDEX(A, P1)

Interconnect network

P1

C1

Memory +Directory

P2

C2

state[A] = INV state[A] = INV

WR_REQ(A)

RDEX(A) FWD_RDEX(A, P1)

RDEX_ACK(A)

Interconnect network

P1

C1

Memory +Directory

P2

C2

state[A] = EXC state[A] = INV

WR_REQ(A)

RDEX(A) FWD_RDEX(A, P1)

RDEX_ACK(A)

WR_ACK(A)

• Programmers program according to a memory model

• System must satisfy memory model for software correctness

• Shared-memory systems are very complex

Parameterized shared-memory systems

Parameters: processors n, addresses mMemory actions: {R,W} {1,..,n} {1,..,m} ValInternal actions: I {1,..,n} {1,..,m}

State transition system: State variablesInitial predicateGuarded command for each action

State transition systemcache: array [1..n] of array [1..m] of {s: State, d: Val}queue: array [1..n] of Queue[m: Msg, a: [1..m]]…

(R,i,j,v) [] cache[i][j].s INV cache[i][j].d = v

(W,i,j,v) [] cache[i][j].s = EXC cache[i][j].d := v

(RRQ,i,j) [] cache[i][j].s = INV queue[i].enqueue(RD_REQ, j)…

(EventId, Proc, Addr, Data)

(WRQ, 2, 1)(WRP, 2, 1)(W, 2, 1, 1)(R, 1, 1, 0)(R, 2, 1, 1)(WRQ, 1, 1)(WRP, 1, 1)(R, 1, 1, 1)(W, 1, 1, 2)(RRQ, 2, 1)(RRP, 2, 1)(R, 2, 1, 2)

Run: finite action sequence

executable from initial state

Verification problem

Impl: state transition system with actions

Spec:1. Invariants, e.g., 1 i, j n. cache[i].s = EXC i j cache[j].s = INV2. Memory models, e.g., sequential consistency, Alpha memory model

Does Impl satisfy Spec?

(EventId, Proc, Addr, Data)

(WRQ, 2, 1)(WRP, 2, 1)(W, 2, 1, 1)(R, 1, 1, 0)(R, 2, 1, 1)(WRQ, 1, 1)(WRP, 1, 1)(R, 1, 1, 1)(W, 1, 1, 2)(RRQ, 2, 1)(RRP, 2, 1)(R, 2, 1, 2)

Run: finite action sequence

executable from initial state

Memory model

(R,1,1,0)

(R,1,1,1)

(W,1,1,2)

(EventId, Proc, Addr, Data)

(W,2,1,1)

(R,2,1,1)

(R,2,1,2)

Processor 1 Processor 2

• n partial orders, one for each processor• i th partial order on memory actions at processor i

Sequential consistency

(R,1,1,0)

(R,1,1,1)

(W,1,1,2)

(EventId, Proc, Addr, Data)

(W,2,1,1)

(R,2,1,1)

(R,2,1,2)

Processor 1 Processor 2

Sequential consistency(EventId, Proc, Addr, Data)

(R,1,1,0)

(W,2,1,1)

(R,2,1,1)

(R,1,1,1)

(W,1,1,2)

(R,2,1,2)

0

1

1

1

2

2

Addr 1(W,2,1,1)

(R,1,1,0)

(R,2,1,1)

(R,1,1,1)

(W,1,1,2)

(R,2,1,2)

swap!

Sequential consistency(EventId, Proc, Addr, Data)

(R,1,1,0)

(W,2,1,1)

(R,2,1,1)

(R,1,1,1)

(W,1,1,2)

(R,2,1,2)

Witness order

System S satisfies Model M iff

there is a witness order for every run

Debugging vs. Verification

McMillan, Schwalbe 91 Clarke et al. 93

Eiriksson, McMillan 95 Ip, Dill 96

Katz, Peled 92Alur et al. 96

Nalumasu et al. 98Henzinger et al. 99

Loewenstein, Dill 92Pong, Dubois 95

Park, Dill 96 Delzanno 00

Graf 94Henzinger et al. 99

TLA Plakal et al. 98

Invariants

ImplSpec

Memory models

Fixed parameters

Arbitraryparameters

needed in practice

Verifying Memory Models is Hard

Alur, McMillan, Peled 96 :

Checking sequential consistency for finiteparameter values is undecidable.

Contribution

Model checking algorithm to verify

a number of shared-memory models on

a useful class of shared-memory systemsfor

finite number of processors and addressesby

reduction to invariant verification.

Outline

• Introduction to shared-memory systems and models

• Model checking method for verifying models on systems

State transition systemcache: array [1..n] of array [1..m] of {s: State, d: Val}queue: array [1..n] of Queue[m: Msg, a: [1..m]]…

(R,i,j,v) [] cache[i][j].s INV cache[i][j].d = v

(W,i,j,v) [] cache[i][j].s = EXC cache[i][j].d := v

(RRQ,i,j) [] cache[i][j].s = INV queue[i].enqueue(RD_REQ, j)…

(EventId, Proc, Addr, Data)

(WRQ, 2, 1)(WRP, 2, 1)(W, 2, 1, 1)(R, 1, 1, 0)(R, 2, 1, 1)(WRQ, 1, 1)(WRP, 1, 1)(R, 1, 1, 1)(W, 1, 1, 2)(RRQ, 2, 1)(RRP, 2, 1)(R, 2, 1, 2)

Run: finite action sequence

executable from initial state

Data independence• Memory systems do not conjure up data values• Data values copied but not examined by actions

(except for read and write actions)• Every run can be generated from an unambiguous

run by suitably renaming data values.

(R,1,1,0)

(R,1,1,1)

(W,1,1,2)

(W,2,1,1)

(R,2,1,1)

(R,2,1,2)

Unambiguous run:

Suffices to analyze unambiguous runs!

(EventId, Proc, Addr, Data)

(R,1,1,0)

(R,1,1,1)

(W,1,1,2)

(W,2,1,1)

(R,2,1,1)

(R,2,1,2)

Unambiguous run:

Witness write order for address 1(W,2,1,1) (W,1,1,2)

System S satisfies Model M ifffor every run there are witness write orders for all addresses

acyclic graph

witness order

(EventId, Proc, Addr, Data)

Recipe for verification

For every unambiguous run,1. guess write order for each address2. generate graph and check for cycles

Interconnect network

P1

C1

Memory +Directory

P2

C2

state[A] = EXC state[A] = INV

WR_REQ(A)

RDEX(A) FWD_RDEX(A, P1)

RDEX_ACK(A)

WR_ACK(A)

Simple write order

For each location, order write events according to

actual occurrence order !!

Examples

• Piranha chip multiprocessor (Compaq)

• Wildfire challenge problem (Compaq)

• DASH multiprocessor (Stanford)

Recipe for verification

For every unambiguous run,1. guess write order for each address

• simple write order2. generate graph and check for cycles

. . .

(*,i,z,*)

. . .

(*,i,x,*)

. . .

. . .

(*,j,x,*)

. . .

(*,j,y,*)

. . .

. . .

(*,k,y,*)

. . .

(*,k,z,*)

. . .

Nice cycles

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

3-nice cycle:•3 processors i, j, k•3 addresses x, y, z

k-nice cycle involves k processors and k addresses

(EventId, Proc, Addr, Data)

Nice cycles

S has a cycle iff

S has a k-nice cycle for 1 k min(n,m)

S: memory system with n processors, m addresses

Lemma:

Recipe for verification

For every unambiguous run,1. guess write orders for each address

• simple write order2. generate graph and check for cycles

• reduce to nice cycles• detecting nice cycles by model checking

Detecting nice cycles

min(n,m) model checking lemmas: kth lemma checks for k-nice cycles

S has a cycle iff

S has a k-nice cycle for 1 k min(n,m)

S: memory system with n processors, m addresses

Lemma:

•Supj supplies write values for address j.

•Moni monitors memory events at processor i.

Memorysystem

Sup1 Mon1Model checker

Property = i. Moni@err1-nice cycle

Detecting nice cycles

Memorysystem

Sup1

Sup2

Mon1

Mon2

Model checker

Property = i. Moni@err

Detecting nice cycles

2-nice cycle

•Supj supplies write values for address j.

•Moni monitors memory events at processor i.

Memorysystem

Sup1

Sup2

Sup3

Mon1

Mon2

Mon3

Model checker

Property = i. Moni@err

Detecting nice cycles

3-nice cycle

•Supj supplies write values for address j.

•Moni monitors memory events at processor i.

. . .

(*,i,z,*)

. . .

(*,i,x,*)

. . .

. . .

(*,j,x,*)

. . .

(*,j,y,*)

. . .

. . .

(*,k,y,*)

. . .

(*,k,z,*)

. . .

Nice cycles

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

3-nice cycle:•3 processors i, j, k•3 addresses x, y, z

(EventId, Proc, Addr, Data)

Unambiguous run:

(R,1,1,0)

(R,1,1,1)

(W,1,1,2)

(W,2,1,1)

(R,2,1,1)

(R,2,1,2)

(EventId, Proc, Addr, Data)

Witness write order for address 1(W,2,1,1) (W,1,1,2)

Causal edges

Anti-causal edges

Supplier automata

Supplies 0 upto some nondeterministicallychosen write and then supplies 1 forever.

0

1

1

Supx (supplier for address x):

. . .

(*,i,z,1)

. . .

(*,i,x,0)

. . .

. . .

(*,j,x,1)

. . .

(*,j,y,0)

. . .

. . .

(*,k,y,1)

. . .

(*,k,z,0)

. . .

Nice cycles

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

3-nice cycle:•3 processors i, j, k•3 addresses x, y, z

(EventId, Proc, Addr, Data)

Monitor automata

Monj:

(*,j,x,1) (*,j,y,0)err

Analysis for sequential consistency

Number of processors = nNumber of addresses = mNumber of model checking runs = min(n,m)

Number of Sup automata = kNumber of Mon automata = kFor all j, number of states in Supj = 3

For all i, number of states in Moni = 3States in model checked system = |S|3k3k

kth model checking run (1 k min(n,m)):

Model checker

Property = i. Moni@err

Other memory models?Alpha memory model, partial store order,

release consistency, weak ordering

Memorysystem

Sup1

Sup2

Sup3

Mon1

Mon2

Mon3

Model checker

Property = i. Moni@err

Other write orders?

Can be generalized !!

Memorysystem

Sup1

Sup2

Sup3

Mon1

Mon2

Mon3

Wildfire challenge problem

• 2 processor, 2 location system– Supplier and monitor automata constructed– Seeded bug was found by invariant

verification on composed system by model checker TLC

Summary

Model checking algorithm to verify

a number of shared-memory models on

a useful class of shared-memory systemsfor

finite number of processors and addressesby

reduction to invariant verification.