-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comparison with "Concurrent Reference Counting and Resource Management in Constant Time" #34
Comments
I'll try to find some time to read it, but it's a bit long and heavy, so I can't promise when it would happen. Feel free to have a look first. There's a long comment in the code explaining the inner workings of arc-swap. One thing that I've noticed when skimming, they claim lock-free reads, while arc-swap claims wait-free ones (unless it's the first read on the given thread, in which case it is merely lock-free). But that was just by scrolling through the PDF 🤷 |
There was a blog post about it just yesterday: https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-pointers/ |
I've had the time to go through the blog post. It's not exactly easy reading and I'll need to go through it few more times. So these are just few impressions:
As I said, these are more of feelings/impressions. If someone would be willing to experiment with it and compare, it would be great, but I'm not sure I'll find the time soon. I don't think this will fit well into this library, but it does seem interesting. |
I'm reading through the article now and that seems a bit more promissing (in particular, using that kind of atomic copy may bring some improvements). And I'm starting to think that users could want to pick different trade-offs (some might be OK with delayed destruction if that brings them better read performance). So I will think if it would be possible to abstract the locking strategy into a trait and be able to add some more to pick from in the future (either directly in the crate or by a third-party crate). |
I've mined some ideas from there and used them. They propose wait-free/wait-free, arc-swap is currently wait-free/lock-free (readers/writers) and I suspect I'd have to make the readers slower to accomplish that. But it is an improvement already :-). If someone wants to try another implementation that is truly based on the article, not just inspired by some ideas from there, it should be possible to be done as part of arc-swap as an experimental strategy, but I'll close this for now. |
It would be interesting to know how arc-swap compares to the approach in https://arxiv.org/pdf/2002.07053.pdf
The text was updated successfully, but these errors were encountered: