Harold W. Cain
ABSTRACT
On the twentieth anniversary of the original publication [10], following ten years of intense activity in the research literature, hardware support for transactional memory (TM) has finally become a commercial reality, with HTM-enabled chips currently or soon-to-be available from many hardware vendors. In this paper we describe architectural support for TM added to a future version of the Power ISA™. Two imperatives drove the development: the desire to complement our weakly-consistent memory model with a more friendly interface to simplify the development and porting of multithreaded applications, and the need for robustness beyond that of some early implementations. In the process of commercializing the feature, we had to resolve some previously unexplored interactions between TM and existing features of the ISA, for example translation shootdown, interrupt handling, atomic read-modify-write primitives, and our weakly consistent memory model. We describe these interactions, the overall architecture, and discuss the motivation and rationale for our choices of architectural semantics, beyond what is typically found in reference manuals.
- ARM Arch. Reference Manual. ARM Ltd., 2005.Google Scholar
- L. Baugh and C. Zilles. An analysis of I/O and syscalls in critical sections and their implications for transactional memory. In Proc. of the 2008 Intl. Symp. on Performance Analysis of Systems and Software. Google ScholarDigital Library
- C. Blundell, E. C. Lewis, and M. M. K. Martin. Unrestricted transactional memory: Supporting I/O and system calls within transactions. Technical Report CIS-06-09, Department of Computer and Information Science, University of Pennsylvania, Apr 2006.Google Scholar
- H.-J. Boehm and S. V. Adve. Foundations of the C++ concurrency memory model. In Proc. of the 2008 Conf. on Programming language design and implementation, 2008. Google ScholarDigital Library
- J. Chung, C. C. Minh, A. McDonald, T. Skare, H. Chafi, B. D. Carlstrom, C. Kozyrakis, and K. Olukotun. Tradeoffs in transactional memory virtualization. In Proc. of the 12th Intl. Conf. on Architectural Support for Programming Languages and Operating Systems, 2006. Google ScholarDigital Library
- W. W. Collier. Reasoning about parallel architectures. Prentice-Hall, Inc., 1992. Google ScholarDigital Library
- D. Dice, Y. Lev, M. Moir, and D. Nussbaum. Early experience with a commercial hardware transactional memory implementation. In Proc. of the 14th Intl. Conference on Architectural Support for Programming Languages and Operating Systems, 2009. Google ScholarDigital Library
- L. Hammond, V. Wong, M. Chen, B. D. Carlstrom, J. D. Davis, B. Hertzberg, M. K. Prabhu, H. Wijaya, C. Kozyrakis, and K. Olukotun. Transactional memory coherence and consistency. In Proc. of the 31st Intl. Symp. on Computer Architecture. Jun 2004. Google ScholarDigital Library
- T. Harris. Exceptions and side-effects in atomic blocks. Sci. Comput. Program., 58(3), Dec. 2005. Google ScholarDigital Library
- M. Herlihy and J. E. B. Moss. Transactional memory: architectural support for lock-free data structures. In Proc. of the 20th Intl. Symp. on Computer Architecture, 1993. Google ScholarDigital Library
- O. S. Hofmann, D. E. Porter, C. J. Rossbach, H. E. Ramadan, and E. Witchel. Solving difficult HTM problems without difficult hardware. In TRANSACT '07: 2nd Workshop on Transactional Computing, August 2007.Google Scholar
- IBM Corporation. Power Instruction Set Architecture v.2.06B, July 2010.Google Scholar
- Intel Corporation. Intel IA-64 Architecture Software Developers Manua l, Volume 2: IA-64 System Architecture, Revision 1.1, July 2000.Google Scholar
- Intel Corporation. Intel 64 and IA-32 Architectures Software Developer's Manual, August 2012.Google Scholar
- Intel Corporation. Intel Architecture Instruction Set Extensions Programming Reference: Chapter 8: Intel Transactional Synchronization Extensions, Feb. 2012.Google Scholar
- C. Jacobi, T. Slegel, and D. Greiner. Transactional memory architecture and implementation for IBM System z. In Proc. of the 45th Intl. Symposium on Microarchitecture, December 2012. Google ScholarDigital Library
- M. M. K. Martin, C. Blundell, and E. Lewis. Subtleties of transactional memory atomicity semantics. Computer Architecture Letters, 5(2), 2006. Google ScholarDigital Library
- A. McDonald, J. Chung, B. D. Carlstrom, C. C. Minh, H. Chafi, C. Kozyrakis, and K. Olukotun. Architectural semantics for practical transactional memory. In Proc. of the 33rd Intl. Symposium on Computer Architecture, 2006. Google ScholarDigital Library
- M. Moir, K. Moore, and D. Nussbaum. The adaptive transactional memory test platform: A tool for experimenting with transactional code for Rock. In TRANSACT '08: 3rd Workshop on Transactional Computing, February 2008.Google ScholarDigital Library
- M. J. Moravan, J. Bobba, K. E. Moore, L. Yen, M. D. Hill, B. Liblit, M. M. Swift, and D. A. Wood. Supporting nested transactional memory in LogTM. In Proc. of the 12th Intl. Conf. on Architectural support for programming languages and operating systems, 2006. Google ScholarDigital Library
- T. Nakaike and M. M. Michael. Lock elision for read-only critical sections in java. In Proc. of the 2010 Conf. on Programming Language Design and Implementation. Google ScholarDigital Library
- N. Neelakantam, R. Rajwar, S. Srinivas, U. Srinivasan, and C. Zilles. Hardware atomicity for reliable software speculation. In Proc. of the 34th Intl. Symposium on Computer Architecture, 2007. Google ScholarDigital Library
- S. J. Patel and S. S. Lumetta. rePLay: A hardware framework for dynamic optimization. IEEE Transactions on Computer Systems, 50(6), June 2001. Google ScholarDigital Library
- R. Rajwar and J. R. Goodman. Speculative lock elision: enabling highly concurrent multi-threaded execution. In Proc. of the 34th Intl. Symposium on Microarchitecture, 2001. Google ScholarDigital Library
- R. Rajwar, M. Herlihy, and K. Lai. Virtualizing transactional memory. In Proc. of the 32nd Intl. Symp. on Computer Architecture, 2005. Google ScholarDigital Library
- S. Sarkar, K. Memarian, S. Owens, M. Batty, P. Sewell, L. Maranget, J. Alglave, and D. Williams. Synchronising C/C++ and POWER. In Proc. of the 33rd Conf. on Programming Language Design and Implementation, 2012. Google ScholarDigital Library
- S. Sarkar, P. Sewell, J. Alglave, L. Maranget, and D. Williams. Understanding POWER multiprocessors. In Proc. of the 32nd Conf. on Programming Language Design and Implementation, 2011. Google ScholarDigital Library
- L. Su and M. H. Lipasti. Speculative optimization using hardware-monitored guarded regions for java virtual machines. In Proc. of the 3rd Intl. Conf. on Virtual execution environments, 2007. Google ScholarDigital Library
- D. L. Weaver and T. Germond, editors. SPARC Architecture Manual V9). PTR Prentice Hall, 1994.Google Scholar
- C. Zilles and L. Baugh. Extending hardware transactional memory to support nonbusy waiting and nontransactional actions. In Proc. of the First Workshop on Languages, Compilers, and Hardware Support for Transactional Computing. June 2006.Google Scholar
Recommendations
Robust architectural support for transactional memory in the power architecture
ICSA '13On the twentieth anniversary of the original publication [10], following ten years of intense activity in the research literature, hardware support for transactional memory (TM) has finally become a commercial reality, with HTM-enabled chips currently ...
Architectural Support for Software Transactional Memory
MICRO 39: Proceedings of the 39th Annual IEEE/ACM International Symposium on MicroarchitectureTransactional memory provides a concurrency control mechanism that avoids many of the pitfalls of lock-based synchronization. Researchers have proposed several different implementations of transactional memory, broadly classified into software ...
Operation-Level Wait-Free Transactional Memory with Support for Irrevocable Operations
Transactional memory (TM) aims to be a general purpose concurrency mechanism. However, operations which cause side-effects cannot be easily managed by a TM system, in which transactions are executed optimistically. In particular, networking, I/O, and some ...
Comments