An Object-Aware Hardware Transactional Memory System

Abstract

Transactional Memory (TM) is receiving attention as a way of expressing parallelism for programming multi-core systems. As a parallel programming model it is able to avoid the complexity of conventional locking. TM can enable multi-core hardware that dispenses with conventional bus-based cache coherence, resulting in simpler and more extensible systems. This is increasingly important as we move into the many-core era. Within TM, however, the processes of conflict detection and committing still require synchronization and the broadcast of data. By increasing the granularity of when synchronization is required, the demands on communication are reduced. Software implementations of TM have taken advantage of the fact that the object structure of data can be employed to further raise the level at which interference is observed. The contribution of this paper is the first hardware TM approach where the object structure is recognized and harnessed. This leads to novel commit and conflict detection mechanisms, and also to an elegant solution to the virtualization of version management, without the need for additional software TM support. A first implementation of the proposed hardware TM system is simulated. The initial evaluation is conducted with three benchmarks derived from the STAMP suite and a transactional version of Lee's routing algorithm.

SABRes: Atomic object reads for in-memory rack-scale computing

“…The hardware simplicity of LightSABRes stems from the insight that objects in data stores are structured, and this software-provided guarantee can be harnessed. A similar observation has been made and leveraged before in the context of HTM: object-aware HTM relies on the organization of data as software objects to tackle the capacity limitations of traditional HTM [24].…”

An integrated pseudo-associativity and relaxed-order approach to hardware transactional memory

“…There is a rich body of research on minimizing these overheads. For example, while TCC, UTM, VTM, LogTM, PTM, XTM, RTM, Scalable-TCC, ObjectTM, FasTM, Reconfigurable-TM, SEL-TM and SUV-TM [Hammond et al 2004]; [Ananian et al 2005]; [Rajwar et al 2005]; [Moore et al 2006]; [Chuang et al 2006]; [Chung et al 2006b]; [Shriraman et al 2007]; [Chafi et al 2007]; [Khan et al 2008]; [Lupon et al 2008] [Lupon et al 2009]; [Armejach et al 2011]; [Zhao et al 2012]; [Yan et al 2012] focus on reducing static overheads on version management, OneTM, DATM, SBCRHTM, ProactiveTM, EasyTM, DynTM, SON-TM, BFGTS-TM, 42:6 Z. Yan et al and ZEBRA [Blundell et al 2007]; [Ramadan et al 2008]; [Titos et al 2009]; [Blake et al 2009]; [Tomic et al 2009]; [Lupon et al 2010]; [Aydonat and Abdelrahman 2010]; [Blake et al 2011]; propose different TM architectures to alleviate the dynamic overheads incurred by transactional conflicts.…”

Scalable Object-Aware Hardware Transactional Memory

“…Previous work [4] has explored an approach to transactional memory that recognises the structure of objects at the hardware level. It argued that such an approach reduces the problems associated with overflow in lazy evaluated TM systems, and that communicating using a concise object representation can cut the bandwidth requirements.…”

“…To address the limitations of previously proposed object-based hardware transactional memory (HTM) system [4] [3], this paper presents a protocol capable of maintaining transactional execution over a scalable memory architecture. This section presents the SO protocol, which no longer relies on a network that supports atomic broadcasts but rather is extendible to function on any scalable network architecture.…”