MTASet: Atomic Range Queries in Concurrent Trees

• MTASet is a concurrent (a,b)-tree-based set that supports update-heavy workloads while providing efficient atomic range queries.
• It employs lock-free search, multi-version coordination via a global version counter, and deferred structural cleanup for optimal performance.
• Empirical evaluations show that MTASet outperforms alternatives like KiWi and SnapTree under mixed workloads, delivering up to 5x scan speed improvements.

Searching arXiv for "MTASet" and closely related records to ground the article. MTASet is a concurrent set/dictionary designed specifically to handle update-heavy workloads while still supporting atomic range queries efficiently. Introduced as a tree-based set built on a concurrent $(a,b)$-tree, specifically inspired by the OCC-ABtree, it combines lock-free search where possible, multi-version atomic scans, and deferred structural cleanup through rebalancing. Its stated purpose is to bridge the gap between read-optimized concurrent sets, which often degrade under many inserts and deletes, and update-optimized structures, which typically do not natively provide efficient atomic scans. The defining correctness property is linearizability (Manor et al., 26 Jul 2025).

1. Design objective and workload model

The problem addressed by MTASet is the mismatch between high-throughput concurrent updates and efficient linearizable or atomic range queries in a single shared set structure. The motivating observation is that many concurrent sets fall into two classes: read-optimized structures that perform well on finds and scans but poorly under heavy update pressure, and update-optimized structures that scale well for inserts and deletes but either do not support range queries well or support them with high overhead. MTASet is intended to bridge that gap.

The design target is therefore not pure scan throughput in isolation, but mixed settings in which scans and updates overlap. In this setting, the central difficulty is that a range query must observe a consistent snapshot across many keys while other threads continue to update the set. The paper frames this as a coordination problem across multiple nodes and versions, one that becomes especially costly in update-heavy workloads.

This emphasis explains the paper’s comparative positioning. KiWi is described as very strong for scans but not optimized for fast updates; SnapTree has decent update performance but expensive scans; the general range-query technique for OCC-ABtree is reported as slower than the approach used in MTASet; and Java ConcurrentSkipListMap provides non-atomic scans and is not competitive in the atomic range-query setting. The intended operating point for MTASet is therefore a concurrent index in which range queries matter, but update throughput cannot be sacrificed (Manor et al., 26 Jul 2025).

2. Structural organization

MTASet is based on a concurrent $(a,b)$-tree in which each node has between $a$ and $b$ children and satisfies

$a \le \frac{b}{2}.$

The implementation is leaf-oriented and inherits the relaxed balancing philosophy of the OCC-ABtree. Rather than preserving a perfectly balanced structure on every operation, it prioritizes fast client operations and defers structural optimization to maintenance procedures.

Three node types are used.

Node type	Role	Salient properties
Leaf node	Stores key/value data	Unordered key array, empty slots as $\bot$, versioned values, doubly linked via left and right
Internal node	Routes searches	Sorted routing keys, child pointers updated infrequently
Tagged internal node	Represents temporary imbalance after split	Exactly two children, later removed by fixTagged

Leaf nodes are the core of both update and scan performance. Keys are stored in an unordered array, values are versioned, and leaves are linked in a doubly linked list so that scans can traverse leaves directly instead of repeatedly descending from the root. Each leaf also carries a version field with an odd/even convention: an even version means the leaf is stable or not being modified, and an odd version means the leaf is being modified. This versioning is central to concurrent search validation.

Two shared coordination structures complement the tree. The Global Version, denoted GV, is a global counter used to assign logical timestamps to updates and scans. The Ongoing Scans Array, denoted OSA, records active scans and their versions. Together they provide the multi-version substrate required for atomic range queries without forcing all scans to serialize with updates (Manor et al., 26 Jul 2025).

3. Search, update, and scan algorithms

