Elastic TransactionsUnleashing Concurrency of Transactional Memory

Pascal Felber Vincent Gramoli Rachid Guerraoui

Goal: Concurrent Programming

1. Easiness: simple adaptation of sequential programming

2. Extensibility: existing code should be re-usable

3. Efficiency: high concurrency

Pessimistic vs. Optimistic Paradigm

• Pessimistic: first validate, then execute– May I modify the data safely?– If so go on, otherwise wait.

• Optimistic: first execute, then validate– Execute & hope for the best.– In worst case, roll-back!

Pessimistic vs. Optimistic Paradigm(cont'd.)

• Pessimistic approaches: Locks or Lock-free– Coarse-grained locking: large lock for mutual exclusion– Fine-grained locking: small multiple locks– Lock-free: universal primitives (e.g., Compare&Swap)

• Optimistic approach: Transactional Memory– Execute a transaction (tx), i.e., a set of operations– Check for potential conflicts (e.g., (write/read)-write)– Commit or abort so that conflicts are avoided

Pessimistic vs. Optimistic Paradigm(cont'd.)

Easy Extensible EfficientPessimistic Fine-grained locking

?Coarse-grained locking

Lock-free universal primitives

Optimistic Transactional models(either lock-based, lock-free, obs-free…)

Bucket Hash Table Example

yyxx maxmax@1

@2

…

@k

@ = Hash(x)

zz maxmax

maxmax

…

one sorted linked list

Bucket Hash Table Example (cont’d.)

1. Easiness: simple basic insert/delete/search operations

2. Extensibility: move(x,y) = delete(x) + insert(y)

3. Efficiency: conflict(insert(y), search(x)) only if x=y, x=y.next, or y=x.next.

Coarse-grained Locking

• Coarse-grained: inefficient

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

Insert(t)

Coarse-grained Locking

• Coarse-grained: inefficient

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

Insert(t)

conflict(insert(t), search(y)) whereas y≠t, y≠t.next, and t≠y.next.

tt

Fine-grained locking

• Lazy alg. [Heller et al. OPODIS05]: Uneasy

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

P2 delete

P1 delete

Fine-grained locking

• Lazy alg. [Heller et al. OPODIS05]: Uneasy

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

P2 delete

P1 would like to insert

P1 delete

P2 would like to insert

DEADLOCK!

Lock-free universal primitives• Harris-Michael [DISC01,SPAA02]: Non-extensible

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

Compare&Swap

P1 deletes

• Harris-Michael [DISC01,SPAA02]: Non-extensibleLock-free universal primitives

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

Compare&Swap

uu

Compare&Swap

P1 deletes

P1 inserts

move(y,u) ≠ delete(y) + insert(u)

• Harris-Michael [DISC01,SPAA02]: Non-extensibleLock-free universal primitives

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

Compare&Swap

yy

Compare&Swap

P1 deletes

P1 inserts

move(x,y) ≠ delete(x) + insert(y)

To become resizable, lock-free HT is

completely re-factored [JACM 2006].

Yet the resulting HT is not movable.To become resizable, lock-free HT is

completely re-factored [JACM 2006].

Yet the resulting HT is not movable.

Software Transactional Memories

• TinySTM, LSA-STM, SSTM, SwissTM: efficient?

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

insert(t) / search(y)

Software Transactional Memories

• TinySTM, LSA-STM, SSTM, SwissTM: efficient?

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

insert(t) / search(y)

conflict(insert(t), search(y)) whereas y≠t, y≠t.next, or t≠y.next.

tt

Elastic Transactional Memory (ε-STM)

• Elastic transactions: weaker than normal ones

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

insert(t) / search(y)tt

Elastic Transactional Memory (ε-STM)

• Elastic transactions: weaker than normal ones

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

insert(t) / search(y)tt

It is cut in 2 parts each w/ ops π(x,*) and π(y,*) if:- all writes are in the same part;- the first op of any part is a read; - there are no two writes on x and y between.

Elastic Transactional Memory (ε-STM)

• Elastic transactions: weaker than normal ones

yyxx maxmax@1

@2

…

@kzz maxmax

maxmax

…

insert(t) / search(y)tt

No conflict(insert(t), search(y)) if y≠t, y≠t.next, or t≠y.next.

Elastic Transactional Memory (ε-STM)

1. Easiness: labeling “BEGIN(elastic)/END” is the only requirement (instead of “BEGIN(normal)/END”)

2. Extensibility: – move(x,y) = delete(x) + insert(y)– compatible with normal transactions: sum_all(){BEGIN(normal); … END();}

3. Efficiency: relax the atomic snapshot of traditional transactions

μBenchmarks

μBenchmarks (Cont’d.)

Related Work: Other Transactional Models

• Open Nesting: – Each sub-transaction commits independently from

its parent transaction(s)

• Early Release:– Some reads may be forgotten (removed from r-set)

Related Work: Other Transactional Models

• Open Nesting: – Each sub-transaction commits independently from

its parent transaction(s)– Programmer must identify commutative operations– Programmer must define inverse operations

• Early Release:– Some reads may be forgotten (release() method)– Programmer must carefully identify when and what

should be released

Related Work: Other Transactional Models

• Open Nesting: – Each sub-transaction commits independently from

its parent transaction(s)– Programmer must identify commutative operations– Programmer must define inverse operations

• Early Release:– Some reads may be forgotten (release() method)– Programmer must carefully identify when and what

should be released

Complex roll-back

experienced

[Ni et al. PPoPP’07]Complex roll-b

ack

experienced

[Ni et al. PPoPP’07]

Issues prevent

automatization

[Harris et al. TRANSACT’07]

Issues prevent

automatization

[Harris et al. TRANSACT’07]

Conclusion

Easy Extensible EfficentPessimistic Fine-grained locking ✖ ✖ ✓

Coarse-grained locking ✓ ✓ ✖

Lock-free universal primitives

✖ ✖ ✓

Optimistic Transactional model ✓ ✓ ✖

Open nesting, early release ✖ ✓ ✓Elastic Transactions ✓ ✓ ✓

ε-STM

http://lpd.epfl.ch/gramoli/php/estm