Speculation-based conflict resolution in hardware transactional memory

Abstract

Conflict management is a key design dimension of hardware transactional memory (HTM) systems, and the implementation of efficient mechanisms for detection and resolution becomes critical when conflicts are not a rare event. Current designs address this problem from two opposite perspectives, namely, lazy and eager schemes. While the former approach is based on an purely optimistic view that is not well-suited when conflicts become frequent, the latter results too pessimistic because resolves conflicts too conservatively, often limiting concurrency unnecessarily. In this paper, we present a hybrid, pseudo-optimistic scheme of conflict resolution for HTM systems that recaptures the concept of speculation to allow transactions to continue their execution past conflicting accesses. Simulation results show that our proposal is capable of combining the advantages of both classical approaches. For the STAMP transactional benchmarks, our hybrid scheme outperforms both eager and lazy systems with average reductions in execution time of 8 and 17%, respectively, and it decreases network traffic by another 17% compared to the eager policy.

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

“…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. However, most of these methods decouple conflict management from version management and do not exploit opportunities availed by the interplay between conflict management and version management.…”

Techniques to improve performance in requester-wins hardware transactional memory

“…Remote readers can now access lines in a nonconflicting manner and writers that are close to commit have a better chance of acquiring ownership over the write-set before being aborted by a remote reader. If resources are sufficient to buffer all store misses until commit, this technique allows for a form of lazy conflict detection (committer-wins) [Hammond et al 2004], which provides stronger forward progress guarantees and can enhance concurrency by allowing readers to commit before a conflicting writer [Shriraman and Dwarkadas 2009;Titos et al 2009;Tomić et al 2009]. However, unlike the latter lazy systems, in our scheme there is no notion of committer, because it is always possible for a transaction to abort after it has reached the commit instruction while it is draining its buffered store misses; but since transactions generally write only a few cache lines, the time required to drain the buffers is generally short and the requirements to buffer all store misses are not excessive.…”

Techniques to improve concurrency in hardware transactional memory

“…Remote readers can now access lines in a non-conflicting manner and writers that are close to commit have a better chance of acquiring ownership over the write-set before being aborted by a remote reader. If resources are sufficient to buffer all store misses until commit, this technique allows for a form of lazy conflict detection (committer-wins) [37], which provides stronger forward progress guarantees and can enhance concurrency by allowing readers to commit before a conflicting writer [77,82,85]. However, unlike the latter lazy systems, in our scheme there is no notion of committer, because it is always possible for a transaction to abort after it has reached the commit instruction while it is draining its buffered store misses; but since transactions generally write only a few cache lines, the time required to drain the buffers is generally short and the requirements to buffer all store misses are not excessive.…”