It sound like you should compute this live instead. This accumulate errors, and require a lock, that seems worse on all fronts. I highly doubt a couple of floating points ops are most costly than this (especially since floating point divide is actually cheaper than integer divide, and all the require atomic ops would be read only, while the mutex require a write).

This is not the right place. You don't even know if these nodes will exchange anything yet.

Shouldn't the mutex be on the smart pointer instead? The metric themselves can be atomic anyways, so a mutex doesn't seem necessary.

Do we want this actually separated from the avalanche state? Maybe this should just be part of it.

When does it stop?

I don't think this code will misbehave if the count is zero.

dito

I though you were implementing an exponential low pass filter. You should update every window.

This achieves absolutely nothing meaningful. nextScore is assigned from availability score, so you are just assigning it to itself. But i can't even figure out what you meant to do here. The whole point of RCU to be able to wait for other to stop using a resource to do something with it, for instance compute statistics on value that won't ever be updated. For that to happen, you need to remove the pointer from public view, then wait for others to reach a revision after the pointer is out of public view, then you know you are the only owner of the resosurce and you can do whatever with it - for instance destroy it.

If you leave it there, then it doesn't matter how long you wait, someone will still be able to see it.

But it seems that you didn't even try to do that because you jumped through hoops to make all the stats fit into an atomic, and you reset them all atomically this way, so I'm not sure why is there even an attempt at doing some swapping business.

I wish I could be of more help, but none of this makes any sense to me. i don't even know what you are trying to do with this.

If the node doesn't have an avalanche state, we shouldn't be polling it.

Why? This comment says what I already know because I can read the code, but it doesn't tell me what i want to know: why.

This is bad way to compute the expo, because difference between floats tends to destroy precision, and in this case, precision errors do not cancel out. What you want is something akin to

(previousScore + k * (2 * votes - polls)) / (1 + k)

No need to do as flat what you can do as int, and no need to fear the division. It is faster for floats than it is for ints, and do not lose precision (same goes for multiplications).

Refreshing all the node every minutes seems like it's way overkill.

Why does this need to be a different object? I don't think it does.

Does that pass sanitizers? You are capturing by reference, but that lambda clearly outlive what's captured. You need to make things explicit, like for the other lambda.

Do not do floating point ops when you don't need to.

I also guess that decay factor is negative here, and you end up doing a fair bit of double negations that makes the code confusing.

Add new lines in between these.