elastic transactions unleashing concurrency of transactional memory pascal felber vincent gramoli...
Post on 15-Jan-2016
246 views
TRANSCRIPT
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