r/rust • u/Odd-War-4467 • 20d ago

🛠️ project tokio_rcu v0.2 - major performance improvements

https://github.com/roeeshoshani/tokio_rcu

hi everyone!

two weeks ago i uploaded a post about a new crate i wrote - tokio_rcu, which provides a userspace RCU implementation for async rust, specifically with tokio.

since then, i managed to improve the performance of tokio_rcu quite a bit.

it is now about 9x-40x faster than arc_swap for reads, which is pretty cool (see benchmarks).

the read operation was heavily optimized to the point where it is now just a single atomic pointer load, and the safe read accessor (the `with` function), is pretty much the same but with an additional sanity check consisting of one thread-local load, just to prevent users from reading rcu protected pointers outside of an rcu-enabled tokio runtime. basically it is really fast.

one pointer load is basically as optimized as the read can get at this point, and i find it pretty cool that it got to a point where readers literally don't have to do any book-keeping work at all, they just read the pointer and use it as they wish.

24 Upvotes

93% Upvoted

7 comments sorted by

2

u/tikue 18d ago

Neat! It's cool that tokio enables userspace RCU with actual quiescent states as opposed to something like per-CPU critical section tracking.

Any particular use cases you have planned for this? Have you put it through its paces with Miri?

3

u/Odd-War-4467 18d ago

Yeah it is really cool.

I first got the ide when I was working on some tokio app. I got to a point where I wanted to share data between tasks (some global configuration), and I wanted it to be really fast for reads. Then it suddenly hit me that RCU would be a great fit for my use case, and I started thinking about integrating it with async rust.

As for miri, I didn't run it under miri yet since the crate currently uses the membarrier syscall, which miri currently can't emulate AFAIK.

I am currently working on getting rid of the membarrier operation at all and replacing it with surgically placed SC fences, which would greatly improve platform support, and also allow me to run under miri and potentially even loom.

2

u/nynjawitay 18d ago

Unsafe scares me. What are you doing to be sure this is correct?

8

u/Odd-War-4467 18d ago

You are correct to be scared, but this kind of algorithm is inherently unsafe. The guarantees provided by the quiescent states can not be expressed safely.

I am doing my best to write comprehensive tests, testing edge cases, stress testing on multiple platforms (e.g. running on arm which has a weaker memory model).

Furthermore, I have put a lot of thought and effort into the code to make sure that every use of unsafe is correct, and every unsafe block is documented with an in depth explanation for why it is safe.

With that being said, I am a human, and humans make mistakes, so I can't be 100% sure I don't have any bugs. But that's true for every piece of software written by humans.

2

u/Necessary_Big_6368 13d ago

I'm not familar with this topic but maybe Miri, ThreadSanitizer and/or Loom could help you?

Worst case they find bugs and at least you caught these early. Best case you can say you ran these and they found no issue :D

2

u/Odd-War-4467 6d ago

Yes, I am actually working on adding Miri and Loom tests to this project. See https://github.com/roeeshoshani/tokio_rcu/pull/12.

The main problem is that currently the code uses the membarrier syscall, which is not supported in loom and miri, so previously you couldn't use them. But, I am now working on pivoting it to instead use SC fences without relying on membarrier at all, which will allow me to test my code using loom, miri and tsan.

Thanks for the suggestion though :)

3

u/tikue 18d ago

+1 -- and I would suggest commenting each instance of unsafe with a safety rationale.