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.