Each operation begins with tree navigation. The helper search returns a PathInfo structure containing the grandparent, parent, current node, parent index, and current node index. The helper searchLeaf then validates the target leaf through a versioned double-collect protocol: read leaf version $ver_1$, retry if $ver_1$ is odd, read the relevant key or value, read leaf version $ver_2$, and retry if $ver_1 \ne ver_2$. This yields a lock-free search path with explicit interference detection.

Insertion is case-based. If the key already exists with a live value, the operation returns the existing value. If the key exists but is logically deleted, or the operation is an update of a logically deleted key, the versioned value is updated in place. If the leaf has room, the key is inserted directly into an empty slot using insertKey. If the leaf is full, the algorithm first calls cleanObsoleteKeys to physically remove logically deleted keys if this is safe. If that creates space, insertion proceeds and may be followed by fixUnderfull; otherwise the leaf is split by creating a tagged internal node, which is later removed by fixTagged.

Deletion is defined as

$(a,b)$0

This means deletion is logical first: the latest value becomes $(a,b)$1, while physical removal is deferred until no active scan can still require the deleted version.

The scan procedure is the main algorithmic contribution. A scan $(a,b)$2 atomically fetches and increments GV, publishes its scan version into the OSA, searches for the leaf containing lowKey, traverses leaves through the linked list, and in each leaf collects values whose keys lie in $(a,b)$3, whose value versions are at most the scan version, and whose value is not $(a,b)$4. Collected items are sorted by key inside each leaf and appended to the result, and the scan terminates when a key exceeds highKey or no more relevant leaves remain. The scan is intended to be wait-free.

The key correctness rule for scans is that a scan with version $(a,b)$5 returns the latest value of each key whose version is at most $(a,b)$6. The linearization point is tied to the condition

$(a,b)$7

so that any operation linearized after that point necessarily receives a larger version and therefore must not appear in the scan result. This is the mechanism by which atomic range queries are obtained in the presence of ongoing updates (Manor et al., 26 Jul 2025).

4. Multi-version coordination, helping, and maintenance

MTASet relies on two forms of helping to close races between scans, updates, and cleanup.

A scan may encounter a value that has no version yet. In that case, the scan helps the update by assigning a version via CAS from the global version. This avoids the case in which an update has already written a key or value but has not yet completed version assignment, which could otherwise allow a scan to miss an update that should belong to its logical snapshot.

Conversely, cleanObsoleteKeys may encounter a scan in the OSA without an assigned version. It helps by assigning one. This prevents races between scan publication and cleanup or compaction logic that depends on version visibility.

Maintenance is intentionally decoupled from the common-case client path. The relevant procedures are fixTagged, which removes temporary tagged nodes created after splits; fixUnderfull, which repairs underfull nodes through redistribution or merging; and cleanObsoleteKeys, which physically removes logically deleted entries when this is safe with respect to all active scans.

The safety condition for physical removal is stated explicitly. The algorithm computes

$(a,b)$8

and a logically deleted key can be physically removed only if

$(a,b)$9

for that key. The intended interpretation is direct: no active scan can still need that version. This maintenance strategy is consistent with the paper’s general philosophy of handling client operations quickly and deferring structural optimization to occasional rebalancing (Manor et al., 26 Jul 2025).

5. Correctness properties and linearizability

The paper proves that MTASet is linearizable, meaning that each operation appears to take effect atomically at some instant between invocation and return. The proof is supported by a collection of structural invariants. Among the listed invariants are that all reachable nodes form a relaxed $a$0-tree; the key range of a removed reachable node remains constant; an unreachable node retains the same keys and values it held when last reachable and unlocked; each key appears only once in a leaf; if a node was once reachable and is unmarked, it remains reachable; leaf nodes being split or merged do not create duplicate scan paths; linked leaf adjacency is stable once a node is unlinked; and search is always performed within the correct key range.

The linearizability argument is operation-specific. A find(k) is linearized when the leaf read during searchLeaf corresponds to a stable moment in which the key is found with a non-$a$1 value, or is absent or logically deleted in a stable view. The double-check on the leaf version is what ensures that the observation is consistent.

