Scalable Concurrent Containers
A collection of high performance concurrent container data structures and utilities for asynchronous and concurrent programming.
- EBR implements epoch-based reclamation.
- LinkedList is a type trait implementing a wait-free concurrent singly linked list.
- HashMap is a concurrent hash map.
- HashSet is a concurrent hash set based on HashMap.
- HashIndex is a read-optimized concurrent hash index.
- TreeIndex is a read-optimized concurrent B+ tree.
See Performance for benchmark results for the container data structures and comparison with other concurrent hash maps.
EBR
The ebr module implements epoch-based reclamation and various types of auxiliary data structures to make use of it. Its epoch-based reclamation algorithm is similar to that implemented in crossbeam_epoch, however users may find it easier to use as the lifetime of an instance is safely managed. For instance, ebr::AtomicArc and ebr::Arc hold a strong reference to the underlying instance, and the instance is automatically passed to the garbage collector when the reference count drops to zero.
Examples
The ebr module can be used without an unsafe block.
use ;
use Relaxed;
// `atomic_arc` holds a strong reference to `17`.
let atomic_arc: = new;
// `barrier` prevents the garbage collector from dropping reachable instances.
let barrier: Barrier = new;
// `ptr` cannot outlive `barrier`.
let mut ptr: = atomic_arc.load;
assert_eq!;
// `atomic_arc` can be tagged.
atomic_arc.update_tag_if;
// `ptr` is not tagged, so CAS fails.
assert!;
// `ptr` can be tagged.
ptr.set_tag;
// The return value of CAS is a handle to the instance that `atomic_arc` previously owned.
let prev: = atomic_arc.compare_exchange.unwrap.0.unwrap;
assert_eq!;
// `17` will be garbage-collected later.
drop;
// `ebr::AtomicArc` can be converted into `ebr::Arc`.
let arc: = atomic_arc.try_into_arc.unwrap;
assert_eq!;
// `18` will be garbage-collected later.
drop;
// `17` is still valid as `barrier` keeps the garbage collector from dropping it.
assert_eq!;
LinkedList
LinkedList is a type trait that implements wait-free concurrent singly linked list operations, backed by EBR. It additionally provides support for marking an entry of a linked list to indicate that the entry is in a user-defined state.
Examples
use ;
use LinkedList;
use Relaxed;
;
let barrier = new;
let head: L = default;
let tail: = new;
// A new entry is pushed.
assert!;
assert!;
// Users can mark a flag on an entry.
head.mark;
assert!;
// `next_ptr` traverses the linked list.
let next_ptr = head.next_ptr;
assert_eq!;
// Once `tail` is deleted, it becomes invisible.
tail.delete_self;
assert!;
HashMap
HashMap is a scalable in-memory unique key-value container that is targeted at highly concurrent write-heavy workloads. It uses EBR for its hash table memory management in order to implement non-blocking resizing and fine-granular locking; it is not a lock-free data structure, and each access to a single key is serialized by a bucket-level mutex. HashMap is optimized for frequently updated large data sets, such as the lock table in database management software.
Examples
A unique key can be inserted along with its corresponding value, and then it can be updated, read, and removed.
use HashMap;
let hashmap: = default;
assert!;
assert_eq!;
assert_eq!;
assert_eq!;
It supports upsert as in database management software; it tries to insert the given key-value pair, and if it fails, it updates the value field with the supplied closure.
use HashMap;
let hashmap: = default;
hashmap.upsert;
assert_eq!;
hashmap.upsert;
assert_eq!;
There is no method to confine the lifetime of references derived from an Iterator to the Iterator, and it is illegal to let them live as long as the HashMap. Therefore Iterator is not implemented, instead, it provides two methods that allow a HashMap to iterate over its entries: for_each, and retain.
use HashMap;
let hashmap: = default;
assert!;
assert!;
// Inside `for_each`, an `ebr::Barrier` protects the entry array.
let mut acc = 0;
hashmap.for_each;
assert_eq!;
// `for_each` can modify the entries.
assert_eq!;
assert_eq!;
assert!;
// Inside `retain`, an `ebr::Barrier` protects the entry array.
assert_eq!;
Asynchronous methods can be used in asynchronous code blocks; asynchronous methods yield the task when the target mutex cannot be acquire.
use HashMap;
let hashmap: = default;
let future_insert = hashmap.insert_async;
let result = future_insert.await;
HashSet
HashSet is a variant of HashMap where the value type is ().
Examples
All the HashSet methods do not receive a value argument.
use HashSet;
let hashset: = default;
assert!;
assert!;
assert!;
The capacity of a HashSet can be specified.
use HashSet;
use RandomState;
let hashset: = new;
assert_eq!;
HashIndex
HashIndex is a read-optimized version of HashMap. It applies EBR to its entry management as well, enabling it to perform read operations without acquiring locks.
Examples
Its read method does not modify any shared data.
use HashIndex;
let hashindex: = default;
assert!;
assert_eq!;
An Iterator is implemented for HashIndex, because derived references can survive as long as the associated ebr::Barrier lives.
use Barrier;
use HashIndex;
let hashindex: = default;
assert!;
let barrier = new;
// An `ebr::Barrier` has to be supplied to `iter`.
let mut iter = hashindex.iter;
// The derived reference can live as long as `barrier`.
let entry_ref = iter.next.unwrap;
assert_eq!;
drop;
// The entry can be read after `hashindex` is dropped.
assert_eq!;
TreeIndex
TreeIndex is a B+ tree variant optimized for read operations. The ebr module enables it to implement lock-free read and scan methods.
Examples
Key-value pairs can be inserted, read, and removed.
use TreeIndex;
let treeindex: = new;
assert!;
assert_eq!;
assert!;
Key-value pairs can be scanned.
use Barrier;
use TreeIndex;
let treeindex: = new;
assert!;
assert!;
assert!;
let barrier = new;
let mut visitor = treeindex.iter;
assert_eq!;
assert_eq!;
assert_eq!;
assert!;
Key-value pairs in a specific range can be scanned.
use Barrier;
use TreeIndex;
let treeindex: = new;
for i in 0..10
let barrier = new;
assert_eq!;
assert_eq!;
assert_eq!;
Asynchronous methods can be used in asynchronous code blocks; asynchronous methods yield the task when the target mutex cannot be acquire.
use TreeIndex;
let treeindex: = default;
let future_insert = treeindex.insert_async;
let result = future_insert.await;
Performance
Interpret the results cautiously as benchmarks do not represent real world workloads.
Setup
- OS: SUSE Linux Enterprise Server 15 SP2
- CPU: Intel(R) Xeon(R) CPU E7-8880 v4 @ 2.20GHz x 4
- RAM: 1TB
- Rust: 1.60.0
- SCC: 0.6.9
Workload
- A disjoint range of 16M
usizeintegers is assigned to each thread. - Insert: each thread inserts its own records.
- Read: each thread reads its own records in the container.
- Scan: each thread scans the entire container once.
- Remove: each thread removes its own records from the container.
- InsertR, RemoveR: each thread additionally operates using keys belonging to a randomly chosen remote thread.
- MixedR: each thread performs
InsertR->ReadR->RemoveR.
Results
| 1 thread | 4 threads | 16 threads | 64 threads | |
|---|---|---|---|---|
| InsertL | 9.411s | 16.041s | 43.012s | 46.540s |
| ReadL | 3.934s | 4.955s | 6.548s | 8.612s |
| ScanL | 0.147s | 0.801s | 3.021s | 13.186s |
| RemoveL | 4.654s | 6.315s | 10.651s | 23.05s |
| InsertR | 11.116s | 27.104s | 54.909s | 58.564s |
| MixedR | 14.976s | 29.388s | 30.518s | 33.081s |
| RemoveR | 7.057s | 12.565s | 18.873s | 26.77s |
| 1 thread | 4 threads | 16 threads | 64 threads | |
|---|---|---|---|---|
| InsertL | 9.73s | 17.11s | 44.599s | 52.276s |
| ReadL | 3.59s | 4.977s | 6.108s | 8.3s |
| ScanL | 0.279s | 1.279s | 5.079s | 20.317s |
| RemoveL | 4.755s | 7.406s | 12.329s | 33.509s |
| InsertR | 11.416s | 26.998s | 54.513s | 65.274s |
| MixedR | 18.224s | 35.357s | 39.05s | 42.37s |
| RemoveR | 8.553s | 13.314s | 19.362s | 38.209s |
| 1 thread | 4 threads | 16 threads | 64 threads | |
|---|---|---|---|---|
| InsertL | 14.839s | 16.196s | 18.644s | 43.914s |
| ReadL | 3.584s | 4.168s | 4.531s | 5.208s |
| ScanL | 1.239s | 5.088s | 20.778s | 85.319s |
| RemoveL | 5.736s | 8.327s | 10.5s | 10.465s |
| InsertR | 20.543s | 77.743s | 56.254s | 65.242s |
| MixedR | 27.587s | 164.433s | 429.19s | 453.633s |
| RemoveR | 9.38s | 20.262s | 30.455s | 39.091s |
HashMap Performance Comparison with DashMap and flurry
- Results on Apple M1 (8 cores).
- Results on Intel Xeon (88 cores).
- Interpret the results cautiously as benchmarks do not represent real world workloads.
- HashMap outperforms the others according to the benchmark test under highly concurrent or write-heavy workloads.
- The benchmark test is forked from conc-map-bench.
Changelog
0.6.9
0.6.8
- Fix wait queue performance issues with asynchronous TreeIndex methods.
0.6.7
- Fix ebr API,
ebr::AtomicArc::swap: return the previousebr::Tagalong with the pointer. - Fix ebr API,
ebr::AtomicArc::compare_exchange: receive a reference toebr::Barrier. - Fix #49 for synchronous TreeIndex methods.
0.6.6
- Add
{HashMap, HashSet}::{scan, scan_async}for a read-only scan. - Minor HashMap optimization.