An integrated hardware-software approach to flexible transactional memory

Abstract

There has been considerable recent interest in the support of transactional memory (TM) in both hardware and software. We present an intermediate approach, in which hardware is used to accelerate a TM implementation controlled fundamentally by software. Our hardware support reduces the overhead of common TM tasks, namely, conflict detection and data isolation, for bounded transactions. Software control allows policy flexibility for conflict detection, contention management, and data granularity, in addition to enabling transactions unbounded in space and time. Our hardware consists of 1) an alert-on-update mechanism for fast eventbased communication, used for software-controlled conflict detection; and 2) support for programmable data isolation, allowing multiple concurrent transactional readers and writers at the software's behest, along with fast data commit and abort support (using only a few cycles of completely local operation).Our results show that for common-case bounded transactions, the proposed hardware mechanisms eliminate data copying and dramatically reduce the overhead of bookkeeping and validation (resulting in a factor of 2 improvement in performance on average). Moreover, RTM shows good scalability as the number of threads is increased and graceful degradation in performance when transactions overflow available hardware support. Detecting conflicts eagerly (on first access) or lazily (at commit time), enabled by the ability to handle multiple concurrent transactional writers and readers, can result in differences in performance in either direction depending on the application access pattern (up to two orders of magnitude at 16 threads for one workload), demonstrating the need for policy flexibility.

Transactional Mutex Locks

“…Rather than implement TM entirely in hardware, several groups have proposed to use hardware to accelerate STM [3,14,18,19,24]. In a similar vein, hardware support substantially less ambitious than HTM could accelerate TML.…”

“…The Alert On Update (AOU) mechanism [19,24] is one example: when a specially marked cache line is evicted (indicating a remote write, so long as capacity and conflict evictions are avoided), the local processor immediately jumps to a handler that can either (a) validate the transaction, re-mark the line, and continue, or (b) roll back and restart.…”

Transactional memory

“…Programmable data isolation (PDI). PDI, first introduced in RTM [93], is a lazy version management mechanism, that enables software to perform speculative and incoherent stores to local caches. 4.…”

“…Alert-on-update (AOU). AOU, also first introduced in RTM [93], is a mechanism that allows software to mark specific cache lines. When a coherence request (invalidation) arrives for a marked cache line, a software handler is triggered and executed.…”

Verifying Safety and Liveness for the FlexTM Hybrid Transactional Memory

“…Otherwise, the transaction is aborted and may be restarted if needed. The concurrent transactions run on top of an underlying Transactional Memory (hardware [1]- [5], software [6]- [10], or hybrid [11]- [14]) infrastructure that maintains the atomicity illusion.…”