Safety Definitions and Inherent Bounds of Transactional Memory Eshcar Hillel

Safety Definitions and Inherent Bounds of Transactional Memory

Eshcar Hillel

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

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 XWrite XRead ZRead Y


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


Commit/ Abort


Commit/ Abort

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

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

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

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

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 operationsConcerns only committed transactions, aborted

transactions may access inconsistent state

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

p1

p2 W(x,2) W(y,2) C

W(x,1) C

R(x,1) R(y,2) A

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

p2

p3

x.Inc()

p1

x.Inc()

x.Inc()

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

What is A Correct Implementation? OpacityA 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

What is A Correct Implementation? Opacity - RefinedA 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

What is A Correct Implementation? Opacity - RefinedA history H ensures opacity if for every


S preserves the real-time order of H' Visible(S) is legal

p1

p2 R(x,1) tC C

W(x,1) tC C

16





p1

p2 R(x,5)

W(x,1)

17





p1

p2 W(x,2) W(y,2) C

W(x,1) C

R(x,1) R(y,2) A

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

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

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

Implementation Restrictions

T1 Read(Y) Write(X1)

T2Write(X2)

T3 Read(X2)Read(X1)

Disjoint

dat

a se

ts

n

o co

nten

tion

Data

sets

are

con

nect

ed

m

ay con

tend

Y

X2X1 T3

T1

Improves scalability for large data structures by reducing interference

DAP: Disjoint-Access Parallelism

22

DAP: More Formally

An STM implementation is disjoint-access parallel if two concurrent transactions T1 and T2 access the same base object ONLY IF the data sets of T1 and T2 are connected.

The data sets of T1 & T2 either intersect or are connected via other transactions

Questions?

(Coffee) Break

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

Time Complexity Lower BoundProof 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

p1

p2

R11 …

R1k-1

R1k

W21 … W2

k

26

Time Complexity Lower BoundProof 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)

p1

p2

R11 …

R1k-1

R1k

W21 … W2

k

27

Time Complexity Lower BoundProof 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■p1

p2

R11 …

R1k-1

R1k

W21 … W2

k

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

Flippable Execution w/ 2 Updaters

p1

p2

q s1 … sl-1 sl … sk

U1 … Ul …

U0 … Ul-1 … Uk

A complete transaction in which p1 writes l-1 to X1A read-only

transaction by q that reads X1 , X2

Ek

30

Flippable Execution w/ 2 Updaters

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

Indistinguishable from executions where the order of (each pair of) updates is flipped…

In one of two ways (forward and backward).

31

Flippable Execution: Forward Flip

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

32


p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Forward Flip

33


p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Forward Flip

34

Flippable Execution: Backward Flip

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

35


p1

p2


U1 … Ul…

U0 … Ul-1 … Uk

Backward Flip

36


p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

p1

p2


U1 … Ul…

U0 … Ul-1 … Uk

Backward Flip

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

Serialization of Ek

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

U1 … Ul … U0 Ul-1 UkSerializationof Ek:

Possible serialization point

Returns (l-1,l-2)

39

Nowhere to Serialize

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

U1 … Ul … U0 Ul-1 UkSerialization

Returns (l-1,l-2)

p1

p2


U1 … Ul…

U0 … Ul-1 … Uk

BW Flip Still

returns (l-1,l-2)

U1 … Ul Ul-1 … Uk

U0Serialization x

Indistinguishable from some flip

(say, backward)

X1 = l-3X2= l-2

X1 = l-3X2= l

X1 = l-1X2= l

40

Lemma 2

In a DAP TM, two consecutive txs U1, U2

from a quiescent configuration, that write to disjoint data sets do not contend on the same base object.

41

Proof of Lemma 2

Assume U1 and U2 contend on some base object

Let o be the last base object accessed by U1 for which U2 has a contending access

U1

C

U2

Last contending access to o

First contending access to o

42

Proof of Lemma 2

C

U2

U1

U1 and U2 have disjoint data set and they

contend on some base object

Not

a D

AP

Impl

emen

tatio

n

U1

C

U2

Last contending access to o

First contending access to o

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

Ul & Ul-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

The Assumptions are Necessary

AlgorithmDAPInvisible read-only Tx

Read-only Tx termination

[Herlihy, Luchangco, Moir & Scherer]

[Avni & Shavit][Riegel, Felber & Fetzer]Harris, Fraser & Pratt]~

45

Also a Lower Bound

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

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!

Documents

Safety Definitions and Inherent Bounds of Transactional Memory Eshcar Hillel