Skip to content

Commit

Permalink
Simplify README
Browse files Browse the repository at this point in the history
  • Loading branch information
@jonhoo
jonhoo committed May 5, 2020
1 parent 4661c85 commit 44eed56
Show file tree
Hide file tree
Showing 2 changed files with 0 additions and 201 deletions.
168 changes: 0 additions & 168 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -34,174 +34,6 @@ meta-information. The writers may update this at will, and when a refresh happen
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

```rust
// 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() {
for review in reviews {
println!("{}: \"{}\"", book, review);
}
}
```

Reads from multiple threads are possible by cloning the `ReadHandle`.

```rust
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`.

```rust
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());
}
```

## Implementation

Under the hood, the map is implemented using two regular `HashMap`s, 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 `HashMap`s 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.

## Performance

I've run some benchmarks of evmap against a standard Rust `HashMap` protected
Expand Down
33 changes: 0 additions & 33 deletions README.tpl
View file

This file was deleted.

0 comments on commit 44eed56

Please sign in to comment.