Preventing False Sharing and Contention

[computerquip]

I'm trying to make a scalable HTTP server. I have some configuration that potentially changes in the middle of the application. It doesn't change very often but it is read on almost every request. I don't want to use a mutex to avoid contention and I don't want to use a global to prevent false sharing. I don't want to make a copy for every request as the state may end up being large and there's a lot of small requests. A thread_local sounds viable but I'm having a hard time figuring out how to update the state for every thread in the thread pool via message passing somehow. A task_local also seems viable but I don't see a lot of examples and I'm not sure if it fits the condition of not making copies for every request.

Are there any suggestions on the route I should go here?

[Darksonn]

One option you may go for is the arc-swap crate. This lets you clone the state only on each change, and any requests using it while you update it will continue to use the old value, but new requests would use the new one. The old value would be destroyed when the last requests using the old one finishes.

Another option is to go for the watch channel. This channel only retains the last value and lets you access the current value without cloning. However it doesn't have the property that requests can keep using the old one as the current value is stored in a read-write lock.

[computerquip-work]

I misunderstood the watch channel, I wasn't aware you could just borrow the latest value. I thought the value had to be transmitted to each task on startup somehow. arc-swap also looks very neat. Either way, these are definitely a start, appreciate the answer!

[ats1999]

If i understood arc-swap correctly then using it could be a disadvantage. Here is a quote from arc-swap documentation.

There’s only limited number of “fast” slots for borrowing from ArcSwap for each single thread (currently 8, but this might change in future versions). If these run out, the algorithm falls back to slower path.
If too many Guards are kept around, the performance might be poor. These are not intended to be stored in data structures or used across async yield points.

Ref =>
https://docs.rs/arc-swap/latest/arc_swap/docs/limitations/index.html#:~:text=There's%20only%20limited%20number%20of,the%20performance%20might%20be%20poor.