Open thorseraq opened 7 months ago
I've came across same problem, it would be nice that dashmap can be run in async runtime
Would love to see this!
You should check if moka or quick-cache would fit your use-case. They are cache implementations, but you either a) should use cache in the first place, or b) can set the capacity to u64::MAX
and let your RAM run out before any evictions would happen.
It's worth noting that I'm currently switching back from mini_moka
to dashmap
. I liked the idea of having my cache automatically managed, and mini-moka is apparently backed by dashmap, but it devastated my software's performance due to repeated calls to std::time::Instant
.
I'm looking into this at the moment. Hopefully I will have a satisfactory solution relatively soon.
Background
Due to
DashMap
's usability and great work of dealing with racing condition, I have seen cases when it was used in production scenario, which also includes when async runtime are started (such as Tokio) and CRUD method ofDashMap
are called in Async Runtime.Problem
The
spin
or elsepark
behavior will block the current thread, if it was called in one of the async runtime's thread, the current async runtime thread will be blocked, which is not the best practice. (The task should yield the occupation of the current thread and let the current thread be able to handle other tasks).In the worst case, when all threads of async runtime are blocked due to waiting for some lock, none of the left async tasks are able to be executed.
Recommendations
Add feature flag such as
async_runtime
, when it was opened, use RwLock struct which can return struct that implements the Future trait whenread()
,write()
is called, such astokio::sync::RwLock
to replace theRwLock
in currentshards
type:https://github.com/xacrimon/dashmap/blob/febc45dc62eecf3415024bb819e1aec7e4a063a7/src/lib.rs#L90