New release of Lock Explorer tools now support Slim Reader Writer locks and Mutexes

I’ve just released new versions of my Lock Explorer tools, LID and LIA. This is quite a big release as it increases the number of locking APIs that the tools instrument from 1 to 3. We now track Slim Reader Writer locks and Mutexes.

Arguably the tools should always have tracked these, and possibly more API calls, but the tools have always been first and foremost to assist in the development and testing of The Server Framework and, well, we only use Critical Sections. However, that has recently changed as we’re now using Slim Reader Writer locks as a more performant, non recursive, Critical Section replacement on platforms that support it - see here for more details. Future versions of The Server Framework will use SRW locks extensively and so we needed to update our testing tools to spot lock inversions which included the new locks.

The SRW API is similar to the Critical Section API in that the identifier for the lock is not a kernel handle. This makes it a reasonably easy and cheap API to instrument as all of the calls that we’ve hooked are about objects that we are interested in. Likewise a lock inversion is still a lock inversion and potential deadlock whether you acquire for read or write. Instrumenting the Mutex API was more complex as it is handle based and this means that you can have multiple handles pointing to the same mutex. This required a bit of a redesign of the internal data structures but the resulting changes should allow us to track any handle based lock API. The Mutex API is slightly more expensive to monitor as we have to look at ALL Wait operations and determine if any of the handles that we’re interested in are involved but at least the actual lock/unlock paradigm is the same. The other handle based synchronisation primitives hand more complex semantics; events and semaphores can be waited on in one thread and ‘released’ from another - so they will take a little more thought to integrate.

The non-recursive nature of SRW locks is also a potential issue for me with The Server Framework code. I now have a whole new set of lock objects and can build with a debug switch enabled which will check for attempts to recursively acquire a non-recursive lock but it’s also handy that LIA can now spot recursive acquisition of SRW locks and terminate the target process and pinpoint the lock acquisition call locations.