Download presentation

Presentation is loading. Please wait.

Published byChristopher Jackson Modified about 1 year ago

1
Safety Definitions and Inherent Bounds of Transactional Memory Eshcar Hillel

2
2 Transactional Memory Concurrency control mechanism Concurrent processes synchronize via in-memory transactions Inspired by database transactions A transaction is a sequence of operations on a set of data items (data set) to be executed atomically

3
3 The Specification (Signature) of Transactions A transaction (T) applies operations on high-level data items In general Read and Write operations: Read set: the items read by T Write set: the items written by T Other operations, such as: Push (into a queue) Remove (from a list) Increment (a counter) Read X Write X Read Z Read Y Read X Write X Read Z Read Y

4
4 The Specification (Signature) of Transactions A transaction (T) applies operations on high-level data items In general Read and Write operations: Read set: the items read by T Write set: the items written by T A transaction ends either by committing all its updates take effect or by aborting no update is effective Read X Write X Read Z Read Y Commit/ Abort Read X Write X Read Z Read Y Commit/ Abort

5
5 What is A Correct Implementation? Txs appear to be executed sequentially Committed txs take effect instantaneously at some single unique point in time Aborted transaction are discarded never become visible All transactions observe a consistent state (view) Additionally, transactions are expected to Preserve their real time order Allow Read operations return not the last written value

6
6 Outline of This Talk Model of TM Safety conditions Liveness conditions Implementations restrictions (Next hour) Inherent limitations on TMs Time complexity lower bound Impossibility result

7
7 Model of Transactional Memory Operation = invocation + response events Invocation events: try-commit, try-abort Response events: commit, abort A (high-level) history H is a sequence of invocation and response events performed by all txs in a given execution well-formed In a sequential (serial) history S txs run sequentially

8
8 What is A Correct Implementation? Safety Conditions Candidates Serializability: every history is equivalent to some sequential history Do not preserve real time order Strict serializability: (like serializability and) Preserves real time order Read operations must return the last written value 1-copy serializability: (like serializability and) Allows a Read to return not the last written value Assumes only Read and Write operations

9
9 What is A Correct Implementation? Safety Conditions Candidates Global atomicity: Distributed db Each transaction is divides into subtransactions executed locally in different sites All sites must commit or all abort Allows a Read operation to return not the last written value Do not limit to Read/Write operations Concerns only committed transactions, aborted transactions may access inconsistent state

10
10 What is A Correct Implementation? Safety Conditions Candidates Global atomicity + strict recovability: if a tx T updates an item, then no other tx applies any operation to this item until T either commits or aborts Insufficient p1p1 p2p2 W(x,2) W(y,2) C W(x,1) C R(x,1) R(y,2) A

11
11 What is A Correct Implementation? Safety Conditions Candidates Global atomicity + strict recovability: if a tx T updates an item, then no other tx applies any operation to this item until T either commits or aborts Insufficient And in fact, too strict p2p2 p3p3 x.Inc() p1p1

12
12 What is A Correct Implementation? Opacity In a complete history all txs are completed Complete(H) is a set of all possible completions of H in which Every commit-pending tx is committed/aborted Other live txs are aborted Visible(S) is the longest subsequence of S Committed txs At most one aborted tx at the suffix of S

13
13 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal

14
14 What is A Correct Implementation? Opacity - Refined A history H ensures opacity if some history in Complete(H) is equivalent to a sequential history S, such that: S preserves the real-time order of H Visible(S) is legal

15
15 What is A Correct Implementation? Opacity - Refined A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' Visible(S) is legal p1p1 p2p2 R(x,1) tC C W(x,1) tC C

16
16 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal p1p1 p2p2 R(x,5) W(x,1)

17
17 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal p1p1 p2p2 W(x,2) W(y,2) C W(x,1) C R(x,1) R(y,2) A

18
18 Liveness Conditions Obstruction-free: if a transaction is (eventually) running solo then it completes Nonblocking: always some tx terminate successfully Wait-free: all txs always terminate successfully

19
19 Implementing TM in Software Data representation for txs & data Algorithms to execute operations in terms of (low-level) primitives on base objects e.g., read write CAS

20
20 Implementation Restrictions Progressive: abort transactions only on real conflicts Invisible reads: no base object is modified during read operations Read-only txs only observe the data Empty write set Invisible: not modify any base object Invisibility helps avoid contention for the memory Single version: store only latest committed values in items Vs multi-version TMs

