Proving liveness. Alexey Gotsman IMDEA Software Institute
|
|
- Cecilia Gardner
- 5 years ago
- Views:
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 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 informationNon-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 informationAutomata-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 informationModel 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 informationNon-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 informationProving 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 informationDesign 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 informationAST: 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 informationG52CON: 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 informationLecture 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 informationSystem 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 informationAbstract 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 informationLinearizability 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 informationA 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 information4/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 informationHoare 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 informationHarvard 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 informationSFU 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 informationAdvanced 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 informationDeclarative 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 informationA 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 informationConcurrent 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
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 informationInterprocess 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 informationModels 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 informationNON-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 informationThreads 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 informationNON-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 informationSynthesis 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 informationPrecision 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 informationLecture 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 informationIndistinguishability: 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 informationFormal 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 informationTyped 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 informationWhatever 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 informationLecture 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 informationCONCURRENT 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 informationReasoning 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 informationProgramming 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 informationWhatever 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 informationModel 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 informationSoftware 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 informationCertification 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 informationMultiple 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 informationLecture 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 informationMonitoring 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 informationDeadlock 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 informationHoare 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 informationG52CON: 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 informationOverview. 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 informationCS5460/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 informationThe 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 informationLindsay 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 informationFinite 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 informationMidterm 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 informationModel 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 informationThread 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 informationLinked 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 informationMutual 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 informationLecture 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 informationTAFL 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 informationTemporal 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 informationCS 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 informationHoare 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 informationPhantom 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 informationLock 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 informationPlan 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 informationSynchronization 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 informationConcurrency: 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 informationHoare 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 informationCompilation 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 informationIntroduction 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 informationType 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 informationShared 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 informationCS370 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 informationProgramming 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 informationA 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 informationDeadlock 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 informationFormal 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 informationVerification 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 informationSYNCHRONIZATION 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 informationModular 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 informationOverview 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 informationTowards 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 informationLocking: 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 informationPhantom 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 informationReminder 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 informationFun 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 informationFinite 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 informationCHAPTER 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 informationStatic 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 informationPart 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 informationThe 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 informationHoare 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 informationMotivation & 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 informationT 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 informationHoare 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 informationLecture 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 informationBehavioural 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 informationTechnical 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