Atomic counters in statistics

[fgalan]

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 __sync_fetch_and_add which could be extended to all the other counters. Another alternative is to use boost::atomic<D> but unfortunatelly it is not include in the Boost library version used by Cb.

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:

• If CB is going to be used in high-load environments, then the CLI parameter will be used to disable statistics at get maximum performance.
• If the CB is going to be used in not hihg-load environments, then performance is not critical.

(Initally assinged to 0.26.0, but maybe it would be deferred to a future milestone after internal discussion).

[fgalan]

The API metrics (#2750) should (and will :) use a mechanism to ensure atomicity.

Regarding the other "debug level" statistics at /statistics, this issue remains opened (although probably is less important each passing day).