1. KAUSHIK LAKSHMINARAYANAN MICHAEL ROZYCZKO VIVEK SESHADRI Transactional Memory: Hybrid Hardware/Software Approaches

2. Transactional Memory Lock-free data structures Atomic code sections  Abstraction – what instead of how Ideas from database community Means a lot to parallel programming

3. Hardware vs Software TM Hardware Transactional Memory (HTM)  Modify cache coherence protocol, ISA extensions  Best-effort (bounded resources)  Transactions cannot exceed processor resources  UTM (unbounded resources)  Supports large transactions – hard to realize Software Transactional Memory (STM)  Software bookkeeping  Overhead Hybrid Transactional Memory (?)  Combine benefits of both models

4. Hybrid TM Design Issues Naming Hardware support Software mechanism Policy ISA extensions Other issues

5. HyTM Overview HyTM  Peter Damron, Alexandra Fedorova, Yossi Lev, Victor Luchangco, Mark Moir and Daniel Nussbaum HyTM Library Best-effort HTM STM

6. Overview of Implementations II RTM  Arvindh Shriraman, Michael F. Spear, Hemayat Hossain, Virendra J. Marathe, Sandhya Dwarkadas and Michael L. Scott Application HTM Handler

7. Overview of Implementations III SigTM  Chi Chao Minh, Martin Trautmann, JaeWoong Chung, Austen McDonald, Nathan Bronson, Jared Casper, Christos Kozyrakis, Kunle Olukotun STM Hardware Bookkeeping (Signatures)

8. Hardware Support/Software Mechanisms HyTM  Does not assume any hardware support  Runs on existing HTM (if one exists)  Full-fledged STM library  Object records (for every word in memory) Meta-information about the state of the word  Handlers Conflict management Hardware/Software interface

9. Hardware Support/Software Mechanisms RTM  Cache coherence protocol modifications – TMESI  Additional registers (transaction metadata)  Application-specific handlers  Conflict detection  Aborted hardware transactions

10. Hardware Support/Software Mechanisms SigTM  Hardware signatures (bookkeeping)  Bloom filter  User-level configuration registers (policy)  Slight modification to cache coherence  Hardware check on signature hits  Software handlers to handle hits (based on policy)  Software write-set bookkeeping  Required to update on successful commit

11. Policy Upon conflict/eviction, something must be done to resolve the situation Conflict detection – write-read, write-write  When to do conflict detection? Eager/Lazy  What to do when conflict encountered? Which to abort. Retrying aborted transactions  Immediate retry vs. back off  HyTM – hardware vs. software transaction  SigTM – API policy management

12. RTM Policy RTM – flexible policy  Application-specific handlers  Speculative execution  Application can decide to allow read-write and write-write  Programmable Data Isolation (PDI)  Can configure exclusivity of data  Alert on Update (AOU)  Inform application when a conflict/eviction occurs

13. ISA extensions Hybrid TM generally use special instructions to interface compiler and TM hardware  Instructions to delimit beginning and ending of transactions (Most implementations)  Instructions to set application-specific handlers (RTM)  Instructions to check whether the hardware can read or write (HyTM)  Update the signatures of addresses (SigTM)

14. Other Issues False sharing  Cache lines – unwanted abort and retries Unnecessarily shared variables  Collecting statistics Memory allocation/Freeing  Malloc and free in aborted transactions Deadlocks  Issue with lock based mechanisms Strong isolation and ordering  Interaction with non-transactional writes

15. KAUSHIK LAKSHMINARAYANAN MICHAEL ROZYCZKO VIVEK SESHADRI Transactional Memory: Hybrid Hardware/Software Approaches