Lecture 17: Transactional Memories I Papers: A Scalable Non-Blocking Approach to Transactional Memory, HPCA’07, Stanford The Common Case Transactional Behavior of Multi-threaded Programs, HPCA’06, Stanford Characterization of TCC on Chip Multiprocessors, PACT’05, Stanford

TM Overview Recall the basic TM implementation: Every transaction maintains read-set and write-set Writes are not propagated until commit time At commit, acquire permission to commit from a central arbiter (no parallel commit for now) Send write-set to other nodes – if the write-set intersects with the node’s read-set, the node’s transaction is aborted and re-started

Implementation Issues Design details: On attempting a write (the Tx is not yet ready to commit), must obtain the most recently committed version of the block in read-only state (the block is not yet part of the read-set, though) At the time of commit, either write-thru to memory (there is no M state in the coherence protocol), or move from S to M state (write-back policy) (a dirty line can’t handle speculative writes, though) For parallel commits: is an ordering implied between these transactions? is a write-set/read-set conflict allowed? is a read-set/write-set conflict allowed? is a write-set/write-set conflict allowed?

Parallel Commits I Ordering is implied: a programmer believes that a transaction executes “in isolation” Write-set/Read-set conflict should cause an abort: hence, the second transaction must: confirm there is no conflict before propagating writes or propagate writes in a manner that does not affect correctness (can’t employ write-thru or write-update, can’t respond to others’ read requests / or must keep track of dependences) Read-set/Write-set conflict need not cause an abort: the ordering should indicate that the first transaction need not abort Write-set/Write-set conflict need not cause an abort: a mechanism is required to ensure that everyone sees writes in the same correct order * Reading your own write is truly not a problem, but since info is maintained at block granularity, the block is included in the read-set

Parallel Commits II Conflicting writes must be merged correctly (note that the writes may be to different words in the same line) If we’re not checking early for Write-set/Read-set conflicts, the first transaction must inform the next transaction after it is done (received all acks) Consistency model: two parallel transactions are sending their write-sets to other nodes over unordered networks: Just as we saw for SC, a reader must not proceed unless everyone has seen the write (the entire transaction need not have committed) Writes to a location must be serialized

The Stanford Approach Transactions are ordered (by contacting a central agent) A transaction first engages in validation and proceeds with commit only if it is guaranteed to not have any conflicts Write-set/Read-set conflicts are not allowed (Ti checks its read-set directories and proceeds only after those directories have seen previous writes) Read-set/Write-set conflicts are allowed (Ti will ignore write notices from transactions >i) Write-set/Write-set conflicts are allowed To maintain write serialization, Ti confirms that a directory is done with all transactions <i

Algorithm Probe your write-set to see if it is your turn to write (helps serialize writes) Let others know that you don’t plan to write (thereby allowing parallel commits to unrelated directories) Mark your write-set (helps hide latency) Probe your read-set to see if previous writes have completed Validation is now complete – send the actual commit message to the write set

Example TID Vendor P1 P2 Rd X Wr X Rd Y Wr Z NS: 1 NS: 1 D: X Z D: Y

Example TID Vendor TID=2 P1 P2 Rd X Wr X TID=1 Rd Y Wr Z NS: 1 NS: 1 D: X Z D: Y

Example TID Vendor TID=2 P1 P2 TID=1 Rd X Wr X Rd Y Wr Z Probe to write-set to see if it can proceed No writes here. I’m done with you. NS: 1 NS: 3 D: X Z D: Y P2 sends the same set of probes/notifications

Example Must wait my turn Can go ahead with my wr TID Vendor TID=2 P1 Rd X Wr X Rd Y Wr Z Mark X NS: 1 NS: 3 D: X Z D: Y Mark messages are hiding the latency for the subsequent commit

Example Keep probing and waiting TID Vendor TID=1 TID=2 P1 P2 Rd X Wr X Rd Y Wr Z Probe read set and make sure they’re done NS: 1 NS: 3 D: X Z D: Y

Example Keep probing and waiting TID Vendor TID=1 TID=2 P1 P2 Rd X Wr X Rd Y Wr Z Commit NS: 2 Invalidate sharers; May cause aborts NS: 3 D: X Z D: Y

Example TID Vendor TID=1 TID=2 P1 P2 Rd X Wr X Rd Y Wr Z NS: 2 NS: 3 D: X Z D: Y P2: Probe finally successful. Can mark Z. Will then check read-set. Then proceed with commit

Algorithm Probe your write-set to see if it is your turn to write (helps serialize writes) Let others know that you don’t plan to write (thereby allowing parallel commits to unrelated directories) Mark your write-set (helps hide latency) Probe your read-set to see if previous writes have completed Validation is now complete – send the actual commit message to the write set

Issues The protocol requires many messages: enables latency hiding for the commit process, though There may be high directory locality for a NUMA machine, but possibly not for a single large-scale CMP with a directory-based cache coherence protocol To support a write-back cache policy, a new non-speculative cache is introduced (so that a transaction does not speculatively over-write a dirty line)

Evaluation

Results Applications with small transactions suffer more from commit latency

Results

Transaction Characteristics An evaluation of 35 multi-threaded programs Transaction length Sizes of read and write sets

Transaction Characteristics

Title Bullet