Abstract

Hardware Transactional Memory (HTM) had an inauspicious debut. Intel’s TSX shipped in Haswell in 2013, was disabled via microcode shortly after due to a correctness erratum, re-enabled in Broadwell, and then effectively abandoned as a reliable programming primitive after a series of errata and side-channel vulnerabilities, culminating in TSX being disabled by default in Linux from kernel 5.15 onward on affected CPUs. IBM’s POWER HTM survived longer in production and remains available on POWER10. Yet the underlying problem HTM was designed to solve - allowing concurrent threads to operate on shared data structures without coarse-grained locking, scaling throughput linearly with core count - has not gone away. As server core counts reach 96, 128, and beyond in 2025, the lock contention bottleneck HTM was meant to address is worse than ever, and the research literature is revisiting what a correctness-first HTM design would look like.

Why TSX Failed and What It Taught

TSX’s troubles were primarily in its abort semantics and capacity limits rather than the transactional concept itself. TSX used the L1 cache as the transactional buffer, meaning any transaction whose read or write set exceeded the L1 capacity would abort and fall back to a software path. For large data structures this fallback was frequent enough to eliminate the benefit. The errata that triggered disablement were corner cases in the interaction between TSX and the speculative execution pipeline, not fundamental to the transactional memory model. IBM’s implementation on POWER8 and later used a more conservative design with explicit transactional state visible to the architectural register file, making correctness easier to verify at the cost of implementation complexity. The POWER10 HTM supports transactions up to 4 KB in the L1 transactional region with a secondary software-assisted fallback, a design that has not suffered the same class of errata.

Current Research Directions

Two threads dominate the 2024-2025 HTM research literature. The first is conflict detection granularity. Traditional HTM detects conflicts at cache-line granularity (64 bytes), which causes false conflicts when two transactions touch different fields of a struct that happen to share a cache line. Word-granularity conflict detection, explored in the STMite and PhTM research prototypes, reduces false abort rates significantly on hash table and tree workloads. The second thread is lazy versioning. Eager versioning, as in TSX, updates the cache in place and logs undo data. Lazy versioning, as in the TL2 software STM and proposed in several hardware designs, buffers writes in a separate structure and applies them only on commit. Lazy versioning interacts better with deep cache hierarchies because aborts require no undo write-back, but it requires more buffering area.

Integration with Lock-Based Fallback

A persistent practical challenge is the transactional lock elision (TLE) pattern: a transaction tries to run optimistically under HTM, and falls back to acquiring a mutex on repeated aborts. This pattern, the basis of the glibc pthread mutex TLE integration that was briefly enabled for TSX, requires the hardware abort rate to be low enough that the optimistic path wins most of the time. On 128-core systems with true cache-coherent NUMA topologies, the coherence invalidation traffic during a transaction can trigger aborts even when there are no logical conflicts, a phenomenon called capacity-induced false aborts from coherence traffic. The 2025 research consensus is that HTM at this scale requires integration with the coherence protocol, allowing the transaction manager to suppress non-conflicting coherence invalidations rather than aborting on them.

Near-Term Prospects

Intel has not publicly committed to reviving HTM in future architectures post-TSX. IBM POWER10 remains the only production HTM widely available in 2025. The RISC-V T-extension proposal for transactional memory was under community discussion through 2024 but has not reached ratification. The most likely near-term deployment of HTM principles in commercial silicon may come through domain-specific uses: database systems like MemSQL (now SingleStore) and VoltDB that can confine transaction sizes to guarantee no capacity aborts, rather than as a general-purpose concurrency primitive.