Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Atomic counters in statistics #1504
Staticist operation includes many counters, as for instance the counter for request number per type (included since the very first version of the statistics functionality) or the timing counters and notification queue counters recently introduced.
These counters are potencially incremented from concurrent threads but currently we are not using any mechanism in our code to ensure that increments are done in atomic way. Thus, considering counter C with value N, it may happend that if thread A want to increase in one and thread B wants to increse in one, the counter ends with N+1 at the end (instead of N+2).
Some parts (the ones related with notification queue) are using a mechanism based in
There could be a trade off between precision and performance if the coded implementation for these builtins uses internal exclusion mechanisms which make some threads to wait while the other modifies the counter. However, as long as we can control statistics generation with CLI parameters (probably CLI switch for statistics should be also reviewed when addressing this issue), it shouldn't be a problem given that:
(Initally assinged to 0.26.0, but maybe it would be deferred to a future milestone after internal discussion).