Insert operations have several possible linearization points: when the operation discovers the key already present; when it holds the leaf lock and observes a stable existing value; when it writes the key and assigns a version in a non-full leaf; when it updates a logically deleted key; or when it writes the new subtree pointer into the parent during a split insertion. Delete follows the same logic because it is implemented as logical insertion of $a$2.

For scans, linearization is tied to the moment when the assigned version becomes sealed by the global version advancing beyond it, namely when $a$3. The proof then argues that any key inserted or deleted after that point must have a larger version and therefore will not be included. The linked-leaf traversal remains correct under rebalancing because an unlinked leaf can still be traversed to its neighbor, keys moved by underfull repair were already removed before the scan’s linearization, and keys created by a split were inserted after the scan linearized. In the paper’s presentation, this makes atomic range queries compatible with concurrent structural changes rather than requiring scans to stop the world (Manor et al., 26 Jul 2025).

6. Evaluation, performance profile, and scope of the name

The experimental setup uses an Azure VM Standard_D96ads_v5 with an AMD EPYC 7763 64-Core CPU, 96 vCPUs, 384 GB RAM, Ubuntu 20.04.2 LTS, and a Java implementation. For both MTASet and OCC-ABtree, the parameters are

$a$4

Each experiment seeds the structure with random keys and values until half of the key range is full, starts 80 threads, uses $a$5 scan threads and $a$6 non-scan threads, runs the measured phase for 10 seconds, and repeats 10 times with averages reported.

The workloads are: 100% scans; scans with parallel updates; get-only; 80% inserts with deletes; 100% inserts; and 90% gets, 9% inserts, 1% deletes. The baselines are OCC-ABtree* with range-scan support added using the general technique from Arbel-Raviv and Brown, OCC-ABtree without range-query support, KiWi, and Java ConcurrentSkipListMap or ConcurrentSkipList.

The reported performance profile is deliberately non-universal. In 100% scans, KiWi is best, which the paper describes as expected because it is scan-optimized. In scans with concurrent updates, MTASet’s scan throughput significantly outperforms OCC-ABtree*; one description states that the improvement is nearly fivefold, the abstract states that MTASet can surpass prior counterparts optimized for range query operations by up to 2x, and the discussion also reports gains of up to 3x in some long-scan-with-updates scenarios. In the 80% insert/delete workload, MTASet and OCC-ABtree without scan support are the fastest, and MTASet’s throughput is about 4x KiWi. In 100% inserts, OCC-ABtree performs best, but MTASet is close. In the mixed 90% get, 9% insert, 1% delete workload, MTASet is comparable to OCC-ABtree* and much faster than KiWi and ConcurrentSkipListMap. The paper also reports that MTASet’s atomic scans are 1.6x faster than the non-atomic scans of Java’s ConcurrentSkipList and that its updates are up to 3.6x faster.

These results define the intended interpretation of the data structure. MTASet is not presented as the fastest structure for pure scans, nor as uniformly superior in every update-only regime. Its claim is narrower and more technical: atomic range queries can be made practical in update-heavy workloads without abandoning the update-oriented design principles of a relaxed concurrent $a$7-tree.

The name “MTASet” also appears in unrelated technical contexts. In measurement-to-track association and finite-set statistics, an “MTASet” can refer to the association set $a$8 or $a$9, namely the set of valid measurement-to-track assignments (Mahler, 2017). In multi-task averaging, the query term is not defined as a distinct mathematical object and is best understood as the set of $b$0 independent sample collections $b$1 to which MTA is applied (Feldman et al., 2011). In random finite set tracking, the term is used for a formulation in which the random variable of interest is a set of trajectories rather than only current target states (García-Fernández et al., 2016). A separate accelerator-physics usage concerns the Fermilab MTA beam line, where “MTA” denotes the measurement platform rather than a concurrent set abstraction (Johnstone, 2012). In current usage, however, the capitalized title “MTASet” primarily denotes the concurrent $b$2-tree with efficient atomic range queries introduced in 2025 (Manor et al., 26 Jul 2025).