1. Transactional Memory (TM) Evan Jolley EE 6633 December 7, 2012

2. Agenda  Reason for Transactional Memory  Basics of Transactional Memory  Types of Transactional Memory  Software Transactional Memory (STM)  Hardware Transactional Memory (HTM)  Hybrid Transactional Memory  Transactional Memory Designs  LogTM-SE with software defined conflicts  SigTM  Conclusions

3. Why Transactional Memory? In the multicore era programs must be written that are highly parallel Need improved mechanism for programmers to write parallel code for simplicity and efficiency A main concern in parallel programs is concurrent accesses to shared memory by multiple thread The current method is the use of locks to protect such access Coarse grain locks suffer from scaling issues Fine grain locks can cause unnecessary data races or introduce deadlocks Locks also suffer overhead problems PROBLEM: SOLUTION: Create a lock-free concurrent memory access model: Transactional Memory

4. Basics of Transactional Memory (1/3) Transaction – group of memory instructions that executes as if it is the only operation accessing its memory locations It can either: 1.Commit – memory instructions complete and are committed to shared memory such that they are visible to all other threads/processors 2.Abort – all executed instructions in the transaction are “rolled back” and the memory is restored to its previous state Conflict – occurs when two transaction operate on same portion of memory and at least one of them is writing Idea of transactional programming comes from the database community Moves responsibility of memory access synchronization from the programmer to the transactional memory system

5. Basics of Transactional Memory (2/3) In order to provide the necessary atomicity and isolation, two key factors must be considered: 1) When is the data being operated on changed? (data versioning)  Eager – replace memory values with transactional values while storing old values in a log for “roll back” if a transaction is aborted  Lazy – buffer transactional data until transaction commits successfully when all values are placed into memory Transactional Memory requires: Failure Atomicity – if any of the instructions in a transaction fail, the transaction fails Isolation – operates as though all other processes/threads are suspended

6. 2) When are conflicts detected/resolved? (conflict detection/resolution)  Eager – detect/resolve conflict as soon as it occurs (typically when transaction is opened)  Lazy – wait to check for and resolve conflict upon commit Basics of Transactional Memory (3/3) Other design factors include: conflict detection granularity, operation of nested transactions, and contention management References: 1.A. Adl-Tabatabai, C. Kozyrakis, and B. Saha, “Unlocking Concurrency,” In Queue, vol. 4, no. 10, pp. 24-33, December 2006. 2.J. Larus and R. Rajwar, Synthesis Lectures on Computer Architecture: Transactional Memory. First Edition. Morgan & Claypool Publishers, January 12, 2007. 3.J. Larus and C. Kozyrakis, “Transactional Memory,” In Communications of the ACM, vol. 51, no. 7, pp. 80-88, July 2008. Another property is the isolation between transactional and non-transactional operations. Strong isolation is preferred as it completely isolates transactional and non-transactional code.

7. Types of Transactional Memory 1.Software Transactional Memory (STM) – Implements TM system on current unmodified hardware using software instrumentation instructions that are responsible for data versioning and conflict detection 2.Hardware Transactional Memory (HTM) – Implements TM system using new hardware constructs (and sometimes ISA modifications) to track data versions and detect conflicts 3.Hybrid Transactional Memory – Use a combined hardware and software approach for executing transactions

8. Transactional Memory Designs Design presented in: R. Titos-Gil, M E. Acacio, J. M. Garcia, T. Harris, A. Cristal, O. Unsal, I. Hur, and M. Valero, “Hardware Transactional Memory with Software-Defined Conflicts,” In TRANSACT 2010, pp. 1-8, April 2010. -Utilizes software defined blocks to determine which inter-transaction conflicts to detect during execution of current transaction as certain conflicts are not needed for different applications -decreases number of unnecessary transaction aborts -increases scalability -Implemented using the LogTM-SE presented in HPCA 2007 by L. Yen, et al.

9. Transactional Memory Designs LogTM-SE -hardware signatures for read and write-sets -log structure to hold previous state for rolling back an aborted transaction -eager data versioning -eager conflict detection References: L. Yen, J. Bobba, M. R. Marty, K. E. Moore, H. Volos, M. D. Hill, M. M. Swift, and D. A. Wood, “LogTM-SE: Decoupling Hardware Transactional Memory from Caches, “ In HPCA '07 Proceedings of the 2007 IEEE 13th International Symposium on High Performance Computer Architecture, pp. 261-272, 2007.

10. Transactional Memory Designs

12. Design presented in: C. C. Minh, M. Trautmann, J. Chung, A. Mcdonald, N. Bronson, J. Casper, C. Kozyrakis, and K. Olukotun, “An Effective Hybrid Transactional Memory System with Strong Isolation Guarantees,” In ISCA '07 Proceedings of the 34th Annual International Symposium on Computer Architecture, pp. 69-80, June 2007. -Implements read and write set hardware signatures for conflict detection -Guarantees strong isolation by looking up coherence requests in the hardware signatures -Attempts to reduce overhead of conventional STM while still exploiting the flexibility of such an implementation -Attempts to keep extra hardware overhead low (just adds bits for hardware signatures)

13. Transactional Memory Designs

17. Conclusion Transactional Memory provides lock free data structures for execution of shared memory (parallel) programs Transactional Memory lessons the burden of the programmer for programming parallel workloads safely Transactional memory guarantees that execution will occur atomically and in isolation Hybrid methods can be used to exploit the positive features of both hardware transactional memory (strong isolation and low runtime overhead) and software flexibility (unlimited transaction size and limited hardware complexity) IBM has implemented Transactional Memory systems into the Blue Gene/Q processors and Intel will release their Haswell CPUs in 2013 that include Transactional Memory References: 1.R. Haring, et al., “The IBM Blue Gene/Q Compute Chip,” In IEEE Micro, vol. 32, no. 2, pp. 48-60, 2012. 2.http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell

18. Questions ??