I think it is a hybrid loop, but the documentation is not really clear about
it. It is not as hybrid as a critical section (which internally falls back to
the kernel based mutex behavior for long waits), but it is more CPU efficient
than a loop around a few simple atomic operations.
Looking
By googling for more details I just found an additional problem…
TryAcquireSRWLockExclusive and TryAcquireSRWLockShared are only implemented on
Windows 7 and later (not Vista and later), so the code needs more fallback
behavior for Vista.
Bert
From: Bert Huijben
I created a patch for the ‘use apr mutex instead of Windows mutex’ scenario
with a surprising result in my initial measurements.
It looks like this implementation is actually a tiny bit faster than the
Windows SRW lock on all cases in testlockperf.exe…
It could be that this is caused by
