Yep, makes sense. I second your opinion, absolute consistency between metrics is not that valuable.
On Thu, Oct 8, 2015 at 8:57 PM, Rainer Gerhards <[email protected]> wrote: > 2015-10-08 17:19 GMT+02:00 singh.janmejay <[email protected]>: >> 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? > > No, I haven't been precise enough. Usually, we have a set of counters > which interdepend. And so you never get them really consistent. > > Rainer >> >> -- >> 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" <[email protected]> wrote: >> >>> 2015-10-08 8:30 GMT+02:00 singh.janmejay <[email protected]>: >>> >> 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. -- Regards, Janmejay http://codehunk.wordpress.com _______________________________________________ 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.
