Lock contention

I had reason to run my deadlock detection tool on a server built with an old version of The Server Framework as I needed to make changes to the server’s locking strategy and I wanted to make sure that I didn’t cause any lock inversions. The tool worked well and I tweaked it a little more to make it run faster (considerably faster actually!) and report better… The speed increase was pretty dramatic and consisted of adding a new option to the tool to prevent it from monitoring lock operations for locks that we have never seen created. This excludes all of the locks that are created in system dlls during process startup and, normally, you don’t need to worry about them when you’re looking for lock inversions.

The reporting changes fixed a couple of bugs in how I was reporting lock usage and made my lock contention report more useful. The tool has always reported on contention, the idea being that once the GUI is bolted on you will be able to view the ‘hottest’ locks in your program and work out if they really should be that hot…

Anyway, the hottest lock in my server was an unexpected one. I use the STL to get string representations of numbers; you know, you stream the number into a stream and then extract the string representation. It seems that when doing such things using the STL that comes with VS2005 a lock is taken out to access the locale information… I now have a note on my list of things to do which tells me to run my deadlock tool on the test servers from my latest version of the framework. There are two reasons for this. One so that I ‘dog food’ the deadlock tool and the second so that I can work out if there are any easy performance improvements due to unexpectedly hot locks…