Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: support "soft" synchronization for Async Runtime #289

Open
thorseraq opened this issue Nov 7, 2023 · 5 comments
Open

RFC: support "soft" synchronization for Async Runtime #289

thorseraq opened this issue Nov 7, 2023 · 5 comments

Comments

@thorseraq
Copy link

thorseraq commented Nov 7, 2023

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).

image

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:

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

@zRegle
Copy link

zRegle commented Nov 22, 2023

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

@esemeniuc
Copy link

Would love to see this!

@tomkarw
Copy link
Contributor

tomkarw commented Feb 3, 2024

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
Copy link

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants