Crate evmap

A lock-free, eventually consistent, concurrent multi-value map.

This map implementation allows reads and writes to execute entirely in parallel, with no implicit synchronization overhead. Reads never take locks on their critical path, and neither do writes assuming there is a single writer (multi-writer is possible using a Mutex), which significantly improves performance under contention.

The trade-off exposed by this module is one of eventual consistency: writes are not visible to readers except following explicit synchronization. Specifically, readers only see the operations that preceeded the last call to WriteHandle::refresh by a writer. This lets writers decide how stale they are willing to let reads get. They can refresh the map after every write to emulate a regular concurrent HashMap, or they can refresh only occasionally to reduce the synchronization overhead at the cost of stale reads.

For read-heavy workloads, the scheme used by this module is particularly useful. Writers can afford to refresh after every write, which provides up-to-date reads, and readers remain fast as they do not need to ever take locks.

The map is multi-value, meaning that every key maps to a collection of values. This introduces some memory cost by adding a layer of indirection through a Vec for each value, but enables more advanced use. This choice was made as it would not be possible to emulate such functionality on top of the semantics of this map (think about it – what would the operational log contain?).

To faciliate more advanced use-cases, each of the two maps also carry some customizeable meta-information. The writers may update this at will, and when a refresh happens, the current meta will also be made visible to readers. This could be useful, for example, to indicate what time the refresh happened.

Examples

Single-reader, single-writer

// new will use the default HashMap hasher, and a meta of ()
// note that we get separate read and write handles
// the read handle can be cloned to have more readers
let (book_reviews_r, mut book_reviews_w) = evmap::new();

// review some books.
book_reviews_w.insert("Adventures of Huckleberry Finn",    "My favorite book.");
book_reviews_w.insert("Grimms' Fairy Tales",               "Masterpiece.");
book_reviews_w.insert("Pride and Prejudice",               "Very enjoyable.");
book_reviews_w.insert("The Adventures of Sherlock Holmes", "Eye lyked it alot.");

// at this point, reads from book_reviews_r will not see any of the reviews!
assert_eq!(book_reviews_r.len(), 0);
// we need to refresh first to make the writes visible
book_reviews_w.refresh();
assert_eq!(book_reviews_r.len(), 4);
// reads will now return Some() because the map has been initialized
assert_eq!(book_reviews_r.get("Grimms' Fairy Tales").map(|rs| rs.len()), Some(1));

// remember, this is a multi-value map, so we can have many reviews
book_reviews_w.insert("Grimms' Fairy Tales",               "Eh, the title seemed weird.");
book_reviews_w.insert("Pride and Prejudice",               "Too many words.");

// but again, new writes are not yet visible
assert_eq!(book_reviews_r.get("Grimms' Fairy Tales").map(|rs| rs.len()), Some(1));

// we need to refresh first
book_reviews_w.refresh();
assert_eq!(book_reviews_r.get("Grimms' Fairy Tales").map(|rs| rs.len()), Some(2));

// oops, this review has a lot of spelling mistakes, let's delete it.
// empty deletes *all* reviews (though in this case, just one)
book_reviews_w.empty("The Adventures of Sherlock Holmes");
// but again, it's not visible to readers until we refresh
assert_eq!(book_reviews_r.get("The Adventures of Sherlock Holmes").map(|rs| rs.len()), Some(1));
book_reviews_w.refresh();
assert_eq!(book_reviews_r.get("The Adventures of Sherlock Holmes").map(|rs| rs.len()), None);

// look up the values associated with some keys.
let to_find = ["Pride and Prejudice", "Alice's Adventure in Wonderland"];
for book in &to_find {
    if let Some(reviews) = book_reviews_r.get(book) {
        for review in &*reviews {
            println!("{}: {}", book, review);
        }
    } else {
        println!("{} is unreviewed.", book);
    }
}

// iterate over everything.
for (book, reviews) in &book_reviews_r.read().unwrap() {
    for review in reviews {
        println!("{}: \"{}\"", book, review);
    }
}

Reads from multiple threads are possible by cloning the ReadHandle.

use std::thread;
let (book_reviews_r, mut book_reviews_w) = evmap::new();

// start some readers
let readers: Vec<_> = (0..4).map(|_| {
    let r = book_reviews_r.clone();
    thread::spawn(move || {
        loop {
            let l = r.len();
            if l == 0 {
                thread::yield_now();
            } else {
                // the reader will either see all the reviews,
                // or none of them, since refresh() is atomic.
                assert_eq!(l, 4);
                break;
            }
        }
    })
}).collect();

