> Hello. > I found all stat is protected by thread's mutex. > All event is running in the signal thread context. > > Why need the protect,for sum?? or for command STAT?? > > thanks
It's for when the summation happens, you can get consistent reads. NOTES, SINCE I HEAR THIS A LOT: *uncontested* mutexes aren't free, but are very nearly free. *contested* mutexes slow things down a lot. Since those thread locks are only ever called in the brief times in which you actually run stats commands, they have a very very small amount of overhead. When I was doing the lock scaling patches for 1.4.10-1.4.15 I did test this out: https://github.com/dormando/memcached/commit/56ad41e1a19a7fc99da51bdca4fdcb524a300984 (a little further work would be required to make that change permanent). On 64bit systems you can do 64bit-aligned 8 byte memory reads atomically, so as long as the stats structure is all 64bit items, is 64bit aligned, and the external reader is ... just a reader, you can get pretty accurate readings. on 32bit you need the lock. So I thought I'd try removing the locks on my 64bit system and test it. There was *ALMOST NO* change in performance. I can't stress this enough. Everyone focuses on these locks but if you bust out a God Damned Ruler they don't even use crap for cycles. The other work I did ended up having a much higher effect when tested, and I merged those branches instead. I think it was between 1-5% change in speed. By comparison making the lock shorter in the item_alloc code was a 15-30% bump. It'll be nice to remove the uncontested locks and save some CPU, but it was a much lower priority than other work. have fun, -Dormando
