moka/
cht.rs

1//! Lock-free hash tables.
2//!
3//! The hash tables in this crate are, at their core, open addressing hash
4//! tables implemented using open addressing and boxed buckets. The core of
5//! these hash tables are bucket arrays, which consist of a vector of atomic
6//! pointers to buckets, an atomic pointer to the next bucket array, and an
7//! epoch number. In the context of this crate, an atomic pointer is a nullable
8//! pointer that is accessed and manipulated using atomic memory operations.
9//! Each bucket consists of a key and a possibly-uninitialized value.
10//!
11//! The key insight into making the hash table resizable is to incrementally
12//! copy buckets from the old bucket array to the new bucket array. As buckets
13//! are copied between bucket arrays, their pointers in the old bucket array are
14//! CAS'd with a null pointer that has a sentinel bit set. If the CAS fails,
15//! that thread must read the bucket pointer again and retry copying it into the
16//! new bucket array. If at any time a thread reads a bucket pointer with the
17//! sentinel bit set, that thread knows that a new (larger) bucket array has
18//! been allocated. That thread will then immediately attempt to copy all
19//! buckets to the new bucket array. It is possible to implement an algorithm in
20//! which a subset of buckets are relocated per-thread; such an algorithm has
21//! not been implemented for the sake of simplicity.
22//!
23//! Bucket pointers that have been copied from an old bucket array into a new
24//! bucket array are marked with a borrowed bit. If a thread copies a bucket
25//! from an old bucket array into a new bucket array, fails to CAS the bucket
26//! pointer in the old bucket array, it attempts to CAS the bucket pointer in
27//! the new bucket array that it previously inserted to. If the bucket pointer
28//! in the new bucket array does *not* have the borrowed tag bit set, that
29//! thread knows that the value in the new bucket array was modified more
30//! recently than the value in the old bucket array. To avoid discarding updates
31//! to the new bucket array, a thread will never replace a bucket pointer that
32//! has the borrowed tag bit set with one that does not. To see why this is
33//! necessary, consider the case where a bucket pointer is copied into the new
34//! array, removed from the new array by a second thread, then copied into the
35//! new array again by a third thread.
36//!
37//! Mutating operations are, at their core, an atomic compare-and-swap (CAS) on
38//! a bucket pointer. Insertions CAS null pointers and bucket pointers with
39//! matching keys, modifications CAS bucket pointers with matching keys, and
40//! removals CAS non-tombstone bucket pointers. Tombstone bucket pointers are
41//! bucket pointers with a tombstone bit set as part of a removal; this
42//! indicates that the bucket's value has been moved from and will be destroyed
43//! if it has not been already.
44//!
45//! As previously mentioned, removing an entry from the hash table results in
46//! that bucket pointer having a tombstone bit set. Insertions cannot
47//! displace a tombstone bucket unless their key compares equal, so once an
48//! entry is inserted into the hash table, the specific index it is assigned to
49//! will only ever hold entries whose keys compare equal. Without this
50//! restriction, resizing operations could result in the old and new bucket
51//! arrays being temporarily inconsistent. Consider the case where one thread,
52//! as part of a resizing operation, copies a bucket into a new bucket array
53//! while another thread removes and replaces that bucket from the old bucket
54//! array. If the new bucket has a non-matching key, what happens to the bucket
55//! that was just copied into the new bucket array?
56//!
57//! Tombstone bucket pointers are typically not copied into new bucket arrays.
58//! The exception is the case where a bucket pointer was copied to the new
59//! bucket array, then CAS on the old bucket array fails because that bucket has
60//! been replaced with a tombstone. In this case, the tombstone bucket pointer
61//! will be copied over to reflect the update without displacing a key from its
62//! bucket.
63//!
64//! This hash table algorithm was inspired by [a blog post by Jeff Phreshing]
65//! that describes the implementation of the Linear hash table in [Junction], a
66//! C++ library of concurrent data structures. Additional inspiration was drawn
67//! from the lock-free hash table described by Cliff Click in [a tech talk] given
68//! at Google in 2007.
69//!
70//! [a blog post by Jeff Phreshing]: https://preshing.com/20160222/a-resizable-concurrent-map/
71//! [Junction]: https://github.com/preshing/junction
72//! [a tech talk]: https://youtu.be/HJ-719EGIts
73
74pub(crate) mod iter;
75pub(crate) mod map;
76pub(crate) mod segment;
77
78#[cfg(test)]
79#[macro_use]
80pub(crate) mod test_util;
81
82pub(crate) use segment::HashMap as SegmentedHashMap;