#map #lock-free #multi-value

evmap

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

50 releases (stable)

11.0.0-alpha.1 Jun 3, 2020
10.0.2 May 11, 2020
9.0.1 Apr 26, 2020
9.0.0 Mar 17, 2020
0.4.0 Mar 31, 2017

#12 in Concurrency

Download history 5199/week @ 2020-06-01 6284/week @ 2020-06-08 7970/week @ 2020-06-15 6049/week @ 2020-06-22 4756/week @ 2020-06-29 8000/week @ 2020-07-06 6904/week @ 2020-07-13 8721/week @ 2020-07-20 15015/week @ 2020-07-27 12634/week @ 2020-08-03 6122/week @ 2020-08-10 5177/week @ 2020-08-17 6190/week @ 2020-08-24 5802/week @ 2020-08-31 6986/week @ 2020-09-07 7431/week @ 2020-09-14

14,229 downloads per month
Used in 10 crates (7 directly)

MIT/Apache

96KB
1.5K SLoC

evmap

Crates.io Documentation Build Status Codecov

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.

Performance

I've run some benchmarks of evmap against a standard Rust HashMap protected by a reader-writer lock, as well as against chashmap — a crate which provides "concurrent hash maps, based on bucket-level multi-reader locks". The benchmarks were run using the binary in benchmark/ on a 40-core machine with Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz CPUs.

The benchmark runs a number of reader and writer threads in tight loops, each of which does a read or write to a random key in the map respectively. Results for both uniform and skewed distributions are provided below. The benchmark measures the average number of reads and writes per second as the number of readers and writers increases.

Preliminary results show that evmap performs well under contention, especially on the read side. This benchmark represents the worst-case usage of evmap in which every write also does a refresh. If the map is refreshed less often, performance increases (see bottom plot).

Read throughput Write throughput Write throughput

Dependencies

~130–265KB