1. LogSI-HTM: Log Based Snapshot Isolation in
Lois Orosa and Rodolfo Azevedo
University of Campinas
LogSI-HTM: Log Based Snapshot Isolation in
Hardware Transactional Memory
WTTM 2015
July 20, 2015, Donostia, Euskadi

2. Snapshot Isolation Model already used in some databases
Snapshot of memory at the beginning of the transaction
Logical Reordering of transactions (independent on the real commit ordering)
Do not abort transactions with read-write conflicts
Read-only transactions always commits
More than 75% of conflicts are Read-Write (STAMP Benchmarks)
Not serializable: Write-Skews
If there exists an invariant whose component variables span multiple concurrent transactions and the transactions have disjoint write sets

3. Transactional Memory Examples(I)
Behavior with different Tx Systems
Tx0
Tx1
Tx2
Tx3
beginTx
Read(A) -
Write(A)
Read(B)
Write(B)
Write(C)
Commit

4. Transactional Memory Examples(II)
2PL system (abort r-w, w-w) → too pessimistic
Tx0
Tx1
Tx2
Tx3
beginTx
Read(A) -
Write(A)
Read(B)
Write(B)
Write(C)
Commit
ABORT!

5. Transactional Memory Examples(IV)
Snapshot isolation
Tx0
Tx1
Tx2
Tx3
beginTx
Read(A) -
Write(A)
Read(B)
Write(B)
Write(C)
Commit
ABORT!!

6. State of the Art: SI-TM approach (I)
Litz et. al. , SI-TM, ASPLOS 2014
First hardware implementation of Snapshot isolation
Lazy conflict detection/Lazy version management
LLC Multiversion memory: overhead from 12,5% to 50%.
Uses timestamps to differentiate different versions of data.

7. State of the Art: SI-TM approach (II)
Transactions: Timestamps associated to the beginning and to the end of the transaction.
Commit: the new data is saved with the commit timestamp.
Transactions read data with the newest data older than its begin timestamp.

8. Our proposal: LogSI-HTM
Alternative Low cost implementation of Snapshot isolation in Hardware Transactional Memory.
Write skews for future work

9. Baseline Yen et. al., LogTM-SE, HPCA 2007
Eager conflict detection / eager version management (fast commits, slow aborts)
Leverages cache coherence protocol
Bloom filters for conflict detection
Old data in a private per-thread log (to restore old versions in aborts)
Commit: delete log, reset Bloom filters
Abort: restore the old versions in the log, reset Bloom filters

10. SI-HTM: key points Differences with LogTM-SE: Shared Logs
Each log have an associated timestamp (corresponding to the end of the transaction)
Logs are not deleted at commit time
Snapshot: different logs maintain different versions of data
No read Bloom filter
OV Bloom filters: maintains write sets of committed transactions
Taken from the state of the art SI-TM:
Uses timestamps

11. Protocol (I) Tx1 snapshot: A0 Tx2 snapshot: A0
Commit: send the write set to all the in-flight Txs (saved in the OV Bloom filter)
A pointer to the log is sent to all the in-flight transactions.
The old versions of data are available beyond the scope of the transaction.
Reads: check for conflicts in the OV Bloom filter → if match, reads data from the log
The last in-flight transaction deletes the log

12. Protocol (II) Tx1 snapshot: A0 Tx4 snapshot: A0 Tx3 snapshot: A0

13. Open Issues Simulation → Performance?
Read old version from logs can slowdown the system
Caches/Translation tables → speed up
Solutions for Write skews → HW approach?

14. Conclusion Simpler alternative to ASPLOS´14 paper
No multiversion memory
New approach Eager-Eager
Fast commits, slow aborts. No problem: abort rate is low

15. QUESTIONS?

16. Snapshot Isolation Issues
Not serializable: Write skew anomalies
Occurs if there exists an invariant whose component variables span multiple concurrent transactions and the transactions have disjoint write sets
Example:
void Withdraw ( bool account , int value ){
if ( checking+saving>value )
if ( account )
checking−=value ;
else
saving−=value ; }
Initial values:
Checking=10
Saving=10
Tx1
Tx2
beginTx()
Withdraw(true, 15)
Withdraw(false, 15)
EndTx()
Final values:
Checking=-5
Saving=-5