LECTURE 12 TRANSACTIONAL MEMORY -...
Transcript of LECTURE 12 TRANSACTIONAL MEMORY -...
6.888 PARALLEL AND HETEROGENEOUS COMPUTER ARCHITECTURE
SPRING 2013
LECTURE 12
TRANSACTIONAL MEMORY
DANIEL SANCHEZ AND JOEL EMER
[BASED ON EE382A MATERIAL FROM KOZYRAKIS]
Transactional Memory (TM) 2
Memory transaction [Lomet’77, Knight’86, Herlihy & Moss’93]
An atomic & isolated sequence of memory accesses
Inspired by database transactions
Atomicity (all or nothing)
At commit, all memory writes take effect at once
On abort, none of the writes appear to take effect
Isolation
No other code can observe writes before commit
Serializability
Transactions seem to commit in a single serial order
The exact order is not guaranteed though
6.888 Spring 2013 - Sanchez and Emer - L12
Programming with TM 3
Declarative synchronization
Programmers says what but not how
No explicit declaration or management of locks
System implements synchronization
Typically with optimistic concurrency [Kung’81]
Slow down only on conflicts (R-W or W-W)
void deposit(account, amount){
lock(account);
int t = bank.get(account);
t = t + amount;
bank.put(account, t);
unlock(account);
}
void deposit(account, amount){
atomic {
int t = bank.get(account);
t = t + amount;
bank.put(account, t);
}
}
6.888 Spring 2013 - Sanchez and Emer - L12
Advantages of TM 4
Easy to use synchronization
As easy to use as coarse-grain locks
Programmer declares, system implements
Performs as well as fine-grain locks
Automatic read-read & fine-grain concurrency
No tradeoff between performance & correctness
Failure atomicity & recovery
No lost locks when a thread fails
Failure recovery = transaction abort + restart
Composability
Safe & scalable composition of software modules
6.888 Spring 2013 - Sanchez and Emer - L12
Performance: Locks Vs Transactions 5
0
0.2
0.4
0.6
0.8
1
1 2 4 8 16
Processors
Ex
ec
uti
on
Tim
e
coarse locks fine locks TCC
0
0.5
1
1.5
2
2.5
3
3.5
4
1 2 4 8 16
Processors
Ex
ec
uti
on
Tim
e
coarse locks fine locks TCC
Ba
lan
ce
d T
ree
H
as
hM
ap
TCC: a HW-based TM system
[Hammond et al, ISCA’04]
6.888 Spring 2013 - Sanchez and Emer - L12
TM Implementation Basics 6
TM systems must provide atomicity and isolation without sacrificing concurrency
Basic implementation requirements
Checkpointing
Data versioning
Conflict detection & resolution
Implementation options
Hardware transactional memory (HTM)
Software transactional memory (STM)
Hybrid transactional memory Hardware accelerated STMs and dual-mode systems
6.888 Spring 2013 - Sanchez and Emer - L12
Motivation for Hardware TM 7
Measured single-thread STM performance:
Software TM suffers 2-8x slowdown over sequential
Short term issue: demotivates parallel programming
Long term issue: not energy-efficient
Industry adopting HTM: Sun (Rock), Intel (Haswell), IBM (Blue Gene
and zSeries)
0.0
0.5
1.0
1.5
2.0
kmeans
Execu
tio
n T
ime
(norm
alized to s
equentia
l)
0
1
2
3
4
5
6
vacation
STMwrite
STMread
STMcommit
Busy
6.888 Spring 2013 - Sanchez and Emer - L12
Data Versioning 8
Manage uncommited (new) and commited (old) versions of data for concurrent
transactions
1. Eager versioning (undo-log based)
Update memory location directly
Maintain undo info in a log
+ Faster commit, direct reads (SW)
– Slower aborts, fault tolerance issues
2. Lazy versioning (write-buffer based)
Buffer data until commit in a write-buffer
Update actual memory location on commit
+ Faster abort, no fault tolerance issues
– Slower commits, indirect reads (SW)
6.888 Spring 2013 - Sanchez and Emer - L12
Eager Versioning Illustration 9
Begin Xaction
Thread
X: 10 Memory
Undo
Log
Write X←15
Thread
X: 15 Memory
Undo
Log X: 10
Commit Xaction
Thread
X: 15 Memory
Undo
Log X: 10
Abort Xaction
Thread
X: 10 Memory
Undo
Log X: 10
6.888 Spring 2013 - Sanchez and Emer - L12
Lazy Versioning Illustration 10
Begin Xaction
Thread
X: 10 Memory
Write
Buffer
Write X←15
Thread
X: 10 Memory
Write
Buffer X: 15
Abort Xaction
Thread
X: 10 Memory
Write
Buffer X: 15
Commit Xaction
Thread
X: 15 Memory
Write
Buffer X: 15
6.888 Spring 2013 - Sanchez and Emer - L12
Conflict Detection 11
Detect and handle conflicts between transaction
Read-Write and (often) Write-Write conflicts
Must track the transaction’s read-set and write-set
Read-set: addresses read within the transaction
Write-set: addresses written within transaction
1. Pessimistic (Eager) detection
Check for conflicts during loads or stores
SW: SW barriers using locks and/or version numbers
HW: check through coherence actions
Use contention manager to decide to stall or abort
Various priority policies to handle common case fast
6.888 Spring 2013 - Sanchez and Emer - L12
Pessimistic Detection Illustration 12
Case 1 Case 2 Case 3 Case 4
X0 X1
rd A
wr B
check
check
wr C check
commit
commit
Success
X0 X1
wr A
rd A
check
check
commit
commit
Early Detect
stall
X0 X1
rd A
wr A
check
check
commit
commit
Abort
restart
rd A check
X0 X1
rd A
check
No progress
wr A
rd A wr A
check
restart
rd A
check
wr A
restart
rd A wr A
check
restart
TIM
E
6.888 Spring 2013 - Sanchez and Emer - L12
Conflict Detection (cont) 13
2. Optimistic (Lazy) detection
Detect conflicts when a transaction attempts to commit
SW: validate write/read-set using locks or version numbers
HW: validate write-set using coherence actions
Get exclusive access for cache lines in write-set
On a conflict, give priority to committing transaction
Other transactions may abort later on
On conflicts between committing transactions, use contention manager to
decide priority
Note: optimistic & pessimistic schemes together
Several STM systems are optimistic on reads, pessimistic on writes
6.888 Spring 2013 - Sanchez and Emer - L12
Optimistic Detection Illustration 14
Case 1 Case 2 Case 3 Case 4
X0 X1
rd A
wr B
wr C
commit
commit
Success
X0 X1
wr A
rd A
commit
Abort
restart
X0 X1
rd A
wr A
commit
Success
X0 X1
rd A
Forward progress
wr A
rd A wr A
check
check
check
rd A
check
commit check
commit check
restart
rd A wr A
commit check
TIM
E
commit check
6.888 Spring 2013 - Sanchez and Emer - L12
Conflict Detection Tradeoffs 15
1. Pessimistic conflict detection (aka eager, encounter)
+ Detect conflicts early
• Undo less work, turn some aborts to stalls
– No forward progress guarantees, more aborts in some cases
– Locking issues (SW), fine-grain communication (HW)
2. Optimistic conflict detection (aka lazy, commit)
+ Forward progress guarantees
+ Potentially less conflicts, shorter locking (SW), bulk communication (HW)
– Detects conflicts late, still has fairness problems
6.888 Spring 2013 - Sanchez and Emer - L12