21
21 Implementation Restrictions T1T1 Read(Y) Write(X 1 ) T2T2 Write(X 2 ) T3T3 Read(X 2 ) Read(X 1 ) Disjoint data sets no contention Data sets are connected may contend Y X2X2 X1X1 T3T3 T1T1 Improves scalability for large data structures by reducing interference DAP: Disjoint-Access Parallelism

22
22 DAP: More Formally An STM implementation is disjoint-access parallel if two concurrent transactions T 1 and T 2 access the same base object ONLY IF the data sets of T 1 and T 2 are connected. The data sets of T 1 & T 2 either intersect or are connected via other transactions

23
Questions? (Coffee) Break

24
24 Time Complexity Lower Bound Theorem: Some operation in a progressive, single-version TM implementation that ensures opacity and uses invisible reads has Ω(k) time complexity k is the number of items The proof refers to the size of the data set (which can be as big as the number of items)

25
25 Time Complexity Lower Bound Proof intuition: Consider an execution of two txs T1, T2: T1 reads k-1 items T2 writes to k items and commits T1 reads an item written by T2 p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

26
26 Time Complexity Lower Bound Proof intuition: T1 cannot abort if the view is consistent (progressive) If T1 returns a value then it returns the value written by T2(single version) p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

27
27 Time Complexity Lower Bound Proof intuition: T1 needs to validate the k-1 first items (opacity) T2 cannot help/notify T1 in case of inconsistent view (invisible reads) T1 needs to do the job - Ω(k) steps - by itself ■ p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

28
28 Impossibility Result Theorem. There is no DAP implementation with invisible & wait-free read-only transactions of an opaque TM Proof utilizes the notion of a flippable execution, used to prove lower bounds for atomic snapshot objects [Attiya, Ellen & Fatourou]

29
29 Flippable Execution w/ 2 Updaters p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k A complete transaction in which p 1 writes l-1 to X 1 A read-only transaction by q that reads X 1, X 2 EkEk

30
30 Flippable Execution w/ 2 Updaters p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk Indistinguishable from executions where the order of (each pair of) updates is flipped… In one of two ways (forward and backward).

31
31 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk

32
32 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Forward Flip

33
33 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Forward Flip

34
34 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk

35
35 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Backward Flip

36
36 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Backward Flip

37
37 Lemma 1 The read-only transaction of q cannot terminate successfully Relies on strict serializabitly Any history is equivalent to a sequential history of the same set of transactions (a serialization) The serialization must preserve the real-time order of (non-overlapping) transactions Why Flippable Executions?

38
38 Serialization of E k p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk U 1 … U l …U 0 U l-1 U k Serialization of E k : Possible serialization point Returns (l-1,l-2)

39
39 Nowhere to Serialize p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk U 1 … U l …U 0 U l-1 U k Serialization Returns (l-1,l-2) p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k BW Flip Still returns (l-1,l-2) U 1 … U l U l-1 … U k U0U0 Serialization x Indistinguishable from some flip (say, backward) X 1 = l-3 X 2 = l-2 X 1 = l-3 X 2 = l X 1 = l-1 X 2 = l

40
40 Lemma 2 In a DAP TM, two consecutive txs U 1, U 2 from a quiescent configuration, that write to disjoint data sets do not contend on the same base object.

41
41 Proof of Lemma 2 Assume U 1 and U 2 contend on some base object Let o be the last base object accessed by U 1 for which U 2 has a contending access U1U1 C U2U2 Last contending access to o First contending access to o

42
42 Proof of Lemma 2 C U2U2 U1U1 U1 and U2 have disjoint data set and they contend on some base object Not a DAP Implementation U1U1 C U2U2 Last contending access to o First contending access to o

43
43 Completing the Proof Show that a flippable execution exists The steps of the read-only transaction can be removed (since it is invisible) Since their data sets are disjoint, transactions U l & U l-1 do not “communicate” (by Lemma 2) Can be flipped By Lemma 1, the read-only transaction cannot terminate successfully If aborts, can apply the same argument again…

44
44 The Assumptions are Necessary Read-only Tx termination Invisible read-only Tx DAPAlgorithm [Herlihy, Luchangco, Moir & Scherer] [Avni & Shavit] [Riegel, Felber & Fetzer] ~~ Harris, Fraser & Pratt]

45
45 Also a Lower Bound A transaction with a data set of size t must write to t-1 base objects

46
46 Sources On the correctness of transactional memory, Rachid Guerraoui, Michal Kapalka, PPOPP 2008 Inherent Limitations on Disjoint-Access Parallel Implementations of Transactional Memory, Hagit Attiya, Eshcar Hillel, and Alessia Milani, TRANSACT 2009 Thank you!

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google