Shared KV store with slow handlers?

[anderspitman]

Summary

I have my axum handler working with a shared mutable state (Arc<Mutex<Library<KvStore>>>). The way it works is that my handler makes calls into Library, which uses KvStore to persist data it needs to use internally.

The problem is that Library makes upstream requests and calls can be quite slow. Since I'm locking the entire state for the full time the call is running, that means it basically I can't handle concurrent requests, even though the only things that actually needs to be locked is the very quick calls into KvStore by Library.

Conceptually what I want to accomplish is to have KvStore handle locking internally, so only actual reads/writes make other requests wait. But I'm not sure how to express this in a way the Rust compiler will accept.

axum version

0.7.9

[mladedav]

How about Arc<Library<KvStore>> with something like struct Library<KvStore> { store: Mutex<KvStore>, _other_fields: () }?

[anderspitman]

That was exactly the clue I needed. I was actually able to put the Mutex all the way inside the KvStore, so that individual reads/writes are locked, instead of the entire KvStore. It works great.

What I was missing was that Rust is smart enough to know that if you protect something with a Mutex, it's safe to make writes to it once you have a lock. Which in turn lets you make any functions modifying the object non-mut. I guess this is what they mean by fearless concurrency. Honestly quite remarkable. Though it is a bit confusing that you can modify internal data from a method that isn't mut. But I'll take that tradeoff any day.

Thank you!

[mladedav]

If you want to read more about this, you might want to look up "interior mutability", there are some types you can mutate through a shared reference. Mutex is classic example for multithreaded code, another is RefCell.

[anderspitman]

Thanks, I'll look into that more