As we saw in SERVER-20091, using a spinlock in situations where a large number of threads can contend for a resource can lead to scalability issues and erratic behavior. Code inspection reveals an additional place where this might occur: TimerStats uses a spinlock to make updates to the count and the total time atomic, and this is used by gleWtimeStats, which can potentially be updated by a large number of threads at high connection count. We could avoid this by

• using a mutex instead of a spinlock
• don't use any lock, use atomics for the individual stats (count and total milliseconds), accept the possibility of a small skew between the two. I think this is probably acceptable for the typical uses of this statistic.

I haven't been able to demonstrate a performance issue for this because this stat is only update for write concern with w>1 or j:true, and both of those have other performance issues that dominate at the moment. Independent of that however, it seems like a good idea to forestall performance pitfalls for future uses of this class.