Comparison with ArcCell
Cocalus opened this issue · comments
It would nice if the documentation compared this to crossbeam::atomic::ArcCell. This appears to be similar while having more features but I'm unsure when I would pick one over the other.
Well, ArcCell is not lock free on either read or write operations, see here: crossbeam-rs/crossbeam#160.
AFAIK it has since been deprecated, but it's left there for now. So I don't know if I want to put links to deprecated thing into the documentation, but maybe some kind of „alternatives“ section would make sense. I'll think about how to make it fit nicely into the text.
Anyway, the people behind crossbeam do work on a replacement. AFAIK it's not yet released, but when it is it might actually turn faster and better in many cases. Both its read and write are lock free, but neither is wait free and readers sometime do a lot of work. You can actually look at the background benchmark in the faster-lease-bench branch.
I not seeing any indication of that ArcCell is deprecate yet in the crossbeam docs/readme/issues. Maybe when they get a replacement working.
So arc-swap so be faster than the current ArcCell in all or almost all cases.
@Cocalus I'm working on Crossbeam.
We haven't been explicit about deprecating ArcCell, but we definitely want to remove it. After all, it's just a hack and not much better (if at all!) than parking_lot::Mutex<Arc<T>>.
We want to replace it with something roughly similar to ArcSwap that would use hazard pointers behind the scenes. There's a prototype in https://github.com/stjepang/atomic, but it's not ready yet.
Ok so in the short term if I need something not depreciated I should use ArcSwap or just parking_lot::Mutex<Arc>.
Yep, that's what I'd suggest!
I've added a section with alternatives, so I think this can be closed. If you find any other alternative, feel free to open a PR or an issue.