Robust architectural support for transactional memory in the power architecture

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 TM . 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.

Remote Transaction Commit: Centralizing Software Transactional Memory Commits

“…Orthogonal to STM, hardware transactional memory (HTM) is currently gaining traction as an alternative for efficiently managing transactions on the hardware level [3], [4]. However, all the released HTM architectures are best-effort (i.e.…”

“…Table 1 provides an analysis of NOrec's commit time ratio of the STAMP benchmarks [6] 3 . In this experiment, we measure the commit time as the sum of the time taken to acquire the lock and the time taken for executing the commit procedure itself.…”

“…Transactional memory is increasingly gaining traction: Intel has released a C++ compiler with STM support [2]; IBM [3] and Intel [4] have released commodity hardware processors integrating transactional memory features; and GCC has released programming language extensions to support STM [5].…”

Solutions to IBM POWER8 verification challenges

“…Additionally, a technique known as transactional lock elision (TLE) [8,9], whereby the thread whose transaction has failed obtains a software lock before attempting to execute the critical section of the transaction non-transactionally, was used to ensure forward progress can be achieved in test cases where the success rate falls below desirable levels. Without such controls, some tests could run indefinitely if each failed transaction was simply retried indefinitely as soon as the failure occurred.…”

Author's retrospective for

“…The closest systems to Hydra's TLS support that we have seen in shipping hardware are the transactional memory mechanisms available in a few chips such as the Intel Haswell [26] and IBM server chips [22,28], but these are too simple to provide full TLS-on-TM support like the kind proposed in our transactional memory papers. While the current hardware designs are capable of basic transactional memory techniques like lock elision, which converts small lock critical regions to transactional memory regions, they do not support the inter-transaction priority ordering mechanisms needed for TLS and are not really designed to scale up to transaction sizes consisting of hundreds or thousands of instructions per transaction, which is needed for TLS-like support.…”