inherent limitations on dap tms 1 inherent limitations on disjoint-access parallel transactional...

Inherent limitations on DAP TMs 1

Inherent Limitations on Disjoint-Access Parallel Transactional Memory

Hagit Attiya, Eshcar Hillel, Alessia MilaniTechnion


Complexity Bounds for STMs: Why? Indicate futile design choices Elucidate expectations (specification) Spell out assumptions

(models of the architecture)


DAP: Disjoint Access Parallelism

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


Optimizing for Read-Only Transactions

Transactions that do not modify the data should

Be invisible (not write to low-level objects) Avoid contention for the memory

Always terminate successfully (wait-free)


Some Known STMs…

AlgorithmDAPInvisible read-only Tx

Read-only Tx termination

[Herlihy, Luchangco, Moir & Scherer]

[Avni & Shavit][Riegel, Felber & Fetzer]

Coincidence or inherent tradeoff ?


Inherent Tradeoff

Theorem. There is no TM implementation that is DAP

and has invisible & wait-free read-only transactions

The paper also shows a lower bound:Theorem. A transaction with a data set of size t must

write to t-1 base objects

Both proofs utilize the flippable execution, used to prove lower bounds for atomic snapshot objects

[Israeli & Shirazi] [Attiya, Ellen & Fatourou]


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


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).


Flippable Execution: Backward Flip

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

p1

p2


U1 … Ul…

U0 … Ul-1 … Uk

Backward Flip


Lemma 1. The read-only transaction of q cannot terminate successfully

Relies on strict serializabitly (~linearizability) The serialization of committed transactions

must preserve the real-time order of non-overlapping transactions

Why Flippable Executions?


Serialization of Ek

p1

p2


U1 … Ul …

U0 … Ul-1 … Uk

Ek

U1 … Ul … U0 Ul-1 UkSerializationof Ek:

Serialization point

Returns (l-1,l-2)


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

Indistinguishable from some flip

(say, backward)


Completing the Proof

Show that a flippable execution exists The read-only transaction is invisible

its steps can be removed Transactions Ul & Ul-1 have disjoint data sets

Ul & Ul-1 do not “communicate” (by DAP)

Ul & Ul-1 can be flipped

By Lemma 1, the read-only transaction cannot terminate successfully If aborts, can apply the same argument again…


Complexity Bounds for STMs: What are the implications? Adapt your expectations

What STM guarantees (e.g. consistency) What you measure:

Best case, average case Special workloads


Weaker Liveness Condition

If a transaction runs alone from a quiescent configuration then it terminates successfully

Weakly progressive

blocking implementation[Guerraoui & Kapalka]

OUR RESULTSSTILL HOLD


Serializability Snapshot Isolation Virtual world consistency

Causal consistency Causal serializability

16

Weaker Consistency Conditions

OUR RESULTSSTILL HOLD

OPEN PROBLEM


Thank you![paper in SPAA 09]

inherent limitations on dap tms 1 inherent limitations on disjoint-access parallel transactional...

Documents