49 releases (stable)

5.0.33 Nov 11, 2023
5.0.29 Aug 5, 2023
5.0.27 Jul 26, 2023
5.0.12 Mar 26, 2023
0.0.13 Nov 13, 2022

#168 in Concurrency

Download history 78/week @ 2023-12-12 63/week @ 2023-12-19 29/week @ 2023-12-26 1/week @ 2024-01-02 15/week @ 2024-01-09 17/week @ 2024-01-16 10/week @ 2024-01-23 8/week @ 2024-01-30 19/week @ 2024-02-06 31/week @ 2024-02-13 127/week @ 2024-02-20 115/week @ 2024-02-27 31/week @ 2024-03-05 53/week @ 2024-03-12 49/week @ 2024-03-19 49/week @ 2024-03-26

189 downloads per month
Used in 9 crates (2 directly)


1.5K SLoC


Lock-free linearizable map.

  • get, insert, cas, remove, iter, range, get_gt, get_gte, get_lt, get_lte, first, last, pop_first, pop_last
  • fully lock-free node splits and merges based on the sled battle-tested implementation. concurrent-map can be though of in some ways as a simplified, in-memory sled that supports high-level types.
  • initially designed for use in sled's next generation object store, marble.

The ConcurrentMap allows users to tune the tree fan-out (FANOUT) and the underlying memory reclamation granularity (LOCAL_GC_BUFFER_SIZE) for achieving desired performance properties. The defaults are pretty good for most use cases but if you want to squeeze every bit of performance out for your particular workload, tweaking them based on realistic measurements may be beneficial. See the ConcurrentMap docs for more details.

If you want to use a custom key type, you must implement the Minimum trait, allowing the left-most side of the tree to be created before inserting any data.

This is an ordered data structure, and supports very high throughput iteration over lexicographically sorted ranges of values. If you are looking for simple point operation performance, you may find a better option among one of the many concurrent hashmap implementations that are floating around. Pay for what you actually use :)


~17K SLoC