RFC: support "soft" synchronization for Async Runtime

[thorseraq]

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 of DashMap are called in Async Runtime.

Problem

The spin or else park 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 when read(), write() is called, such as tokio::sync::RwLock to replace the RwLock in current shards type:

dashmap/src/lib.rs

Line 90 in febc45d

shards: Box<[RwLock<HashMap<K, V, S>>]>,

[zRegle]

I've came across same problem, it would be nice that dashmap can be run in async runtime

[esemeniuc]

Would love to see this!

[tomkarw]

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.

[leontoeides]

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.

[xacrimon]

I'm looking into this at the moment. Hopefully I will have a satisfactory solution relatively soon.