Atomic ops are actually rather expensive (almost as expsnsive as full locks). If
you want a lockless metrics capability, you should do a separate set of
variables per thread, gathering them a reporting time. And document that there
is going to be inconsistancy between the different metrics
unless you lock everything, you are going to have inconsistancies across the
different metrics.
Also, not all platforms have the easy atomic ops you are thinking of, and atomic
ops can't operate on all sizes of data (for example, 32 bit systems probably
can't update a 64 bit value atomically)
David Lang
On Thu, 8 Oct 2015, singh.janmejay wrote:
Did you mean it's not atomic across different metrics? That I think should
be acceptable. A single metric however should get swapped losslessly with
atomic-swap. Either an increment of m should be applied before swap (making
the reading n + m, or after it leaving the accumulator at m and reading at
n). But it should not be lost.
Am I misunderstanding something?
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 8, 2015 12:33 PM, "Rainer Gerhards" <rgerha...@hq.adiscon.com> wrote:
2015-10-08 8:30 GMT+02:00 singh.janmejay <singh.janme...@gmail.com>:
Similarly, when one thread goes to output the stats, you need to lock
them so that there isn't a lost increment between the time that you read
the stat and the time you zero it.
No, this involves the same shared (uncontended) lock, except
atomic-increment is replaced by atomic-swap with 0.
Just FYI: this is what the current stats system also does. It is also
where some inaccuracy stems from. Reporting stats is not atomic
without looks, so a stats counter may be read with value n, then m
atomic increments happen to it on another thread, then value n is
being reported (but we are really at n+m) and then the stats counter
is reset to 0 via an atomic swap. So m updates are lost. IMHO this is
perfectly acceptable, because otherwise we would lose almost all
concurrency.
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
