An introduction to RGSep. Viktor Vafeiadis

Size: px

Start display at page:

Download "An introduction to RGSep. Viktor Vafeiadis"

Kellie Holmes
7 years ago
Views:

1 An introduction to RGSep Viktor Vafeiadis

2 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

3 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

4 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

5 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

6 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

7 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

8 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

9 Example: lock-coupling list There is one lock per node; threads acquire locks in a hand over hand fashion. If a node is locked, we can insert a node just after it. If two adjacent nodes are locked, we can remove the second.

10 Operations (actions) Lock-coupling list Lock Unlock Add node Delete node

11 Part I. Basic concepts Local & shared state Actions Program & environment Program specifications Stability

12 Local & shared state The total state is logically divided into two components: Shared: accessible by all threads via synchronisation Local: accessible only by one thread, its owner Shared Local 6 Figure. State of the lock-coupling list just before inserting a new node. The node to be added is local because other threads cannot yet access it.

13 Actions (1/3) Actions describe minimal atomic changes to the shared state. Lock Unlock An action allows any part of the shared state that satisfies the LHS to be changed to a part satisfying the RHS, but the rest of the shared state must not be changed.

14 Actions (2/3) Actions can also adjust the boundary between local state and stared state. This is also known as tranfer of ownership. Add node This node becomes shared. Delete node This node becomes local.

15 Actions (3/3) Example: Lock coupling list Shared Local 6 Add node

16 Actions (3/3) Example: Lock coupling list Shared Local Add node

17 Actions (3/3) Example: Lock coupling list Shared Local Lock node

18 Actions (3/3) Example: Lock coupling list Shared Local Lock node

19 Actions (3/3) Example: Lock coupling list Shared Local Delete node

20 Actions (3/3) Example: Lock coupling list Shared Local 6 Delete node

21 Actions (3/3) Example: Lock coupling list Shared Local 6 Now, the node is local; we can safely dispose it.

22 Actions (3/3) Example: Lock coupling list Shared Local Now, the node is local; we can safely dispose it.

23 Program & environment Program: the current thread being verified. Environment: all other threads of the system that execute in parallel with the thread being verified. Interference. The program interferes with the environment by modifying the shared state. Conversely, the environment interferes with the program by modifying the shared state.

24 Program specifications The specification of a program consists of two assertions (precondition & postcondition), and two sets of actions: Rely: Describes the interference that the program can tolerate from the environment; i.e. specifies how the environment can change the shared state. Guarantee: Describes the interference that the program imposes on its environment; i.e. specifies how the program can change the shared state.

25 Stability (1/2) Definition. An assertion is stable if and only if it is preserved under interference by other threads. Example 1. The following assertion is not stable A A For instance, another thread could remove node 3 or add a node after node 11.

26 Stability (1/2) Definition. An assertion is stable if and only if it is preserved under interference by other threads. Example 1. The following assertion is not stable A A For instance, another thread could remove node 3 or add a node after node 11.

27 Stability (1/2) Definition. An assertion is stable if and only if it is preserved under interference by other threads. Example 1. The following assertion is not stable A For instance, another thread could remove node 3 or add a node after node 11. A 12

28 Stability (2/2) Example 2. The following assertion, however, is stable. A 5 A 7 Lock B Unlock B

29 Stability (2/2) Example 2. The following assertion, however, is stable. A 5 A 7 Add node B B Delete node B B B

30 Part II. Program logic Syntax & semantics of assertions Syntax & semantics of actions Syntax & semantics of judgements Some proof rules Checking stability

31 Assertion syntax Separation Logic Extended logic P, Q ::= false emp e = e e e x. P P Q P Q P Q h SL P Q h SL (P Q) h. (h SL P ) (h h SL Q) p, q ::= P P p q p q p q x. p x. p local shared

32 Assertion semantics l, s P l SL P l, s P l = (s SL P ) l, s p 1 p 2 l 1, l 2. (l = l 1 l 2 ) (l 1, s p 1 ) (l 2, s p 2 ) Split local state; share global state.

33 Actions x 0, v, t x tid, v, t x tid, v, t x 0, v, t x tid, v, t x tid, v, y y 0, v, t x tid, v, y y tid, v, t x tid, v, t

34 Judgements C sat (p, R, G, q) (precondition, rely, guarantee, postcondition)

35 Parallel rule C 1 sat (p 1, R G 2, G 1, q 1 ) C 2 sat (p 2, R G 1, G 2, q 2 ) (C 1 C 2 ) sat (p 1 p 2, R, G 1 G 2, q 1 q 2 ) Splits local state; Shares global state.

36 Atomic commands p, q stable under R (atomic C) sat (p,, G, q) (atomic C) sat (p, R, G, q) P 2, Q 2 precise (P 2 Q 2 ) G C sat ( (P 1 P 2,,, Q 1 Q 2 ) (atomic C) sat P 1 P 2 F,, G, Q 1 Q 2 F ) Local state Shared state

37 Stability S stable under P Q iff ((P S) Q) S

38 The End Further topics: Automation (SmallfootRG) Local guards & provided clauses Modular reasoning about memory allocators Proving linearisability of concurrent algorithms

Proving That Non-Blocking Algorithms Don t Block

Proving That Non-Blocking Algorithms Don t Block Alexey Gotsman University of Cambridge Byron Cook Microsoft Research Matthew Parkinson University of Cambridge Viktor Vafeiadis Microsoft Research Abstract