1. Eran Yahav 1

2. Previously…  An algorithmic view  Abstract data types (ADT)  Correctness Conditions  Sequential consistency  Linearizability  Treiber’s stack  Atomic Snapshot 2

3. Today 3  A verification view  Assigning meaning to programs  Trace semantics  Properties  Abstract data types (ADT)  Sequential ADTs over traces  Concurrent ADTs?  Correctness Conditions  Sequential consistency  Linearizability  Treiber’s stack  Atomic Snapshot

4. Overview of Verification Techniques “The desire for brevity combined with a poor memory has led me to omit a great deal of significant work” -- Lamport 4

5. What is the “meaning” of a program? 5 int foo(int a ) { if( 0 < a < 5) c = 42 else c = 73; return c; } int a() { printf(“a”); return 1; } int b() { printf(“b”); return 2; } int c() { printf(“c”); return 3; } int sum(int x, int y, int z) { return x+y+z; } void bar() { printf(“%d”, sum(a(),b(),c()); }

6. Semantics “mathematical models of and methods for describing and reasoning about the behavior of programs” 6

7. Why Formal Semantics?  implementation-independent definition of a programming language  automatically generating interpreters (and some day maybe full fledged compilers)  verification and debugging  if you don’t know what it does, how do you know its incorrect? 7

8. Different Approaches  Denotational Semantics  define an input/output relation that assigns meaning to each construct (denotation)  Structural Operational Semantics  define a transition system, transition relation describes evaluation steps of a program  Axiomatic Semantics  define the effect of each construct on logical statements about program state (assertions) 8

9. Denotational Semantics 9 λx.2*x int double1(int x) { int t = 0; t = t + x; return t; } int double2(int x) { int t = 2*x; return t; }

10. Operational Semantics 10 int double1(int x) { int t = 0; t = t + x; return t; } int double2(int x) { int t = 2*x; return t; } [t  0, x  2] x  2 [t  2, x  2] [t  4, x  2]

11. Axiomatic Semantics 11 int double1(int x) { { x = x 0 } int t = 0; { x = x 0  t = 0 } t = t + x; { x = x 0  t = x 0 } t = t + x; { x = x 0  t = 2*x 0 } return t; } int double2(int x) { { x = x 0 } int t = 2*x; { x = x 0  t = 2*x 0 } return t; }

12. Relating Semantics 12

13. What is the “meaning” of this program? 13 [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y − 1] 5 ; ) [y := 0] 6

14. what is the “meaning” of an arithmetic expression?  z * y  y – 1  First: syntax of simple arithmetic expressions  For now, assume no variables  a ::= n | a1 + a2 | a1 – a2 | a1 * a2 | (a1) 14

15. Structural Operational Semantics  Defines a transition system ( , ,T)  configurations  : snapshots of current state of the program  transitions    : steps between configurations  final configurations T   15 11 22 33 44  = {  1,  2,  3,  4 }  = { (  1,  2 ), (  1,  4 ), (  2,  3 ) } T = {  3,  4 }

16.  We write    ’ when ( ,  ’)     * denotes the reflexive transitive closure of the relation     *  ’ when there is a sequence  =  0   1  …  n =  ’ for some n  0 16 Structural Operational Semantics Useful Notations

17. Big-step vs. Small-step  Big-step     ’ describes the entire computation   ’ is always a terminal configuration  Small-step      ’ describes a single step of a larger computation   ’ need not be a terminal configuration  pros/cons to each  big-step hard in the presence of concurrency 17

18. Simple Arithmetic Expressions (big step semantics) 18 [Plus] a1  v1 a2  v2 a1 + a2  v where v = v1 + v2 a  v means “expression a evaluates to the value v” a  AExp, v  Z conclusion premises side condition

19. Simple Arithmetic Expressions (big step semantics) 19 [Plus] a1  v1 a2  v2 a1 + v1  v where v = v1 + v2 [Minus] a1  v1 a2  v2 a1 - v1  v where v = v1 - v2 [Mult] a1  v1 a2  v2 a1 * v1  v where v = v1 * v2 [Paren] a1  v1 (a1)  v [Num] n  v if N  n  = v

20.  Transition system ( , ,T)  configurations  = AExp  Z  transitions    : defined by the rules on the previous slide  final configurations T = Z  Transitions are syntax directed 20 Simple Arithmetic Expressions (big step semantics)

21. Derivation Tree  show that ( 2 + 4 )*( 4 + 3 )  42 21 2  2 4  4 2 + 4  6 4  4 3  3 4 + 3  7 2 + 4  6 (2 + 4)  6 4 + 3  7 (4 + 3)  7 (2+4)  6 (4 + 3)  7 (2+4)*(4 + 3)  42 2  2 4  4 3  3

22. 22 [Plus-1] a1  a1’ a1 + a2  a1’ + a2 [Plus-2] a2  a2’ a1 + a2  a1 + a2’ [Plus-3] v1 + v2  v where v = v1+ v2 Simple Arithmetic Expressions (small step semantics) intermediate values intermediate configurations

23. Small Step and Big Step 23  0   1  1   2  2   3  0   3 small step big step

24. The WHILE Language: Syntax A  AExp arithmetic expressions B  BExp boolean expressions S  Stmt statements Var set of variables Lab set of labels Op a arithmetic operators Op b boolean operators Op r relational operators a ::= x | n | a1 op a a2 b ::= true | false | not b | b1 op b b2 | a1 op r a2 S ::= [x := a] lab | [skip] lab | S1;S2 | if [b] lab then S1 else S2 | while [b] lab do S (We are going to abuse syntax later for readability) 24

25. The WHILE Language: Structural Operational Semantics   State = Var  Z Configuration:  for terminal configuration Transitions:    ’ 25 Both the statement that remains to be executed, and the state, can change

26. The WHILE Language: Structural Operational Semantics  Transition system ( , ,T)  configurations  = (Stmt  State)  State  transitions     final configurations T = State 26

27. The WHILE Language: Structural Operational Semantics (Table 2.6 from PPA) [seq 1 ]  [seq 2 ]  ’    [x  A  a  ][ass]  [skip] 27

28. The WHILE Language: Structural Operational Semantics (Table 2.6 from PPA)  if B  b   = true [if 1 ]  if B  b   = false [if 2 ]  if B  b   = true [wh 1 ]   if B  b   = false [wh 1 ] 28

29. Derivation Sequences  Finite derivation sequence  A sequence …  n     n terminal configuration  Infinite derivation sequence  A sequence …   29

30. Termination in small-step semantics 30 1: while (0 = 0) ( 2: skip; )   …

31.  We say that S terminates from a start state  when there exists a state  ’ such that  *  ’ 31 Termination in small-step semantics

32. Termination in big-step semantics  what would be the transition in the big-step semantics for this example? 32 while [0 = 0] 1 ( [skip] 2 ; )

33. Semantic Equivalence  formal semantics enables us to reason about programs and their equivalence  S1 and S2 are semantically equivalent when  for all  and  ’  *  ’ iff  *  ’  We write S1  S2 when S1 and S2 are semantically equivalent 33

34. Abnormal Termination  add a statement abort for aborting execution  in the big-step semantics  while (0=0) skip;  abort  big-step semantics does not distinguish between abnormal termination and infinite-loops  in the small-step semantics  while (0=0) skip;  abort  but we can distinguish the cases if we look at the transitions   0  infinite trace of skips 34

35. What is the “meaning” of this program? 35 [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y − 1] 5 ; ) [y := 0] 6 now we can answer this question using derivation sequences

36. Example of Derivation Sequence [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y − 1] 5 ; ) [y := 0] 6 0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  0, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 }> … 36

37. Traces 0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  0, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 }> … 0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  0, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 }> … [y := x] 1 [z := 1] 2 [y > 0] 3 37

38. Traces 0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  0, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 }> … [y := x] 1 [z := 1] 2 [y > 0] 3  … [y := x] 1 [z := 1] 2 [y > 0] 3 38

39. Traces  … [y := x] 1 [z := 1] 2 [y > 0] 3 39

40. Trace Semantics  In the beginning, there was the trace semantics…  note that input (x) can be anything  clearly, the trace semantics is not computable [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y − 1] 5 ; ) [y := 0] 6 … 40    … [y := x] 1 [z := 1] 2 [y > 0] 3    … [y := x] 1 [z := 1] 2 [y > 0] 3

41. Specification  Set of traces that satisfy the property 41

42. Abstract Data Types  Raise the level of abstraction  Work on (complex) data types as if their operations are primitive operations  What does it mean technically? 42 clientADT

43. Hiding ADT implementation  What should we require from the ADT?  When can we replace one ADT implementation with another ADT implementation? 43 All operations exposed Hiding ADT operation Client steps ADT steps Client steps ADT big step

44. Splitting Specification between Client and ADT  Specify the requirements from an ADT  Show that an ADT implementation satisfies its spec  Verify a client using the ADT specification (“big step”) instead of using/exposing its internal implementation 44

45. ADT Specification  Typically: each operation specified using precondition/postcondition  (implicitly: the meaning is the set of traces that satisfy the pre/post) 45 EffectReturn value Insert(a)S’ = S U { a}a  S Remove(a)S = S \ { a }a  S Contains(a)a  S Example: operations over a set ADT

46. ADT Verification  Show that the implementation of each operation satisfies its spec  Simple example: counter ADT 46 int tick() { t = val val = t+1 return t } EffectReturn value tick()C’ = C + 1C

47. Client Verification 47 Module three-ticks { Counter c = new Counter(); int bigtick() { c.tick(); t = c.tick(); return t; } Regardless of how the counter ADT is implemented, client verification can reason at the level of ADT operations Client steps ADT steps return tick beforeafter Clear notion of before/after an ADT operation

48. Client Verification 48 Module three-ticks { Counter c = new Counter(); int bigtick() { { c.value = prev } c.tick(); { c.value = prev + 1 } c.tick(); { c.value = prev + 2 } t = c.tick(); { c.value = prev + 3, t = prev + 2 } return t; }

49. Adding concurrency  How do we tell the client what it can assume about the ADT?  No clear notion of “before” and “after” an operation  When can we check the precondition and guarantee that the postcondition holds?  When operations are not atomic, there is possible overlap 49

50. Two views  “Lamportism” – there should be a global invariant of the system that holds on every step  “Owicki-Gries-ism” – generalize sequential pre/post proofs to concurrent setting  Really, having a local invariant at a program point (taking into account the possible states of other threads) 50

51. ADT Verification  Not true anymore, depends on other tick() operations that may be running concurrently 51 int tick() { t = val val = t+1 return t } EffectReturn value tick()C’ = C + 1C

52. ADT Verification 52 int tick() { t = val val = t+1 return t } EffectReturn value tick()C’ = C + 1C val = 0 t = valval = t+1 t = valval = t + 1 return t = 0 T1 T2 

53. Concurrent Counter int tick() { lock(L) t = val val = t+1 unlock(L) return t } val = 0 t = valval = t+1 t = val ret t = 0 lock(L) unlock(L) T1 T2 53

54. What guarantees can the ADT provide to clients?  Linearizability  If operations don’t overlap, you can expect same effect as serial execution  When operations overlap, you can expect some serial witness (with a potentially different ordering of operations)  Correctness does not depend on other operations/object used in the client  Locality 54

55. Optimistic Concurrent Counter bool CAS(addr, old, new) { atomic { if (*addr == old) { *addr = new; return true; } else return false; } int tick() { restart: old = val new = old + 1 if CAS(&val,old,new) return old else goto restart return t } Only restart when another thread changed the value of “val” concurrently Lock-free (but not wait-free) CAS in operation fails only when another operation succeeds note: failed CAS has no effect 55

56. tick / 0 tick / 1 tick / 0 Correctness of the Concurrent Counter  Linearizability [Herlihy&Wing 90]  Counter should give the illusion of a sequential counter tick / 1 tick / 0tick / 1 T1 T2 T1 T2 Tick / 1 Tick / 0 T1 T2 T1 T2 tick / 0  56

57. References  “Transitions and Trees” / Huttel  “Principles of Program Analysis” / Nielson, Nielson, and Hankin 57

58. Backup slides 58

59. Client Verification 59 int bigtick() { { c.value = prev } c.tick(); { c.value = prev + 1 } c.tick(); { c.value = prev + 2 } t = c.tick(); { c.value = prev + 3, t = prev + 2 } return t; } int bigtick() { { c.value = prev } c.tick(); { c.value = prev + 1 } c.tick(); { c.value = prev + 2 } t = c.tick(); { c.value = prev + 3, t = prev + 2 } return t; } Now what?

60. Determinacy  We would like the big-step semantics of arithmetic expressions to be deterministic  a  v1 and a  v2 then v1 = v2  induction on the height of the derivation tree (“transition induction”)  show that rules for roots are deterministic  show that transition rules are deterministic 60

61. Determinacy  Is the small-step semantics of arithmetic expressions deterministic?  we want  if a  v1 and a  v2 then v1 = v2  but we have, for example  2 +3  2 + 3 61

62. Arithmetic Expressions 62 A: AExp  (State  Z) A  x  =  (x) A  n  = N  n  A  a1 op a2  = A  a1  op A  a2 

63. Boolean Expressions 63 B: BExp  (State  { true, false} ) B  not b  =  B  b  B  b1 op b b2  = B  b1  op b B  b2  B  a1 op r a2  = A  a1  op r A  a2 

64. Derivation Tree 64 2  2 4  4 2 + 4  6 4  4 3  3 4 + 3  7 (2 + 4)  6(4 + 3)  7 (2+4)*(4 + 3)  42

65. Nondeterminism big-step semantics  new language construct s1 OR s2 65 [OR1-BSS]   ’ [OR2-BSS]   ’

66. Nondeterminism small-step semantics 66 [OR1-SSS]  [OR1-SSS] 

67. Nondeterminism  (x = 1) OR while(0=0) skip;  big-step semantics suppresses infinite loops  small step semantics has the infinite sequence created by picking the while 67   …