// do some writes
book_reviews_w.insert("Adventures of Huckleberry Finn",    "My favorite book.");
book_reviews_w.insert("Grimms' Fairy Tales",               "Masterpiece.");
book_reviews_w.insert("Pride and Prejudice",               "Very enjoyable.");
book_reviews_w.insert("The Adventures of Sherlock Holmes", "Eye lyked it alot.");
// expose the writes
book_reviews_w.refresh();

// you can read through the write handle
assert_eq!(book_reviews_w.len(), 4);

// the original read handle still works too
assert_eq!(book_reviews_r.len(), 4);

// all the threads should eventually see .len() == 4
for r in readers.into_iter() {
    assert!(r.join().is_ok());
}

If multiple writers are needed, the WriteHandle must be protected by a Mutex.

use std::thread;
use std::sync::{Arc, Mutex};
let (book_reviews_r, mut book_reviews_w) = evmap::new();

// start some writers.
// since evmap does not support concurrent writes, we need
// to protect the write handle by a mutex.
let w = Arc::new(Mutex::new(book_reviews_w));
let writers: Vec<_> = (0..4).map(|i| {
    let w = w.clone();
    thread::spawn(move || {
        let mut w = w.lock().unwrap();
        w.insert(i, true);
        w.refresh();
    })
}).collect();

// eventually we should see all the writes
while book_reviews_r.len() < 4 { thread::yield_now(); };

// all the threads should eventually finish writing
for w in writers.into_iter() {
    assert!(w.join().is_ok());
}

ReadHandle is not Sync as it is not safe to share a single instance amongst threads. A fresh ReadHandle needs to be created for each thread either by cloning a ReadHandle or from a ReadHandleFactory.

The reason for this is that each ReadHandle assumes that only one thread operates on it at a time. For details, see the implementation comments on ReadHandle.

 use evmap::ReadHandle;

 fn is_sync<T: Sync>() {
   // dummy function just used for its parameterized type bound
 }

 // the line below will not compile as ReadHandle does not implement Sync

 is_sync::<ReadHandle<u64, u64>>()

ReadHandle is Send though, since in order to send a ReadHandle, there must be no references to it, so no thread is operating on it.

 use evmap::ReadHandle;

 fn is_send<T: Send>() {
   // dummy function just used for its parameterized type bound
 }

 is_send::<ReadHandle<u64, u64>>()

For further explanation of Sync and Send here

Implementation

Under the hood, the map is implemented using two regular HashMaps, an operational log, epoch counting, and some pointer magic. There is a single pointer through which all readers go. It points to a HashMap, which the readers access in order to read data. Every time a read has accessed the pointer, they increment a local epoch counter, and they update it again when they have finished the read (see #3 for more information). When a write occurs, the writer updates the other HashMap (for which there are no readers), and also stores a copy of the change in a log (hence the need for Clone on the keys and values). When WriteHandle::refresh is called, the writer, atomically swaps the reader pointer to point to the other map. It then waits for the epochs of all current readers to change, and then replays the operational log to bring the stale map up to date.

Since the implementation uses regular HashMaps under the hood, table resizing is fully supported. It does, however, also mean that the memory usage of this implementation is approximately twice of that of a regular HashMap, and more if writes rarely refresh after writing.

Value storage

The values for each key in the map are stored in Values. Conceptually, each Values is a bag or multiset; it can store multiple copies of the same value. evmap applies some cleverness in an attempt to reduce unnecessary allocations and keep the cost of operations on even large value-bags small. For small bags, Values uses the smallvec crate. This avoids allocation entirely for single-element bags, and uses a Vec if the bag is relatively small. For large bags, Values uses the hashbag crate, which enables evmap to efficiently look up and remove specific elements in the value bag. For bags larger than one element, but smaller than the threshold for moving to hashbag, we use smallvec to avoid unnecessary hashing. Operations such as Fit and Replace will automatically switch back to the inline storage if possible. This is ideal for maps that mostly use one element per key, as it can improvate memory locality with less indirection.

Re-exports

pub use crate::shallow_copy::ShallowCopy;

Modules

shallow_copy

Types that can be cheaply aliased.

Structs

MapReadRef

A live reference into the read half of an evmap.

Options

Options for how to initialize the map.

Predicate

Unary predicate used to retain elements.

ReadGuard

A guard wrapping a live reference into an evmap.

ReadGuardIter

An Iterator over keys and values in the evmap.

ReadHandle

A handle that may be used to read from the eventually consistent map.

ReadHandleFactory

A type that is both Sync and Send and lets you produce new ReadHandle instances.

Values

A bag of values for a given key in the evmap.

WriteHandle

A handle that may be used to modify the eventually consistent map.

Enums

Operation

A pending map operation.

Functions

new

Create an empty eventually consistent map.

with_hasher

Create an empty eventually consistent map with meta information and custom hasher.

with_meta

Create an empty eventually consistent map with meta information.