Multiverse: Transactional Memory with Dynamic Multiversioning

TL;DR

Multiverse tackles the challenge of supporting long-running reads in software transactional memory by introducing an opaque STM that blends unversioned execution with dynamic multiversioning. It achieves this through word-level dynamic versioning, a Version List Table, and two global TM modes (Mode Q for on-demand versioning and Mode U for global versioning) with transient transitions managed by a background thread. The key contributions include a dual-path architecture with selective MVCC, a robust correctness argument via opacity-based validation, and a memory-management scheme using epoch-based reclamation. Empirically, Multiverse matches the best unversioned STMs on common workloads and substantially outperforms them on workloads with long-running reads, sometimes by orders of magnitude, enabling efficient, scalable transactional memory in realistic settings.

Abstract

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.

Figures (21)

• Figure 1: (a,b)-tree benchmark with an 89.99% search, 0.01% RQ, 5% insert, 5% delete workload using a uniform key access pattern. RQ size is 10k (1% of prefill size). Y-axis is ops/sec. X-axis is number of threads.
• Figure 2: Data structures used in Multiverse. In this example addresses $a_1$ and $a_2$ map to the first VLT bucket but only $a_1$ is versioned. The orange arrows indicate a mapping while the black arrows indicate a memory pointer. The dotted arrow from the bloom filter to the VLT is indicating that we access the bloom filter first before the VLT.
• Figure 3: Example execution where Mode Q is not suitable. All addresses are initially unversioned. The versioned transaction T1 needs to read addresses $a_1$ to $a_n$ but it must perform $O(n^2)$ accesses to commit as a result of aborts caused by conflicts with the concurrent unversioned transaction. T1 would perform only $n$ accesses if the addresses were already versioned.
• Figure 4: Example execution with the same transactions from \ref{['fig:mode1-bad-exec']} but now the TM is in Mode U forcing the unversioned transaction to version each address it updates. The versioned transaction commits without any aborts.
• Figure 5: State transition diagram of the TM mode.