towards a separation logic for multicore ocaml
play

Towards a separation logic for Multicore OCaml Glen Mvel , - PowerPoint PPT Presentation

Towards a separation logic for Multicore OCaml Glen Mvel , Jacques-Henri Jourdan, Franois Pottier May 25, 2020 PPS seminar, Paris CNRS & Inria, Paris, France The weak memory model Multicore OCaml Extension of the OCaml language with


  1. Towards a separation logic for Multicore OCaml Glen Mével , Jacques-Henri Jourdan, François Pottier May 25, 2020 PPS seminar, Paris CNRS & Inria, Paris, France

  2. The weak memory model

  3. Multicore OCaml Extension of the OCaml language with multicore programming . Research project at OCaml Labs (Cambridge), will be merged eventually. Strengths: • brings multicore abilities to a functional, statically typed, memory-safe programming language; • (gives the programmer a simpler memory model than that of C11, hopefully;) • limited performance drop for sequential code. Goals of this PhD: • Build a proof system for Multicore OCaml programs. • Prove interesting concurrent data structures. 1

  4. Sequential consistency Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%. 2

  5. Sequential consistency Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%. 2

  6. Sequential consistency Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%. 2

  7. Sequential consistency Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%. 2

  8. A weaker memory model Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1), (0, 0). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%, 0.1%. 2

  9. A weaker memory model Consider this concurrent program: x := 0 y := 0 x := 1 y := 1 A := y B := x Possible outcomes (A, B): (0, 1), (1, 0), (1, 1), (0, 0). Observed (M.OCaml on 2-core x86-64) : 91%, 9%, 0.001%, 0.1%. The compiler may reorder a write after a read. (The processor too.) 2

  10. Weak memory models Sequential consistency is unrealistic. We need a weaker memory model , where different threads have different views of the shared state. The model should be specific to our language. Existing works: Java (2000s), C11 (2010s; also Rust). Candidate model for Multicore OCaml: Dolan, Sivaramakrishnan, Madhavapeddy. Bounding Data Races in Space and Time . PLDI 2018. Two access modes: non-atomic, atomic. 3

  11. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x 4

  12. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x Each non-atomic location has a history , i.e. a map from timestamps to values (timestamps are per location). x : x0 y : y 0 4

  13. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x Each non-atomic location has a history , i.e. a map from timestamps to values (timestamps thread B thread A are per location). x : x0 y : y Each thread has its own view of the 0 non-atomic store, i.e. a map from non-atomic locations to timestamps. 4

  14. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x non-atomic write thread B thread A • Timestamp must be fresh. x : x0 x1 • Timestamp must be newer than y : y 0 current thread’s view. • Current thread’s view is updated. 4

  15. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x non-atomic write thread B thread A • Timestamp must be fresh. x : x0 x1 • Timestamp must be newer than y : y y 0 1 current thread’s view. • Current thread’s view is updated. 4

  16. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x thread B thread A non-atomic read x : x0 x1 • Returns any value at least as recent as current thread’s view. y : y y 0 1 • Current thread’s view is unchanged. 4

  17. An operational model for Multicore OCaml: non-atomics x := x 1 y := y 1 A := !y B := !x thread B thread A non-atomic read x : x0 x1 • Returns any value at least as recent as current thread’s view. y : y y 0 1 • Current thread’s view is unchanged. 4

  18. An operational model for Multicore OCaml: atomics Non-atomic locations are useful for updating the state locally, but they don’t provide synchronization. Atomic locations allow the message-passing idiom. 5

  19. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x thread B thread A x : x0 a : false 6

  20. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A Each atomic location stores one value, x : x0 and one view of the non-atomic store. a : false 6

  21. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A x : x0 a : false 6

  22. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A x : x0 x1 a : false 6

  23. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A atomic write x : x0 x1 Merges the writer’s view into the atomic location’s view. a : true 6

  24. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A atomic read x : x0 x1 Merges the atomic location’s view into the reader’s view. a : true 6

  25. An operational model for Multicore OCaml: atomics x := x 1 REPEAT a := at true C := ! at a UNTIL C = true B := !x atomic a thread B thread A x : x0 x1 a : true 6

  26. Our program logic

  27. Rules of non-atomic locations The predicate x �→ v means that we own the non-atomic location x and that we have seen its latest value, which is v . Non-atomic write: { x �→ v } x := v ′ { λ () . x �→ v ′ } Non-atomic read: { x �→ v } ! x { λ v ′ . v ′ = v ∗ x �→ v } 7

  28. Impact of the weak memory model on our CSL Invariants are the mechanism by which threads can share propositions in a Concurrent Separation Logic such as Iris: { P ∗ I } e { Q ∗ I } e atomic ⊢ { P } e { Q } I The proposition x �→ v is subjective : its truth depends on the thread’s view of memory. It is unsound to share it via an invariant. Propositions which are true in all threads are called objective : • “pure” facts, such as v = 5 • ghost state, such as γ ֒ → ◦ 5 • atomic state, such as a �→ at ( v , V ) Only objective propositions can be put in an invariant. 8

  29. Rules of atomic locations (simplified) The predicate a �→ at v means that we own the atomic location a , which stores the value v . It is objective . Atomic write: { a �→ at v } a := at v ′ { λ () . a �→ at v ′ } Atomic read: { a �→ at v } ! at a { λ v ′ . v ′ = v ∗ a �→ at v } 9

  30. Rules of atomic locations (simplified) The predicate a �→ at v means that we own the atomic location a , which stores the value v . It is objective . Atomic write: views { a �→ at v } Views are ordered by inclusion. a := at v ′ { λ () . a �→ at v ′ } The predicate ↑ V means “the Atomic read: current thread’s view includes V ”. { a �→ at v } ! at a { λ v ′ . v ′ = v ∗ a �→ at v } 9

  31. Rules of atomic locations The predicate a �→ at ( v , V ) means that we own the atomic location a , which stores the value v and a view (at least) V . It is objective . Atomic write: views { a �→ at ( v , V ) ∗ ↑ V ′ } Views are ordered by inclusion. a := at v ′ { λ () . a �→ at ( v ′ , V ′ ) } The predicate ↑ V means “the Atomic read: current thread’s view includes V ”. { a �→ at ( v , V ) } ! at a { λ v ′ . v ′ = v ∗ a �→ at ( v , V ) ∗ ↑ V } 9

  32. Rules of atomic locations The predicate a �→ at ( v , V ) means that we own the atomic location a , which stores the value v and a view (at least) V . It is objective . Atomic write: views { a �→ at ( v , V ) ∗ ↑ V ′ } Views are ordered by inclusion. a := at v ′ { λ () . a �→ at ( v ′ , V ′ ⊔ V ) ∗ ↑ V } The predicate ↑ V means “the Atomic read: current thread’s view includes V ”. { a �→ at ( v , V ) } ! at a { λ v ′ . v ′ = v ∗ a �→ at ( v , V ) ∗ ↑ V } 9

  33. Propositions are monotonic Subjective propositions are monotonic w.r.t. the thread’s view. One reason: the frame rule: { a �→ at v ∗ P } a := at v ′ { λ () . a �→ at v ′ ∗ P } 10

  34. Propositions are monotonic Subjective propositions are monotonic w.r.t. the thread’s view. One reason: the frame rule: { a �→ at v ∗ P this holds at the thread’s current view } a := at v ′ { λ () . a �→ at v ′ ∗ P this holds at the thread’s now extended view } 10

  35. The message passing idiom The objective proposition “ P at V ” is the subjective proposition P seen at a fixed view V . P ⇐ ⇒ ∃V . ( ↑ V ) ∗ ( P at V ) ( ⇒ ) If P holds now, then it holds at the current view. ( ⇐ ) If P holds at some earlier view, then it holds now. 11

Recommend


More recommend