I have a task, which has two futures, both being waited on. The first future consumes data from a channel, transforms it and sends it out another channel, incrementing a stats counter. The second future waits on a different channel for a "stats request", where it will send the current value of the counter to a different channel. I need this to be fast and efficient, so no mutex. I don't need to share the value; so a copy is perfectly fine. Am I better off using an atomic, or a cell for the mutable counter? If it makes a difference, the counter is in a self, shared between the two futures. My understanding, is even though its 2 futures, because they are in the same spawned task, the two won't run concurrently, even when the executor is shared across multiple threads.
While atomic feels like the easy choice, I'm concerned about what happens in a 16 or 32 core systems where I have lots of tasks running, doing similar counting. I don't know enough about the performance of updating, or reading a Cell counter vs an atomic counter.
The stats are part of self, and the read/writer are two futures which are part of the same task. Unfortunately, the borrow-checker isn't sophisticated enough to know that as a result the two futures will never run concurrently. So, I'm left using something that requires a fence. Currently, I'm wrapping the stats into a RWLock and calling try_read/write(), which should never fail and should be fast enough. I'll likely compare this against some kind of mutex/guard for comparison. Clearly I could drop down to unsafe code, but I'd like to avoid doing so.