Slightly more efficient locking

Another performance improvement in the forthcoming 6.6 release is due to a change in our default choice for locking primitives on most platforms. Note that the perf improvement is small and, according to our testing, it doesn’t materialise on all hardware (though there’s no performance degradation seen).

The change is to switch from using CRITICAL_SECTION objects to using Slim Reader Writer Locks in exclusive (write) mode. You can read about the differences between these two locks in Kenny Kerr’s MSDN article here. This change can’t be applied to all uses of our CCriticalSection class as SRW locks are not recursive and so we have a whole new locking class hierarchy with new CLockableObject locks which use SRW locks on platforms that support it and drop back to using a CRITICAL_SECTION on XP and earlier. Then there’s a CReentrantLockableObject which is, basically, a CCriticalSection with a new name and a slightly new interface. There are also classes for locks which track the thread that owns them (just so that they can tell you if you currently have them locked) as we use that functionality in a couple of places in The Server Framework for optimising code paths.

The new locks give a slight improvement in the time taken to acquire them and use fewer resources. They haven’t been fully integrated into all libraries yet (in particular they are not in use throughout the Socket Tools library yet) and so the full affect of these changes cannot yet be appreciated.