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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend