Proving liveness. Alexey Gotsman IMDEA Software Institute

Size: px
Start display at page:

Download "Proving liveness. Alexey Gotsman IMDEA Software Institute"

Transcription

1 Proving liveness Alexey Gotsman IMDEA Software Institute

2 Safety properties Ensure bad things don t happen: - the program will not commit a memory safety fault - it will not release a lock it does not hold Counterexamples: finite executions

3 Liveness properties Ensure good things eventually happen: - the program eventually terminates - whenever it acquires a lock, it will eventually release it - every process eventually gets a chance to execute Counterexamples: infinite executions

4 Liveness of sequential programs Fully-automatic tools for proving liveness Liveness of integer sequential programs: TERMINATOR Liveness of heap-manipulating programs by reduction to integer ones: Magill+. Automatic Numeric Abstractions for Heap-Manipulating Programs. POPL 10

5 Liveness of concurrent programs Open research area This lecture: automatically proving liveness properties of non-blocking algorithms Joint work with Byron Cook, Matthew Parkinson and Viktor Vafeiadis Assume we can check liveness properties of sequential C programs

6 Circular reasoning about safety Thread-modular reasoning is circular: R 1,G 1 {P 1 C 1 {Q 1 R 2,G 2 {P 2 C 2 {Q 2 R 1 R 2,G 1 G 2 {P 1 P 2 C 1 C 2 {Q 1 Q 2 assumes C1 satisfies G1 C2 satisfies G2 assumes Sound because G1 and G2 define safety properties

7 Circular reasoning about liveness Circular reasoning about liveness is unsound: x = y = 1; while (x) ; y = 0; while (y) ; x = 0; assumes If the other thread resets x, I ll eventually reset y If the other thread resets y, I ll eventually reset x assumes Both are true, but the program doesn t terminate

8 Treiber s stack struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val;

9 Treiber s stack struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Do push and pop always terminate?

10 Treiber s stack struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val;

11 struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; Treiber s stack void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; push or pop may not terminate if other threads continuously modify Top

12 struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; Treiber s stack void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; push or pop may not terminate if other threads continuously modify Top However: some operation will always terminate

13 struct Node { Node *next; data_t val; *Top; CAS(x, v1, v2) { if (*x == v1) { *x = v2; return true; else return false; Treiber s stack void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; push or pop may not terminate if other threads continuously modify Top However: some operation will always terminate Lock-freedom

14 Lock-freedom Most general client C(m): For any m in any execution of C(m) under any scheduler some operation returns infinitely often Any scheduler: can suspend a thread and never resume it again (but assume it always schedules someone) Also: wait-freedom, obstruction-freedom

15 From lock-freedom to termination Lock-freedom: for any m in any execution of C(m) some operation returns infinitely often True iff for any l the program C (l) terminates

16 From lock-freedom to termination

17 From lock-freedom to termination Non-terminating execution of C (l) execution of C(l) violating lock-freedom

18 From lock-freedom to termination Non-terminating execution of C (l) execution of C(l) violating lock-freedom Same operations as in C (l); threads get preempted forever after one successful iteration

19 From lock-freedom to termination

20 From lock-freedom to termination

21 From lock-freedom to termination

22 From lock-freedom to termination Execution of C(m) violating lock-freedom has only k operations non-terminating execution of C (k)

23 From lock-freedom to termination Execution of C(m) violating lock-freedom has only k operations non-terminating execution of C (k) Same operations as in C (l) with the same scheduling decisions

24 From lock-freedom to termination

25 From lock-freedom to termination

26 RGSep proof struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val;

27 RGSep proof struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Shared state

28 RGSep proof struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Shared state Top 42 4 NULL

29 RGSep proof struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id Shared state Top 42 4 NULL

30 RGSep proof struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id

31 Lock-freedom of Treiber s stack struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id

32 Lock-freedom of Treiber s stack struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id The do loops terminate if no-one else executes Push or Pop infinitely often

33 Lock-freedom of Treiber s stack struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id The do loops terminate if no-one else executes Push or Pop infinitely often No-one executes Push or Pop infinitely often

34 Lock-freedom of Treiber s stack struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id The do loops terminate if no-one else executes Push or Pop infinitely often No-one executes Push or Pop infinitely often Hence, push and pop terminate

35 Lock-freedom of Treiber s stack struct Node { Node *next; data_t val; *Top; void push(data_t v) { Node *t, *x; x = new Node; x->val = v; do { t = Top; x->next = t; while(!cas(&top,t,x)); Push or Id data_t pop() { Node *t, *x; do { t = Top; if (t == NULL) return EMPTY; x = t->next; while(!cas(&top,t,x)); return t->val; Pop or Id The do loops terminate if no-one else executes Push or Pop infinitely often No-one executes Push or Pop infinitely often Hence, push and pop terminate liveness assumption

36 Layered proof I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I terminate I terminate

37 Layered proof Thread-modular query: thread simple environment model can be checked by sequential tools I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I terminate I terminate

38 Layered proof I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I terminate I terminate

39 Layered proof I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often What about n threads? I terminate I terminate

40 Layered proof I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often What about n threads? I terminate I terminate Is such a proof always valid for n threads?

41 Layered proof I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often What about n threads? I terminate I terminate Is such a proof always valid for n threads? Yes: finitely many + finitely many = finitely many!

42 Spinlocks using CAS Lock l: 0 or 1 lock(l) { while (!CAS(l, 0, 1)) ; unlock(l){ l=0; Is it lock-free?

43 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; Contending push and pop can eliminate each other without modifying the stack pop just returns the value that push is trying to insert Operations collide by writing to a random slot in the col array

44 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; Others or Id Contending push and pop can eliminate each other without modifying the stack pop just returns the value that push is trying to insert Operations collide by writing to a random slot in the col array

45 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Others or Id Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos];

46 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Others or Id Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; No-one executes Push or Pop infinitely often

47 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Others or Id Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; No-one executes Push or Pop infinitely often push and pop terminate if no-one else executes Push, Pop, or Xchg infinitely often

48 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Others or Id Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; No-one executes Push or Pop infinitely often push and pop terminate if no-one else executes Push, Pop, or Xchg infinitely often push and pop don t execute Xchg infinitely often if noone else executes Push or Pop infinitely often

49 HSY stack (Hendler-Shavit-Yerushalmi) void push(data_t v) { Node *t, *x; x = new Node; x->val = v; while(true) { t = Top; x->next = t; if(cas(&top,t,x)) return; hisid = col[pos]; Others or Id Push or Id Xchg or Id while(!cas(&col[pos],hisid,myid)) hisid = col[pos]; No-one executes Push or Pop infinitely often push and pop terminate if no-one else executes Push, Pop, or Xchg infinitely often push and pop don t execute Xchg infinitely often if noone else executes Push or Pop infinitely often Hence, push and pop terminate

50 Layered proof I execute only Push, Pop, Xchg, Others or Id I execute only Push, Pop, Xchg, Others or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I don t execute Push, Pop or Xchg infinitely often I don t execute Push, Pop or Xchg infinitely often I terminate I terminate

51 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

52 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

53 RGSep judgements R, G {P C {Q If the initial state satisfies P and the environment satisfies R, then C is safe, satisfies G, and the final state, when C terminates, satisfies Q P, Q assertions interpreted over LocalStates SharedStates R, G relations in P(SharedStates SharedStates)

54 Judgements for liveness proofs R, G {P C {Q If the initial state satisfies P and the environment satisfies R, then C is safe, satisfies G, and the final state, when C terminates, satisfies Q P, Q assertions interpreted over LocalStates SharedStates R, G languages of finite and infinite words over the alphabet P(SharedStates SharedStates)

55 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next Semantics over infinite words: δ 1 δ 2... = A δ 1 A δ 1 δ 2 δ 3... δ 1 δ 2... = Ψ i. δ i δ i+1... = Ψ δ 1 δ 2 δ 3... δ 1 δ 2... = Ψ i. δ i δ i+1... = Ψ δ 1 δ 2 δ 3... δ i δ 1 δ 2... = Ψ δ 2 δ 3... = Ψ δ 1 δ 2 δ 3...

56 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next Semantics over finite words: δ 1...δ m = A δ 1 A δ 1 δ 2 δ 3... δ m δ 1...δ m = Ψ i. 1 i m δ i...δ m = Ψ δ 1 δ 2 δ 3... δ m δ 1...δ m = Ψ i. 1 i m δ i...δ m = Ψ δ 1 δ 2 δ 3... δ i δ m δ 1...δ m = Ψ m 2 δ 2...δ m = Ψ δ 1 δ 2 δ 3... δ m

57 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next

58 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A

59 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A

60 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A

61 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A finitely often A

62 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A finitely often A (A 1 A 2 )

63 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A finitely often A (A 1 A 2 ) A1 is always followed by A2

64 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A finitely often A (A 1 A 2 ) A1 is always followed by A2 False

65 Linear temporal logic (LTL) Ψ ::= RGSepActions Ψ Ψ Ψ Ψ Ψ Ψ always eventually next A finitely often A A finitely often A (A 1 A 2 ) A1 is always followed by A2 False termination

66 Property specification RGSep triple R, G {P C {Q: R, G {P C {Q push doesn t execute Push or Pop infinitely often : push terminates if no-one else executes Push or Pop infinitely often :

67 Keeping track of guarantees I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I terminate I terminate

68 Extra judgement form R, (G 1, G 2 ) {P C 1 C 2 {Q If the initial state satisfies P and the environment satisfies R, then C 1 C 2 is safe, C 1 satisfies G 1, C 2 satisfies G 2, and the final state, when C 1 C 2 terminates, satisfies Q P, Q assertions interpreted over LocalStates SharedStates R, G 1, G 2 languages of finite and infinite words over the alphabet P(SharedStates SharedStates)

69 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

70 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

71 Discharging thread-local assumptions Automata-theoretic framework [Vardi 1991] Fair termination of SmallfootRG [Calcagno , Vafeiadis 2010] Abstract transition system [Magill , 2010] Equiterminating integer program Terminator with fairness [Cook ] Yes/No

72 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

73 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

74 Proof rule G 1 G 2 G 1 G 2

75 Proof rule G 1 G 2 G 1 G 2 R G 2,G 1 {P 1 C 1 {Q 1 R G 1,G 2 {P 2 C 2 {Q 2 R, G 1 G 2 {P 1 P 2 C 1 C 2 {Q 1 Q 2

76 Layered proof I execute only Push, Pop, Xchg, Others or Id I execute only Push, Pop, Xchg, Others or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I don t execute Push, Pop or Xchg infinitely often I don t execute Push, Pop or Xchg infinitely often I terminate I terminate

77 Proof system push and pop don t execute Push, Pop or Xchg infinitely often if no-one else executes Push or Pop infinitely often

78 Proof system push and pop don t execute Push, Pop or Xchg infinitely often if no-one else executes Push or Pop infinitely often

79 Proof system push and pop don t execute Push, Pop or Xchg infinitely often if no-one else executes Push or Pop infinitely often

80 Proof system push and pop don t execute Push, Pop or Xchg infinitely often if no-one else executes Push or Pop infinitely often

81 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

82 Wish list Formal system for thread-local judgements Tool for discharging the judgements Proof rules for combining the judgements Strategy for proof search

83 Proof search strategy Relies/guarantees of the form are usually sufficient Only a few actions per algorithm

84 Proof search strategy Run the safety checker:

85 Proof search strategy Run the safety checker: ü ü û û Try to use this guarantee to prove actions can t be executed infinitely often

86 Proof search strategy Run the safety checker: ü ü û û

87 Proof search strategy Run the safety checker: ü ü û û ü ü ü û Try to use the guarantee (Push Pop) to prove actions can t be executed infinitely often

88 Proof search strategy Run the safety checker: ü ü û û ü ü ü û

89 Proof search strategy Run the safety checker: ü ü û û ü ü ü û ü ü ü ü Try to use the guarantee (Push Pop Xchg) to prove actions can t be executed infinitely often

90 Proof search strategy Run the safety checker: ü ü û û ü ü ü û ü ü ü ü

91 Proof search strategy Run the safety checker: Proof valid for an arbitrary number of threads ü ü û û ü ü ü û ü ü ü ü

92 Case studies Treiber's stack [Treiber 1986] HSY stack [Hendler+ 2004] Non-blocking queue [Michael, Scott 1996] Non-blocking linked list [Michael 2002] RDCSS [Harris+ 2002]

93 Conclusion: research paradigm Pick a class of programs Design an appropriate logic Observe that proofs are simple and follow the same pattern Infer proofs automatically Proofs produce insights into algorithm architecture: if no-one can screw you up infinitely often, then you re lockfree

94 Conclusion: technique Circular reasoning about liveness is unsound Yet modular reasoning about liveness is possible by repeatedly strengthening thread guarantees: I execute only Push, Pop or Id I execute only Push, Pop or Id I don t execute Push or Pop infinitely often I don t execute Push or Pop infinitely often I terminate I terminate

95 References Gotsman, Cook, Parkinson, Vafeiadis. Proving that non-blocking algorithms don t block. POPL 09

Proving linearizability & lock-freedom

Proving linearizability & lock-freedom Proving linearizability & lock-freedom Viktor Vafeiadis MPI-SWS Michael & Scott non-blocking queue head tail X 1 3 2 null CAS compare & swap CAS (address, expectedvalue, newvalue) { atomic { if ( *address

More information

Non-blocking Array-based Algorithms for Stacks and Queues!

Non-blocking Array-based Algorithms for Stacks and Queues! Non-blocking Array-based Algorithms for Stacks and Queues! Niloufar Shafiei! Department of Computer Science and Engineering York University ICDCN 09 Outline! Introduction! Stack algorithm! Queue algorithm!

More information

Automata-Theoretic LTL Model Checking. Emptiness of Büchi Automata

Automata-Theoretic LTL Model Checking. Emptiness of Büchi Automata Automata-Theoretic LTL Model Checking Graph Algorithms for Software Model Checking (based on Arie Gurfinkel s csc2108 project) Automata-Theoretic LTL Model Checking p.1 Emptiness of Büchi Automata An automation

More information

Model checking pushdown systems

Model checking pushdown systems Model checking pushdown systems R. Ramanujam Institute of Mathematical Sciences, Chennai jam@imsc.res.in Update Meeting, IIT-Guwahati, 4 July 2006 p. 1 Sources of unboundedness Data manipulation: integers,

More information

Non-blocking Array-based Algorithms for Stacks and Queues. Niloufar Shafiei

Non-blocking Array-based Algorithms for Stacks and Queues. Niloufar Shafiei Non-blocking Array-based Algorithms for Stacks and Queues Niloufar Shafiei Outline Introduction Concurrent stacks and queues Contributions New algorithms New algorithms using bounded counter values Correctness

More information

Proving Lock-Freedom Easily and Automatically

Proving Lock-Freedom Easily and Automatically Proving Lock-Freedom Easily and Automatically Xiao Jia Wei Li Shanghai Jiao Tong University Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS) Abstract Lock-freedom is a liveness property

More information

Design of Concurrent and Distributed Data Structures

Design of Concurrent and Distributed Data Structures METIS Spring School, Agadir, Morocco, May 2015 Design of Concurrent and Distributed Data Structures Christoph Kirsch University of Salzburg Joint work with M. Dodds, A. Haas, T.A. Henzinger, A. Holzer,

More information

AST: scalable synchronization Supervisors guide 2002

AST: scalable synchronization Supervisors guide 2002 AST: scalable synchronization Supervisors guide 00 tim.harris@cl.cam.ac.uk These are some notes about the topics that I intended the questions to draw on. Do let me know if you find the questions unclear

More information

G52CON: Concepts of Concurrency

G52CON: Concepts of Concurrency G52CON: Concepts of Concurrency Lecture 11: Semaphores I" Brian Logan School of Computer Science bsl@cs.nott.ac.uk Outline of this lecture" problems with Peterson s algorithm semaphores implementing semaphores

More information

Lecture 10: Avoiding Locks

Lecture 10: Avoiding Locks Lecture 10: Avoiding Locks CSC 469H1F Fall 2006 Angela Demke Brown (with thanks to Paul McKenney) Locking: A necessary evil? Locks are an easy to understand solution to critical section problem Protect

More information

System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements

System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements System Correctness EEC 421/521: Software Engineering A Whirlwind Intro to Software Model Checking A system is correct when it meets its requirements a design without requirements cannot be right or wrong,

More information

Abstract Interpretation Using Laziness: Proving Conway s Lost Cosmological Theorem

Abstract Interpretation Using Laziness: Proving Conway s Lost Cosmological Theorem Abstract Interpretation Using Laziness: Proving Conway s Lost Cosmological Theorem Kevin Watkins CMU CSD POP Seminar December 8, 2006 In partial fulfillment of the speaking skills requirement ? 2111 1231

More information

Linearizability with ownership transfer

Linearizability with ownership transfer Linearizability with ownership transfer Hongseok Yang University of Oxford Joint work with Alexey Gotsman (IMDEA Software Institute, Spain) Concurrent libraries Encapsulate efficient concurrent algorithms.

More information

A Gentle Introduction to Program Analysis

A Gentle Introduction to Program Analysis A Gentle Introduction to Program Analysis Işıl Dillig University of Texas, Austin January 21, 2014 Programming Languages Mentoring Workshop 1 / 24 What is Program Analysis? Very broad topic, but generally

More information

4/6/2011. Model Checking. Encoding test specifications. Model Checking. Encoding test specifications. Model Checking CS 4271

4/6/2011. Model Checking. Encoding test specifications. Model Checking. Encoding test specifications. Model Checking CS 4271 Mel Checking LTL Property System Mel Mel Checking CS 4271 Mel Checking OR Abhik Roychoudhury http://www.comp.nus.edu.sg/~abhik Yes No, with Counter-example trace 2 Recap: Mel Checking for mel-based testing

More information

Hoare logic. A proof system for separation logic. Introduction. Separation logic

Hoare logic. A proof system for separation logic. Introduction. Separation logic Introduction Hoare logic Lecture 6: Examples in separation logic In the previous lecture, we saw how reasoning about pointers in Hoare logic was problematic, which motivated introducing separation logic.

More information

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 19 Tuesday, April 3, 2018 1 Introduction to axiomatic semantics The idea in axiomatic semantics is to give specifications

More information

SFU CMPT Lecture: Week 8

SFU CMPT Lecture: Week 8 SFU CMPT-307 2008-2 1 Lecture: Week 8 SFU CMPT-307 2008-2 Lecture: Week 8 Ján Maňuch E-mail: jmanuch@sfu.ca Lecture on June 24, 2008, 5.30pm-8.20pm SFU CMPT-307 2008-2 2 Lecture: Week 8 Universal hashing

More information

Advanced Programming Methods. Introduction in program analysis

Advanced Programming Methods. Introduction in program analysis Advanced Programming Methods Introduction in program analysis What is Program Analysis? Very broad topic, but generally speaking, automated analysis of program behavior Program analysis is about developing

More information

Declarative semantics for concurrency. 28 August 2017

Declarative semantics for concurrency. 28 August 2017 Declarative semantics for concurrency Ori Lahav Viktor Vafeiadis 28 August 2017 An alternative way of defining the semantics 2 Declarative/axiomatic concurrency semantics Define the notion of a program

More information

A Scalable Lock-free Stack Algorithm

A Scalable Lock-free Stack Algorithm A Scalable Lock-free Stack Algorithm Danny Hendler Ben-Gurion University Nir Shavit Tel-Aviv University Lena Yerushalmi Tel-Aviv University The literature describes two high performance concurrent stack

More information

Concurrent library abstraction without information hiding

Concurrent library abstraction without information hiding Universidad Politécnica de Madrid Escuela técnica superior de ingenieros informáticos Concurrent library abstraction without information hiding Artem Khyzha Advised by Manuel Carro and Alexey Gotsman Madrid

More information

[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION

[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION v1.0 20130407 Programmazione Avanzata e Paradigmi Ingegneria e Scienze Informatiche - UNIBO a.a 2013/2014 Lecturer: Alessandro Ricci [module 2.2] MODELING CONCURRENT PROGRAM EXECUTION 1 SUMMARY Making

More information

Interprocess Communication By: Kaushik Vaghani

Interprocess Communication By: Kaushik Vaghani Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the

More information

Models of concurrency & synchronization algorithms

Models of concurrency & synchronization algorithms Models of concurrency & synchronization algorithms Lecture 3 of TDA383/DIT390 (Concurrent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2016/2017 Today s menu

More information

NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 17 November 2017

NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 17 November 2017 NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY Tim Harris, 17 November 2017 Lecture 7 Linearizability Lock-free progress properties Hashtables and skip-lists Queues Reducing contention Explicit

More information

Threads and Parallelism in Java

Threads and Parallelism in Java Threads and Parallelism in Java Java is one of the few main stream programming languages to explicitly provide for user-programmed parallelism in the form of threads. A Java programmer may organize a program

More information

NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 31 October 2012

NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 31 October 2012 NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY Tim Harris, 31 October 2012 Lecture 6 Linearizability Lock-free progress properties Queues Reducing contention Explicit memory management Linearizability

More information

Synthesis for Concurrency

Synthesis for Concurrency Synthesis for Concurrency Martin Vechev ETH Zurich (joint work with Eran Yahav, Greta Yorsh) 1 Concurrency is Everywhere Unreliable Concurrency is Everywhere 2003 Northeast Blackout concurrency error triggers

More information

Precision and the Conjunction Rule in Concurrent Separation Logic

Precision and the Conjunction Rule in Concurrent Separation Logic Precision and the Conjunction Rule in Concurrent Separation Logic Alexey Gotsman a Josh Berdine b Byron Cook b,c a IMDEA Software Institute b Microsoft Research c Queen Mary University of London Abstract

More information

Lecture 9: Multiprocessor OSs & Synchronization. CSC 469H1F Fall 2006 Angela Demke Brown

Lecture 9: Multiprocessor OSs & Synchronization. CSC 469H1F Fall 2006 Angela Demke Brown Lecture 9: Multiprocessor OSs & Synchronization CSC 469H1F Fall 2006 Angela Demke Brown The Problem Coordinated management of shared resources Resources may be accessed by multiple threads Need to control

More information

Indistinguishability: Friend and Foe of Concurrent Data Structures. Hagit Attiya CS, Technion

Indistinguishability: Friend and Foe of Concurrent Data Structures. Hagit Attiya CS, Technion Indistinguishability: Friend and Foe of Concurrent Data Structures Hagit Attiya CS, Technion Uncertainty is a main obstacle for designing correct applications in concurrent systems Formally captured by

More information

Formal Methods for Software Development

Formal Methods for Software Development Formal Methods for Software Development Model Checking with Temporal Logic Wolfgang Ahrendt 21st September 2018 FMSD: Model Checking with Temporal Logic /GU 180921 1 / 37 Model Checking Check whether a

More information

Typed Assembly Language for Implementing OS Kernels in SMP/Multi-Core Environments with Interrupts

Typed Assembly Language for Implementing OS Kernels in SMP/Multi-Core Environments with Interrupts Typed Assembly Language for Implementing OS Kernels in SMP/Multi-Core Environments with Interrupts Toshiyuki Maeda and Akinori Yonezawa University of Tokyo Quiz [Environment] CPU: Intel Xeon X5570 (2.93GHz)

More information

Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL

Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL 251 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor

More information

Lecture 10 Notes Linked Lists

Lecture 10 Notes Linked Lists Lecture 10 Notes Linked Lists 15-122: Principles of Imperative Computation (Summer 1 2015) Frank Pfenning, Rob Simmons, André Platzer 1 Introduction In this lecture we discuss the use of linked lists to

More information

CONCURRENT LIBRARIES. Correctness Criteria, Verification

CONCURRENT LIBRARIES. Correctness Criteria, Verification CONCURRENT LIBRARIES Correctness Criteria, Verification Verification Ingredients Specifying a Library: φ Implementing a Library: L Verifying a Library implementation: L φ The History of an Object Object

More information

Reasoning About Imperative Programs. COS 441 Slides 10

Reasoning About Imperative Programs. COS 441 Slides 10 Reasoning About Imperative Programs COS 441 Slides 10 The last few weeks Agenda reasoning about functional programming It s very simple and very uniform: substitution of equal expressions for equal expressions

More information

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1 Programming Languages and Compilers Qualifying Examination Monday, September 19, 2016 Answer 4 of 6 questions.1 GENERAL INSTRUCTIONS 1. Answer each question in a separate book. 2. Indicate on the cover

More information

Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs 3.

Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs 3. Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs 3. LOCK FREE KERNEL 309 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor

More information

Model Checking Transactional Memories

Model Checking Transactional Memories Model Checking Transactional Memories Abstract Rachid Guerraoui Thomas A. Henzinger Barbara Jobstmann Vasu Singh Model checking software transactional memories (STMs) is difficult because of the unbounded

More information

Software Model Checking with Abstraction Refinement

Software Model Checking with Abstraction Refinement Software Model Checking with Abstraction Refinement Computer Science and Artificial Intelligence Laboratory MIT Armando Solar-Lezama With slides from Thomas Henzinger, Ranjit Jhala and Rupak Majumdar.

More information

Certification of Termination for Integer Transition Systems

Certification of Termination for Integer Transition Systems Certification of Termination for Integer Transition Systems Marc Brockschmidt, Sebastiaan Joosten, René Thiemann and Akihisa Yamada Sebastiaan.Joosten@uibk.ac.at Supported by FWF project Y 757 Reliable

More information

Multiple Inheritance. Computer object can be viewed as

Multiple Inheritance. Computer object can be viewed as Multiple Inheritance We have seen that a class may be derived from a given parent class. It is sometimes useful to allow a class to be derived from more than one parent, inheriting members of all parents.

More information

Lecture 10 Notes Linked Lists

Lecture 10 Notes Linked Lists Lecture 10 Notes Linked Lists 15-122: Principles of Imperative Computation (Spring 2016) Frank Pfenning, Rob Simmons, André Platzer 1 Introduction In this lecture we discuss the use of linked lists to

More information

Monitoring Interfaces for Faults

Monitoring Interfaces for Faults Monitoring Interfaces for Faults Aleksandr Zaks RV 05 - Fifth Workshop on Runtime Verification Joint work with: Amir Pnueli, Lenore Zuck Motivation Motivation Consider two components interacting with each

More information

Deadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018

Deadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018 Deadlock and Monitors CS439: Principles of Computer Systems September 24, 2018 Bringing It All Together Processes Abstraction for protection Define address space Threads Share (and communicate) through

More information

Hoare triples. Floyd-Hoare Logic, Separation Logic

Hoare triples. Floyd-Hoare Logic, Separation Logic Hoare triples Floyd-Hoare Logic, Separation Logic 1. Floyd-Hoare Logic 1969 Reasoning about control Hoare triples {A} p {B} a Hoare triple partial correctness: if the initial state satisfies assertion

More information

G52CON: Concepts of Concurrency

G52CON: Concepts of Concurrency G52CON: Concepts of Concurrency Lecture 6: Algorithms for Mutual Natasha Alechina School of Computer Science nza@cs.nott.ac.uk Outline of this lecture mutual exclusion with standard instructions example:

More information

Overview. Probabilistic Programming. Dijkstra s guarded command language: Syntax. Elementary pgcl ingredients. Lecture #4: Probabilistic GCL

Overview. Probabilistic Programming. Dijkstra s guarded command language: Syntax. Elementary pgcl ingredients. Lecture #4: Probabilistic GCL Overview Lecture #4: Probabilistic GCL 1 Joost-Pieter Katoen 2 3 Recursion RWTH Lecture Series on 2018 Joost-Pieter Katoen 1/31 Joost-Pieter Katoen 2/31 Dijkstra s guarded command language: Syntax Elementary

More information

CS5460/6460: Operating Systems. Lecture 11: Locking. Anton Burtsev February, 2014

CS5460/6460: Operating Systems. Lecture 11: Locking. Anton Burtsev February, 2014 CS5460/6460: Operating Systems Lecture 11: Locking Anton Burtsev February, 2014 Race conditions Disk driver maintains a list of outstanding requests Each process can add requests to the list 1 struct list

More information

The SPIN Model Checker

The SPIN Model Checker The SPIN Model Checker Metodi di Verifica del Software Andrea Corradini Lezione 1 2013 Slides liberamente adattate da Logic Model Checking, per gentile concessione di Gerard J. Holzmann http://spinroot.com/spin/doc/course/

More information

Lindsay Groves, Simon Doherty. Mark Moir, Victor Luchangco

Lindsay Groves, Simon Doherty. Mark Moir, Victor Luchangco Lindsay Groves, Simon Doherty Victoria University of Wellington Mark Moir, Victor Luchangco Sun Microsystems, Boston (FORTE, Madrid, September, 2004) Lock-based concurrency doesn t scale Lock-free/non-blocking

More information

Finite State Verification. CSCE Lecture 21-03/28/2017

Finite State Verification. CSCE Lecture 21-03/28/2017 Finite State Verification CSCE 747 - Lecture 21-03/28/2017 So, You Want to Perform Verification... You have a property that you want your program to obey. Great! Let s write some tests! Does testing guarantee

More information

Midterm Exam Amy Murphy 19 March 2003

Midterm Exam Amy Murphy 19 March 2003 University of Rochester Midterm Exam Amy Murphy 19 March 2003 Computer Systems (CSC2/456) Read before beginning: Please write clearly. Illegible answers cannot be graded. Be sure to identify all of your

More information

Model Checking with Automata An Overview

Model Checking with Automata An Overview Model Checking with Automata An Overview Vanessa D Carson Control and Dynamical Systems, Caltech Doyle Group Presentation, 05/02/2008 VC 1 Contents Motivation Overview Software Verification Techniques

More information

Thread Safety. Review. Today o Confinement o Threadsafe datatypes Required reading. Concurrency Wrapper Collections

Thread Safety. Review. Today o Confinement o Threadsafe datatypes Required reading. Concurrency Wrapper Collections Thread Safety Today o Confinement o Threadsafe datatypes Required reading Concurrency Wrapper Collections Optional reading The material in this lecture and the next lecture is inspired by an excellent

More information

Linked Lists: The Role of Locking. Erez Petrank Technion

Linked Lists: The Role of Locking. Erez Petrank Technion Linked Lists: The Role of Locking Erez Petrank Technion Why Data Structures? Concurrent Data Structures are building blocks Used as libraries Construction principles apply broadly This Lecture Designing

More information

Mutual Exclusion: Classical Algorithms for Locks

Mutual Exclusion: Classical Algorithms for Locks Mutual Exclusion: Classical Algorithms for Locks John Mellor-Crummey Department of Computer Science Rice University johnmc@cs.rice.edu COMP 422 Lecture 18 21 March 2006 Motivation Ensure that a block of

More information

Lecture 7: Mutual Exclusion 2/16/12. slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit

Lecture 7: Mutual Exclusion 2/16/12. slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit Principles of Concurrency and Parallelism Lecture 7: Mutual Exclusion 2/16/12 slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit Time Absolute, true and mathematical time, of

More information

TAFL 1 (ECS-403) Unit- V. 5.1 Turing Machine. 5.2 TM as computer of Integer Function

TAFL 1 (ECS-403) Unit- V. 5.1 Turing Machine. 5.2 TM as computer of Integer Function TAFL 1 (ECS-403) Unit- V 5.1 Turing Machine 5.2 TM as computer of Integer Function 5.2.1 Simulating Turing Machine by Computer 5.2.2 Simulating Computer by Turing Machine 5.3 Universal Turing Machine 5.4

More information

Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion

Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion CS236368 Formal Specifications Lecture-- TLA 1 Basic Idea Combine transitions with temporal logic

More information

CS 267: Automated Verification. Lecture 13: Bounded Model Checking. Instructor: Tevfik Bultan

CS 267: Automated Verification. Lecture 13: Bounded Model Checking. Instructor: Tevfik Bultan CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan Remember Symbolic Model Checking Represent sets of states and the transition relation as Boolean logic formulas

More information

Hoare Logic and Model Checking

Hoare Logic and Model Checking Hoare Logic and Model Checking Kasper Svendsen University of Cambridge CST Part II 2016/17 Acknowledgement: slides heavily based on previous versions by Mike Gordon and Alan Mycroft Introduction In the

More information

Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs

Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs Christian J. Bell, Mohsen Lesani, Adam Chlipala, Stephan Boyer, Gregory Malecha, Peng Wang MIT CSAIL Goal: verification

More information

Lock Oscillation: Boosting the Performance of Concurrent Data Structures

Lock Oscillation: Boosting the Performance of Concurrent Data Structures Lock Oscillation: Boosting the Performance of Concurrent Data Structures Panagiota Fatourou FORTH ICS & University of Crete Nikolaos D. Kallimanis FORTH ICS The Multicore Era The dominance of Multicore

More information

Plan of the lecture. Quick-Sort. Partition of lists (or using extra workspace) Quick-Sort ( 10.2) Quick-Sort Tree. Partitioning arrays

Plan of the lecture. Quick-Sort. Partition of lists (or using extra workspace) Quick-Sort ( 10.2) Quick-Sort Tree. Partitioning arrays Plan of the lecture Quick-sort Lower bounds on comparison sorting Correctness of programs (loop invariants) Quick-Sort 7 4 9 6 2 2 4 6 7 9 4 2 2 4 7 9 7 9 2 2 9 9 Lecture 16 1 Lecture 16 2 Quick-Sort (

More information

Synchronization 1. Synchronization

Synchronization 1. Synchronization Synchronization 1 Synchronization key concepts critical sections, mutual exclusion, test-and-set, spinlocks, blocking and blocking locks, semaphores, condition variables, deadlocks reading Three Easy Pieces:

More information

Concurrency: Signaling and Condition Variables

Concurrency: Signaling and Condition Variables Concurrency: Signaling and Condition Variables Questions Answered in this Lecture: How do we make fair locks perform better? How do we notify threads of that some condition has been met? Hale CS450 Thanks

More information

Hoare Logic and Model Checking. A proof system for Separation logic. Introduction. Separation Logic

Hoare Logic and Model Checking. A proof system for Separation logic. Introduction. Separation Logic Introduction Hoare Logic and Model Checking In the previous lecture we saw the informal concepts that Separation Logic is based on. Kasper Svendsen University of Cambridge CST Part II 2016/17 This lecture

More information

Compilation and Program Analysis (#11) : Hoare triples and shape analysis

Compilation and Program Analysis (#11) : Hoare triples and shape analysis Compilation and Program Analysis (#11) : Hoare triples and shape analysis Laure Gonnord http://laure.gonnord.org/pro/teaching/capm1.html Laure.Gonnord@ens-lyon.fr Master 1, ENS de Lyon dec 2017 Inspiration

More information

Introduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL

Introduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL Introduction to Linear-Time Temporal Logic CSE 814 Introduction to LTL 1 Outline Motivation for TL in general Types of properties to be expressed in TL Structures on which LTL formulas are evaluated Syntax

More information

Type Soundness and Race Freedom for Mezzo

Type Soundness and Race Freedom for Mezzo Type Soundness and Race Freedom for Mezzo Thibaut Balabonski François Pottier Jonathan Protzenko INRIA FLOPS 2014 1 / 42 Mezzo in a few words Mezzo is a high-level programming language, equipped with:

More information

Shared Objects. Shared Objects

Shared Objects. Shared Objects Shared Objects Shared Objects Invoked operations have a non-zero duration Invocations can overlap Useful for: modeling distributed shared memory Objects can be combined together to implement higher level

More information

CS370 Operating Systems

CS370 Operating Systems CS370 Operating Systems Colorado State University Yashwant K Malaiya Spring 1018 L11 Synchronization Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ Multilevel feedback queue:

More information

Programming Languages

Programming Languages TECHNISCHE UNIVERSITÄT MÜNCHEN FAKULTÄT FÜR INFORMATIK Programming Languages Concurrency: Atomic Executions, Locks and Monitors Dr. Michael Petter Winter term 2016 Atomic Executions, Locks and Monitors

More information

A Program Logic for Concurrent Objects under Fair Scheduling

A Program Logic for Concurrent Objects under Fair Scheduling A Program Logic for Concurrent Objects under Fair Scheduling Hongjin Liang Xinyu Feng School of Computer Science and Technology & Suzhou Institute for Advanced Study University of Science and Technology

More information

Deadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018

Deadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018 Deadlock and Monitors CS439: Principles of Computer Systems February 7, 2018 Last Time Terminology Safety and liveness Atomic Instructions, Synchronization, Mutual Exclusion, Critical Sections Synchronization

More information

Formal Verification: Practical Exercise Model Checking with NuSMV

Formal Verification: Practical Exercise Model Checking with NuSMV Formal Verification: Practical Exercise Model Checking with NuSMV Jacques Fleuriot Daniel Raggi Semester 2, 2017 This is the first non-assessed practical exercise for the Formal Verification course. You

More information

Verification of Work-stealing Deque Implementation

Verification of Work-stealing Deque Implementation IT 12 008 Examensarbete 30 hp Mars 2012 Verification of Work-stealing Deque Implementation Majid Khorsandi Aghai Institutionen för informationsteknologi Department of Information Technology Abstract Verification

More information

SYNCHRONIZATION M O D E R N O P E R A T I N G S Y S T E M S R E A D 2. 3 E X C E P T A N D S P R I N G 2018

SYNCHRONIZATION M O D E R N O P E R A T I N G S Y S T E M S R E A D 2. 3 E X C E P T A N D S P R I N G 2018 SYNCHRONIZATION M O D E R N O P E R A T I N G S Y S T E M S R E A D 2. 3 E X C E P T 2. 3. 8 A N D 2. 3. 1 0 S P R I N G 2018 INTER-PROCESS COMMUNICATION 1. How a process pass information to another process

More information

Modular Verification of Preemptive OS Kernels

Modular Verification of Preemptive OS Kernels Under consideration for publication in J. Functional Programming 1 Modular Verification of Preemptive OS Kernels ALEXEY GOTSMAN IMDEA Software Institute HONGSEOK YANG University of Oxford Abstract Most

More information

Overview of Lecture 4. Memory Models, Atomicity & Performance. Ben-Ari Concurrency Model. Dekker s Algorithm 4

Overview of Lecture 4. Memory Models, Atomicity & Performance. Ben-Ari Concurrency Model. Dekker s Algorithm 4 Concurrent and Distributed Programming http://fmt.cs.utwente.nl/courses/cdp/ Overview of Lecture 4 2 Memory Models, tomicity & Performance HC 4 - Tuesday, 6 December 2011 http://fmt.cs.utwente.nl/~marieke/

More information

Towards a Logical Reconstruction of Relational Database Theory

Towards a Logical Reconstruction of Relational Database Theory Towards a Logical Reconstruction of Relational Database Theory On Conceptual Modelling, Lecture Notes in Computer Science. 1984 Raymond Reiter Summary by C. Rey November 27, 2008-1 / 63 Foreword DB: 2

More information

Locking: A necessary evil? Lecture 10: Avoiding Locks. Priority Inversion. Deadlock

Locking: A necessary evil? Lecture 10: Avoiding Locks. Priority Inversion. Deadlock Locking: necessary evil? Lecture 10: voiding Locks CSC 469H1F Fall 2006 ngela Demke Brown (with thanks to Paul McKenney) Locks are an easy to understand solution to critical section problem Protect shared

More information

Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs

Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs Phantom Monitors: A Simple Foundation for Modular Proofs of Fine-Grained Concurrent Programs Christian J Bell, Mohsen Lesani, Adam Chlipala, Stephan Boyer, Gregory Malecha, Peng Wang MIT CSAIL cj@csailmitedu

More information

Reminder from last time

Reminder from last time Concurrent systems Lecture 2: More mutual exclusion, semaphores, and producer-consumer relationships DrRobert N. M. Watson 1 Reminder from last time Definition of a concurrent system Origins of concurrency

More information

Fun facts about recursion

Fun facts about recursion Outline examples of recursion principles of recursion review: recursive linked list methods binary search more examples of recursion problem solving using recursion 1 Fun facts about recursion every loop

More information

Finite State Verification. CSCE Lecture 14-02/25/2016

Finite State Verification. CSCE Lecture 14-02/25/2016 Finite State Verification CSCE 747 - Lecture 14-02/25/2016 So, You Want to Perform Verification... You have a property that you want your program to obey. Great! Let s write some tests! Does testing guarantee

More information

CHAPTER 6: PROCESS SYNCHRONIZATION

CHAPTER 6: PROCESS SYNCHRONIZATION CHAPTER 6: PROCESS SYNCHRONIZATION The slides do not contain all the information and cannot be treated as a study material for Operating System. Please refer the text book for exams. TOPICS Background

More information

Static Program Analysis

Static Program Analysis Static Program Analysis Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ws-1617/spa/ Recap: Taking Conditional Branches into Account Extending

More information

Part II: Atomicity for Software Model Checking. Analysis of concurrent programs is difficult (1) Transaction. The theory of movers (Lipton 75)

Part II: Atomicity for Software Model Checking. Analysis of concurrent programs is difficult (1) Transaction. The theory of movers (Lipton 75) Part II: Atomicity for Software Model Checking Class Account { int balance; static int MIN = 0, MAX = 00; bool synchronized deposit(int n) { int t = balance + n; if (t > MAX) return false; bool synchronized

More information

The Java Memory Model

The Java Memory Model Jeremy Manson 1, William Pugh 1, and Sarita Adve 2 1 University of Maryland 2 University of Illinois at Urbana-Champaign Presented by John Fisher-Ogden November 22, 2005 Outline Introduction Sequential

More information

Hoare logic. WHILE p, a language with pointers. Introduction. Syntax of WHILE p. Lecture 5: Introduction to separation logic

Hoare logic. WHILE p, a language with pointers. Introduction. Syntax of WHILE p. Lecture 5: Introduction to separation logic Introduction Hoare logic Lecture 5: Introduction to separation logic In the previous lectures, we have considered a language, WHILE, where mutability only concerned program variables. Jean Pichon-Pharabod

More information

Motivation & examples Threads, shared memory, & synchronization

Motivation & examples Threads, shared memory, & synchronization 1 Motivation & examples Threads, shared memory, & synchronization How do locks work? Data races (a lower level property) How do data race detectors work? Atomicity (a higher level property) Concurrency

More information

T Reactive Systems: Kripke Structures and Automata

T Reactive Systems: Kripke Structures and Automata Tik-79.186 Reactive Systems 1 T-79.186 Reactive Systems: Kripke Structures and Automata Spring 2005, Lecture 3 January 31, 2005 Tik-79.186 Reactive Systems 2 Properties of systems invariants: the system

More information

Hoare logic. Lecture 5: Introduction to separation logic. Jean Pichon-Pharabod University of Cambridge. CST Part II 2017/18

Hoare logic. Lecture 5: Introduction to separation logic. Jean Pichon-Pharabod University of Cambridge. CST Part II 2017/18 Hoare logic Lecture 5: Introduction to separation logic Jean Pichon-Pharabod University of Cambridge CST Part II 2017/18 Introduction In the previous lectures, we have considered a language, WHILE, where

More information

Lecture Notes on Queues

Lecture Notes on Queues Lecture Notes on Queues 15-122: Principles of Imperative Computation Frank Pfenning Lecture 9 September 25, 2012 1 Introduction In this lecture we introduce queues as a data structure and linked lists

More information

Behavioural Equivalences and Abstraction Techniques. Natalia Sidorova

Behavioural Equivalences and Abstraction Techniques. Natalia Sidorova Behavioural Equivalences and Abstraction Techniques Natalia Sidorova Part 1: Behavioural Equivalences p. p. The elevator example once more How to compare this elevator model with some other? The cabin

More information

Technical Report. Automatically proving linearizability. Viktor Vafeiadis. Number 778. September Computer Laboratory

Technical Report. Automatically proving linearizability. Viktor Vafeiadis. Number 778. September Computer Laboratory Technical Report UCAM-CL-TR-778 ISSN 1476-2986 Number 778 Computer Laboratory Automatically proving linearizability Viktor Vafeiadis September 2016 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom

More information