Expand description
A lock-free, partially wait-free, eventually consistent, concurrent hashmap.
This map implementation allows reads to always be wait-free, and almost as cheap as reading from an
Arc<HashMap<K, V>>. Moreover, writes (when executed from a single thread only) will effectively
be wait-free if performed sufficiently infrequently, and readers do not hold onto guards for
extended periods of time.
The trade-offs for extremely cheap reads are that a write can only be exectued from one thread at a time, and eventual consistency. In other words, when a write is performed, all reading threads will only observe the write once they complete their last read and begin a new one.
How is flashmap different?
The underlying algorithm used here is, in principle, the same as that used by
evmap. However the implementation of that algorithm has been
modified to significantly improve reader performance, at the cost of some necessary API
changes and a different performance profile for the writer. More information on the implementation
details of the algorithm can be found in the algorithm module.
When to use flashmap
flashmap is optimized for read-heavy to almost-read-only workloads where a single writer is
acceptable. Good use-cases include:
- High frequency reads with occational insertion/removal
- High frequency modification of existing entries with low contention via interior mutability with occasional insertion/removal
- High frequency reads with another thread executing a moderate write workload
Situations when not to use flashamp include:
- Frequent, small writes which cannot be batched
- Concurrent write access from multiple threads
Performance
TODO: compile some benchmarks
Structs
Allows for aliasing typically non-aliasable types without undefined behavior or SB violations.