1. K. Rustan M. Leino RiSE, Microsoft Research, Redmond joint work with Peter Müller and Jan Smans Lecture 0 1 September 2009 FOSAD 2009, Bertinoro, Italy

2. Prove program correctness for all possible inputs and behaviors

3. Prove parts of a program separately Correctness of every part implies correctness of whole program

4. Record programmer design decisions Describe usage of program constructs Provide redundancy Enable modular verification

5. Specification and verification methodology Describes properties of the heap Active area of research Ownership Spec#, Java+JML, vcc, type systems, … Dynamic frames VeriCool, Dafny Permissions (capabilities) Effect systems, separation logic, VeriCool 3, Chalice, …

6. Interleaving of thread executions Unbounded number of: threads, locks, … We need some basis for doing the reasoning A way of thinking!

7. Concurrent programs Features like: threads, monitors, abstraction as well as: objects, methods, loops, … Avoid errors like: race conditions, deadlocks Specifications with permissions Building a program verifier

8. Pre- and postconditions

9. Loop invariants

10. Chalice

11. Helps testing find bugs more quickly Optional, they can be treated as ghosts If they are to be ghosted, specifications must have no side effects (on non-ghost state)

12. Access to a memory location requires permission Permissions are held by activation records Syntax for talking about permission to y: acc(y)

13. Permissions

14. method Main() { var c := new Counter; call c.Inc(); } method Main() { var c := new Counter; call c.Inc(); } method Inc() requires acc(y) ensures acc(y) { y := y + 1; } method Inc() requires acc(y) ensures acc(y) { y := y + 1; } acc(c.y)

15. A specification expression can mention a memory location only if it also entails the permission to that location acc(y) && y < 100 y < 100  acc(x) && y < 100  acc(o.y) && p.y < 100  o == p && acc(o.y) && p.y < 100 x / y < 20  y ≠ 0 && x / y < 20

16. A loop iteration is like its own activation record is like Before; while (B) invariant J { S; } After; Before; while (B) invariant J { S; } After; Before;method MyLoop(…) call MyLoop(…);requires J After; ensures J { if (B) { S; call MyLoop(…); } } Before;method MyLoop(…) call MyLoop(…);requires J After; ensures J { if (B) { S; call MyLoop(…); } }

17. method M() requires acc(x) && acc(y) && x <= 100 && y <= 100 { while (y < 100) invariant acc(y) && y <= 100 { y := y + 1; x := x + 1; // error: no permission to access x } assert x <= y; } method M() requires acc(x) && acc(y) && x <= 100 && y <= 100 { while (y < 100) invariant acc(y) && y <= 100 { y := y + 1; x := x + 1; // error: no permission to access x } assert x <= y; }

18. method M() requires acc(x) && acc(y) && x <= 100 && y <= 100 { while (y < 100) invariant acc(y) && y <= 100 { y := y + 1; } assert x <= y; } method M() requires acc(x) && acc(y) && x <= 100 && y <= 100 { while (y < 100) invariant acc(y) && y <= 100 { y := y + 1; } assert x <= y; }

19. Loop invariants with permissions

20. Threads run concurrently A new thread of control is started with the fork statement A thread can wait for another to complete with the join statement Permissions are transferred to and from a thread via the starting method’s pre- and postconditions

21. Fork and join

22. call == fork + join is semantically like … but is implemented more efficiently call x,y := o.M(E, F); fork tk := o.M(E, F); join x,y := tk; fork tk := o.M(E, F); join x,y := tk;

23. Parallel computation

24. Recall: A specification expression can mention a memory location only if it also entails some permission to that location Example: acc(y) && y < 100 Without any permission to y, other threads may change y, and then y would not be stable

25. acc(y)write permission to y rd(y)read permission to y At any one time, at most one thread can have write permission to a location

26. Parallel reads

27. acc(y)100% permission to y acc(y, p)p% permission to y rd(y)read permission to y Write access requires 100% Read access requires >0% = +  acc(y)acc(y,69) acc(y,31) rd(y) acc(y,  )

28. method M() requires acc(y) ensures acc(y) can change y Can method P() requires rd(y) ensures rd(y) change y? That is, can we prove: method Q() requires rd(y) && y == 5 { call P(); assert y == 5; } method Q() requires rd(y) && y == 5 { call P(); assert y == 5; } Demo: NoPerm

29. What if two threads want write access to the same location? method A() … { y := y + 21; } method A() … { y := y + 21; } method B() … { y := y + 34; } method B() … { y := y + 34; } class Fib { var y: int; method Main() { var c := new Fib; fork c.A(); fork c.B(); } class Fib { var y: int; method Main() { var c := new Fib; fork c.A(); fork c.B(); } acc(c.y)

30. method A() … { acquire this; y := y + 21; release this; } method A() … { acquire this; y := y + 21; release this; } method B() … { acquire this; y := y + 34; release this; } method B() … { acquire this; y := y + 34; release this; } class Fib { var y: int; invariant acc(y); method Main() { var c := new Fib; share c; fork c.A(); fork c.B(); } class Fib { var y: int; invariant acc(y); method Main() { var c := new Fib; share c; fork c.A(); fork c.B(); } acc(c.y) acc(y)

31. Like other specifications, can hold both permissions and conditions Example: invariant acc(y) && 0 <= y acc(y)

32. thread local shared, available shared, locked new share acquire release

33. Monitors

34. The concepts holding a lock, and having permissions are orthogonal to one another In particular: Holding a lock does not imply any right to read or modify shared variables Their connection is: Acquiring a lock obtains some permissions Releasing a lock gives up some permissions

35. Server-side locking “safer” (requires less thinking) Client-side locking more efficient invariant acc(y); method M() requires true { acquire this; y := …; release this; } invariant acc(y); method M() requires true { acquire this; y := …; release this; } method M() requires acc(y) { y := …; } method M() requires acc(y) { y := …; }