1 / 60

Verification of architectural memory models by model checking

Verification of architectural memory models by model checking. Shaz Qadeer Compaq Systems Research Center Shaz.Qadeer@compaq.com. Outline. Introduction to shared-memory systems and models Model checking method for verifying models on systems. Multithreaded program. Language memory model

lindsey
Download Presentation

Verification of architectural memory models by model checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verification of architectural memory models by model checking Shaz Qadeer Compaq Systems Research Center Shaz.Qadeer@compaq.com

  2. Outline • Introduction to shared-memory systems and models • Model checking method for verifying models on systems

  3. Multithreaded program Language memory model (Java, Modula-3, C with threads) Compiler Executable code Multiprocessor

  4. Multiprocessor P P P INTERCONNECT NETWORK P P P

  5. Multiprocessor Architectural memory model (SC, Alpha, Sun) 

  6. Multithreaded program Language memory model (Java, Modula-3, C with threads) Compiler Executable code Multiprocessor

  7. Multithreaded program Language memory model (Java, Modula-3, C with threads) Compiler Executable code Architectural memory model (SC, Alpha, Sun)

  8. Multiprocessor Verification Problem ? Architectural memory model (SC, Alpha, Sun) 

  9. Uniprocessor Initially A = B = 0 P A := 1; if (B = 0) { ... } Memory

  10. Shared-memory multiprocessor Initially A = B = 0 P P A := 1; if (B = 0) { ... } B := 1; if (A = 0) { ... } Memory

  11. Shared-memory model Initially A = B = 0 P P W(A, 1) R(B, ?) W(B, 1) R(A, ?) Memory

  12. Sequential consistency Initially A = B = 0 P P W(A, 1) R(B, 1) W(B, 1) R(A, 1) Memory

  13. Sequential consistency Initially A = B = 0 P P W(A, 1) R(B, 0) W(B, 1) R(A, 1) Memory

  14. Sequential consistency Initially A = B = 0 P P W(A, 1) R(B, 1) W(B, 1) R(A, 0) Memory

  15. Initially A = B = 0 P P W(A, 1) R(B, 0) W(B, 1) R(A, 0) Memory Sequential consistency

  16. Dekker’s algorithm Initially A = B = 0 P P A := 1; if (B = 0) { CS } B := 1; if (A = 0) { CS } Memory

  17. RDEX(A) FWD_RDEX(A, P1) state[A] = INV state[A] = EXC P1 P2 WR_REQ(A) C1 C2 Interconnect network Memory + Directory

  18. RDEX(A) FWD_RDEX(A, P1) state[A] = INV state[A] = INV P1 P2 RDEX_ACK(A) WR_REQ(A) C1 C2 Interconnect network Memory + Directory

  19. RDEX(A) FWD_RDEX(A, P1) state[A] = EXC state[A] = INV P1 P2 RDEX_ACK(A) WR_REQ(A) WR_ACK(A) C1 C2 Interconnect network Memory + Directory

  20. Programmers program according to a memory model • System must satisfy memory model for software correctness • Shared-memory systems are very complex

  21. Parameterized shared-memory systems Parameters: processors n, addresses m Memory actions: {R,W}  {1,..,n}  {1,..,m}  Val Internal actions: I  {1,..,n}  {1,..,m} State transition system: State variables Initial predicate Guarded command for each action

  22. State transition system cache: 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) …

  23. (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

  24. 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 = INV 2. Memory models, e.g., sequential consistency, Alpha memory model Does Impl satisfy Spec?

  25. (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

  26. Memory model (EventId, Proc, Addr, Data) Processor 1 Processor 2 (R,1,1,0) (R,1,1,1) (W,1,1,2) (W,2,1,1) (R,2,1,1) (R,2,1,2) • n partial orders, one for each processor • i th partial order on memory actions at processor i

  27. Sequential consistency (EventId, Proc, Addr, Data) Processor 1 Processor 2 (R,1,1,0) (R,1,1,1) (W,1,1,2) (W,2,1,1) (R,2,1,1) (R,2,1,2)

  28. (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) Addr 1 0 1 1 1 2 2 (R,1,1,0) (W,2,1,1) (R,2,1,1) (R,1,1,1) (W,1,1,2) (R,2,1,2)

  29. Sequential consistency (EventId, Proc, Addr, Data) Witness order (R,1,1,0) (W,2,1,1) (R,2,1,1) (R,1,1,1) (W,1,1,2) (R,2,1,2) System S satisfies Model M iff there is a witness order for every run

  30. Impl needed in practice Fixed parameters Arbitrary parameters Spec Invariants Memory models Debugging vs. Verification McMillan, Schwalbe 91 Clarke et al. 93 Eiriksson, McMillan 95 Ip, Dill 96 Loewenstein, Dill 92 Pong, Dubois 95 Park, Dill 96 Delzanno 00 Graf 94 Henzinger et al. 99 TLA Plakal et al. 98 • Katz, Peled 92 • Alur et al. 96 • Nalumasu et al. 98 • Henzinger et al. 99

  31. Verifying Memory Models is Hard Alur, McMillan, Peled 96 : Checking sequential consistency for finite parameter values is undecidable.

  32. Contribution Model checking algorithm to verify a number of shared-memory models on a useful class of shared-memory systems for finite number of processors and addresses by reduction to invariant verification.

  33. Outline • Introduction to shared-memory systems and models • Model checking method for verifying models on systems

  34. State transition system cache: 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) …

  35. (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

  36. 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. Unambiguous run: (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) Suffices to analyze unambiguous runs!

  37. 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)  acyclic graph  witness order Witness write order for address 1 (W,2,1,1) (W,1,1,2) (EventId, Proc, Addr, Data) System S satisfies Model M iff for every run there are witness write orders for all addresses

  38. Recipe for verification For every unambiguous run, 1. guess write order for each address 2. generate graph and check for cycles

  39. RDEX(A) FWD_RDEX(A, P1) state[A] = EXC state[A] = INV P1 P2 RDEX_ACK(A) WR_REQ(A) WR_ACK(A) C1 C2 Interconnect network Memory + Directory

  40. Simple write order For each location, order write events according to actual occurrence order !!

  41. Examples • Piranha chip multiprocessor (Compaq) • Wildfire challenge problem (Compaq) • DASH multiprocessor (Stanford)

  42. Recipe for verification • For every unambiguous run, • 1. guess write order for each address • simple write order • 2. generate graph and check for cycles

  43. Nice cycles • 3-nice cycle: • 3 processors  i, j, k • 3 addresses  x, y, z (EventId, Proc, Addr, Data) . . . . . . . . . . . . . . . . . . (*,i,z,*) . . . (*,i,x,*) . . . . . . (*,j,x,*) . . . (*,j,y,*) . . . . . . (*,k,y,*) . . . (*,k,z,*) . . . . . . . . . . . . . . . . . . k-nice cycle involves k processors and k addresses

  44. Nice cycles S: memory system with n processors, m addresses Lemma: S has a cycle iff S has a k-nice cycle for 1  k  min(n,m)

  45. Recipe for verification • For every unambiguous run, • 1. guess write orders for each address • simple write order • 2. generate graph and check for cycles • reduce to nice cycles • detecting nice cycles by model checking

  46. Detecting nice cycles S: memory system with n processors, m addresses Lemma: S has a cycle iff S has a k-nice cycle for 1  k  min(n,m)  min(n,m) model checking lemmas: kth lemma checks for k-nice cycles

  47. Property  = i. Moni@err Model checker Detecting nice cycles • Supj supplies write values for address j. • Moni monitors memory events at processor i. 1-nice cycle Sup1 Mon1 Memory system

  48. Property  = i. Moni@err Model checker Detecting nice cycles • Supj supplies write values for address j. • Moni monitors memory events at processor i. 2-nice cycle Sup1 Mon1 Memory system Sup2 Mon2

  49. Property  = i. Moni@err Sup1 Mon1 Memory system Sup2 Mon2 Model checker Sup3 Mon3 Detecting nice cycles • Supj supplies write values for address j. • Moni monitors memory events at processor i. 3-nice cycle

More Related