Multiverse: Transactional Memory with Dynamic Multiversioning

Software transactional memory (STM) allows programmers to easily implement concurrent data structures. STMs simplify atomicity. Recent STMs can achieve good performance for some workloads but they have some limitations. In particular, STMs typically cannot support long-running reads which access a large number of addresses that are frequently updated. Multiversioning is a common approach used to support this type of workload. However, multiversioning is often expensive and can reduce the performance of transactions where versioning is not necessary. In this work we present Multiverse, a new STM that combines the best of both unversioned TM and multiversioning. Multiverse features versioned and unversioned transactions which can execute concurrently. A main goal of Multiverse is to ensure that unversioned transactions achieve performance comparable to the state of the art unversioned STM while still supporting fast versioned transactions needed to enable long running reads. We implement Multiverse and compare it against several STMs. Our experiments demonstrate that Multiverse achieves comparable or better performance for common case workloads where there are no long running reads. For workloads with long running reads and frequent updates Multiverse significantly outperforms existing STMS. In several cases for these workloads the throughput of Multiverse is several orders of magnitude faster than other STMs.

💡 Research Summary

Multiverse is an opaque software transactional memory (STM) system that unifies the low‑overhead path of traditional single‑version STM with the long‑read‑only support of multiversion concurrency control (MVCC). The key idea is to allow both “unversioned” and “versioned” transactions to coexist, and to let the system dynamically decide which addresses should carry version lists. Unversioned transactions follow a DCTL‑style design: they read a global clock, validate lock versions against a read‑clock, and use encounter‑time locking for writes. If a write touches a versioned address, the corresponding version list is updated, but otherwise the transaction proceeds without any version‑related bookkeeping.

Versioned transactions are read‑only and obtain a snapshot timestamp from the global clock. For each read they check a Bloom filter to see whether the address is versioned; if so they traverse the per‑address version list to locate the appropriate version. Two global modes control how addresses become versioned. In Mode Q, versioned transactions are responsible for marking addresses as versioned; unversioned transactions are largely oblivious, aborting if they encounter an unversioned address that has changed. In Mode U, the opposite holds: writers mark addresses as versioned, allowing versioned readers to assume all relevant addresses are already versioned. The system switches between these modes (and transient intermediate modes) based on a heuristic that monitors abort counts, recent transaction behavior, and overall contention.

Address versioning is performed at word granularity. Version lists and versioned locks are stored in hash‑based tables (Version List Table and lock table) so that the program’s memory layout is untouched. Bloom filters accelerate the “is this address versioned?” check, and unversioning is done per bucket to keep bucket lengths short and to reset Bloom filters efficiently. A background thread periodically reclaims version lists using epoch‑based reclamation, guided by timestamps collected from versioned transactions.

The authors evaluate Multiverse against several opaque STMs (including DCTL, TL2, and other multiversioned prototypes) on a variety of benchmarks such as (a,b)-tree, skip‑list, and queue workloads. Results show that on workloads without long‑running reads Multiverse matches or exceeds the throughput of the best unversioned STM. On workloads that combine large read‑only range queries with frequent updates, Multiverse outperforms existing STMs by orders of magnitude, demonstrating that the dynamic multiversioning overhead is incurred only when needed.

In summary, Multiverse contributes a novel dynamic multiversioning mechanism, a dual‑mode operation that adapts to workload characteristics, and an implementation that preserves the cache‑friendly behavior of unversioned STM while providing opaque MVCC for long‑running reads. This work pushes the practical performance envelope of STM systems, making them viable for a broader class of concurrent applications.