An Introduction to Software Transactional Memory Alessia Milani Labri, Bordeaux.
-
Upload
matthew-lawrence -
Category
Documents
-
view
217 -
download
2
Transcript of An Introduction to Software Transactional Memory Alessia Milani Labri, Bordeaux.
An Introduction to Software Transactional Memory
Alessia Milani
Labri, Bordeaux
Popularizing Concurrent Programming
• A multi-core revolution is underway• Exploit the power of concurrent
computing, by restructuring applications• Devise scalable concurrent programs is
hard…unless good abstractions :☞ Transaction
2
Transaction
A transaction is a sequence of operations by a single process on a set of shared data items (transactional objects) that ends
Either by committing : all of its updates take effect atomically
or by aborting : has no effect (typically restarted)
3
4
Transactional Memory (TM)
• To simplify : Just wrap (sequential) code in begin / end transaction
• TM synchronizes memory accesses so that each transaction seems to execute sequentially and in isolation
begin-transaction-------------------------------------------------------------end-transaction
Implementing Transactional Memory
• TM was originally suggested as hardware platform [Herlihy and Moss 1993]
– HTM is in today hardware platforms, e.g. Intel, IBM, Sun
• Purely in software : – First Software Transactional Memory (STM) only
for static transactions [Shavit & Touitou 1995]
– First dynamic STM [Herlihy, Luchnagco, Moir and Schrer 2003]
• Hybrid schemes (HyTM) that combine hardware and software [Moir et al. 2006]
Implementing Transactional Memory in Software (STM)
• Data representation for transactions and data items using base objects
• Algorithms for operations on data items, applying primitives to base objects– registers, CAS, DCAS
Asynchronous processes execute these algorithms to execute the operations of the transactions
base objects read
read
write
TryCommit
…
begin-transaction
end-transaction
Algorithms
6
7
3 levels of abstractions
• Transaction
• Operations – on data items: E.g., read
and write– tryCommit / tryAbort
• Primitives on base objects (registers, CAS…)
read write tryCread
STM algorithms
Main Techniques
8
Back to TM ConsistencySerializability: committed transactions
appear to execute sequentially
begin-Tx
read write
write writeread read
TryC
TryC
Commit
read
begin-Tx Commit
begin-Tx
write writeread read TryC
Commit
read write TryCread
begin-Tx Commit
Back to TM ConsistencySerializability: committed transactions
appear to execute sequentiallyStrict serializability: also preserves the
order of non-overlapping transactions [Papadimitriou 1979]
Opacity: even transactions that later abort are (strictly) serializable [Guerraoui, Kapalka POPL 2008]
Much more …
serializability
strictserializability
opacity
Conflicts
• Two concurrent transactions have a conflict if they access the same data item and at least one of these accesses is a Write operation.
• Two transactions that cannot be serialized have a conflict. (The converse is not true)
11
p1
begin-Tx
Read(x)0
Read(x)0
Commit
begin-Tx
Write(x)1
Write(x)2
Commit
p2
p1
begin-Tx
Read(y)0
Read(x)0
Commit
begin-Tx
Write(y)1
Write(x)1
Commit
p2
12
Design approaches
• Deferred/Direct updates : operate on local copies of the data items & install changes at commit/ Modify in place, roll back on abort
• Detect conflicts– Commit time– Encountering time
• Resolve a conflict either by aborting one of the conflicting transactions or by waiting/helping it to complete– This depends on the progress you want– Contention manager
13
Contention Manager Strategies
• Priority to– Oldest?– Most work?
…
• None Dominates• Lots of empirical work but formal work in
infancy
Progress for TM• Lock-free TM
– Wait-freedom : each non-faulty process completes (successfully) its transaction within a finite number of steps
– Obstruction-freedom : a process running solo eventually commits its transaction
• Lock-Based TM– Weakly progressive: a transaction aborts only if it has conflicts
[Guerraoui, Kapalka POPL 2009]– Strongly progressive: at least one of the transactions involved in the
conflict commits– Multi-version permissive: only writing transaction that conflicts with
another writing transaction aborts[Perelman, Fan, Keidar PODC 2010]
Read-only transactions always commit
STM algorithms
Two Case Studies
15
16
A lock-based STM : TL2[Dice et al. DISC 2006]
• Each data item is associated with a version number– TL2 relies on a global versioning clock
• Transaction keeps– Read set: data items & values read– Write set: data items & values to be written
• Deferred update– Changes installed at commit
• Lazy conflict detection– Conflicts detected at commit
100
1717
Read-Only Transactions
12
32
56
19
17
100
Shared Version Clock
Private Read Version (RV)
Copy version clock to local read version clock
RV
Copy version clock to local read version clock
RV
Mem Locks
100
1818
Mem Locks
12
32
56
19
17
100
Shared Version Clock
Private Read Version (RV)
18
Copy version clock to local read version clockCopy version clock to
local read version clockEach read operation is
post-validated checking the lock and version # of
the corresponding memory location
Each read operation is post-validated checking
the lock and version # of the corresponding memory location
Read-Only Transactions
1919
12
32
56
19
17 Private Read Version (RV)
Copy version clock to local read version clockCopy version clock to
local read version clockRead lock, version #, and memory, check
version # less than read clock
Read lock, version #, and memory, check
version # less than read clock
COMMIT if no post-validation fails. Otherwise ABORT as
soon as one Read fails
COMMIT if no post-validation fails. Otherwise ABORT as
soon as one Read fails
100
Shared Version Clock
100
19
Mem Locks
Read-Only Transactions
2020
Read-Only Transactions
12
32
56
19
17
100
Shared Version Clock
Private Read Version (RV)
100
We have taken a snapshot without keeping an explicit read
set!
We have taken a snapshot without keeping an explicit read
set!
20
Mem Locks
Example Execution: Read Only Trans
1. RV Shared Version Clock2. On Read: read lock, read mem,
read lock: check unlocked, unchanged, and v# <= RV
3. Commit.
87 0 87 0
34 0
88 0
V# 0
44 0
V# 0
34 0
99 0 99 0
50 0 50 0
Mem Locks
Reads form a snapshot of memory.No read set!
100 Shared Version Clock
87 0
34 0
99 0
50 0
87 0
34 0
88 0
V# 0
44 0
V# 0
99 0
50 0
100 RV
100
2222
Writing TransactionsMem
Locks
12
32
56
19
17
100
Shared Version Clock
Private Read Version (RV)
Copy version clock to local read version clock
RV
Copy version clock to local read version clock
RV
22
100
2323
Writing TransactionsMem
Locks
12
32
56
19
17
100
Shared Version Clock
Private Read Version (RV)
Copy version clock to local read version clockCopy version clock to
local read version clockOn read/write, check:
Unlocked & version # < RV
Add to R/W set
On read/write, check:Unlocked & version # <
RVAdd to R/W set
23
2424
On CommitMem
Locks
100
Shared Version Clock
100
12
32
56
19
17 Private Read Version (RV)
Acquire write locksAcquire write locks
Art of Multiprocessor Programming
2525
On CommitMem
Locks
100
Shared Version Clock
100101
12
32
56
19
17 Private Read Version (RV)
Acquire write locksAcquire write locks
Increment Version ClockIncrement Version Clock
25
Art of Multiprocessor Programming
2626
On Commit
Mem Locks
100
Shared Version Clock
100101
12
32
56
19
17 Private Read Version (RV)
Acquire write locksAcquire write locks
Increment Version ClockIncrement Version ClockCheck version numbers
≤ RVCheck version numbers
≤ RV
26
2727
On Commit
Mem Locks
100
Shared Version Clock
100101
12
32
56
19
17 Private Read Version (RV)
Acquire write locksAcquire write locks
Increment Version ClockIncrement Version ClockCheck version numbers
≤ RVCheck version numbers
≤ RVUpdate memoryUpdate memoryx
y
27
2828
On CommitMem Locks
100
Shared Version Clock
100101
12
32
56
19
17 Private Read Version (RV)
Acquire write locksAcquire write locks
Increment Version ClockIncrement Version ClockCheck version numbers
≤ RVCheck version numbers
≤ RVUpdate memoryUpdate memory
Update write version #sUpdate write version #s
x
y
101
101
28
Example: Writing Transaction
1. RV Shared Version Clock2. On Read/Write: check
unlocked and v# <= RV then add to Read/Write-Set
3. Acquire Locks4. WV = F&I(VClock)5. Validate each v# <= RV6. Release locks with v# WV
100 Shared Version Clock
87 0 87 0
34 0
88 0
44 0
V# 0
34 0
99 0 99 0
50 0 50 0
Mem Locks
87 0
34 0
99 0
50 0
34 1
99 1
87 0
X
Y
Commit
121 0
121 0
50 0
87 0
121 0
88 0
V# 0
44 0
V# 0
121 0
50 0
100 RV
100120121
X
Y
29
30
A lock-free STM : Dynamic Software Transactional Memory
• Proposed in [Herlihy et al. DISC 2003] – Opacity & obstruction freedom
• Transaction keeps– Read set: data items & values read
• Direct update– Changes installed when the corresponding Write
is executed• Eager conflict detection
– Conflicts detected at encountering time
DSTM : transaction and transactional object representation
• A transaction has – a status field that is initialized to be ACTIVE, and it is later COMMITED or
ABORTED using a CAS primitive– a readlist to store the data items read together with the values read
• Each transactional object has the following structure
start
TMObject
transaction
new object
old object
status
Data
Data
Locator
Status of the transaction that most recently accessed the
object to write it
Current object version
• The current object version is determined by the status of the transaction that most recently accessed the object to WRITE :– committed: the new object is the current– aborted: the old object is the current– active: the old object is the current, and the new is
tentative
• The actual version only changes when a commit is successful
start
o
transactionnew object
old object
committed
Data
DataB’s Locator
1 A creates a new Locator
transactionnew object
old object
A’s Locator
2 A copies the previous new object, and sets new
Data
copy
3 A sets old object to the previous new
active4 Use CAS in
order to replace locator
If CAS fails, A restarts from the
beginning
Write operation : example• Transaction A tries to write object o. Let B be the transaction that
most recently accessed o to WRITE it
Which is the current version of the object if B is active?
• A and B are conflicting transactions, that run at the same time
• Use Contention Manager to decide which should continue and which should abort
• If B needs to abort, try to change its status to aborted (using CAS)
Read operation
• To read object o by a transaction A – Fetch the current version v just as before– Add the pair (o, v) to the read set of A
Validating a transaction
• Before returning the value either read or written, check consistency
• For each pair (o,v) in the read set, verify that v is still the most recently committed version of the transactional object o.
• Check that the status of the transaction is still ACTIVE
Committing a transaction
• The commit needs to do the following:1. Validate the transaction
2. Change the transaction’s status from active to committed (using CAS)
That’s it?
You are here
Irrevocable transactions
Multiversioning
Nested transactions
Distributed STM
Lower bounds
Privatization
Elastic Txs
More references and credits
Many of these slides are (largely inspired) from– The slides of “The Art of Multiprocessor
Programming” by Maurice Herlihy and Nir Shavit– A PODC 2010 talk by Hagit Attiya– Teaching slides by Danny Hendler
Other reference :– Transactional Memory,Foundations, Algorithms,
Tools, and Applications. COST Action Euro-TM IC1001. Lecture Notes in Computer Science, Springer 2014.