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 trying to fit everything in a single pointer
value (as Windows does for the SRWLock), or it could be noise in my test
environment.
But at least it makes the apr rwlock fast enough for Subversion’s in memory
cache, without really changing any of the api behavior of apr.
Note that I now have to use rwlock->readers in apr_thread_rwlock_unlock(), like
in my original patch as the apr unlock doesn’t produce an usable errorcode. But
as we can assume having at least one reader or writer lock when entering this
function, this is safe to do.
Bert
From: Bert Huijben [mailto:[email protected]]
Sent: maandag 7 juli 2014 12:25
To: 'Jeff Trawick'; 'APR Developer List'
Subject: RE: Windows R/W lock comment
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 at the old implementation I’m thinking that as a first step we should
switch the current/old implementation to using an APR mutex instead of the
Windows mutex. On all NT platforms the apr mutex is implemented as a critical
section, which is much faster than the inter-process capable Windows mutex.
(Handling this mutex is where the current implementation spends almost all its
time)
Bert
From: Jeff Trawick [mailto:[email protected]]
Sent: donderdag 3 juli 2014 21:57
To: APR Developer List
Subject: Windows R/W lock comment
I'm getting filtered when I try to respond to the original thread.
This is an important issue: If a writer holds the lock for a significant time
(e.g., refreshing a table from a database), do all would-be readers spin-loop,
or is it a hybrid spin-then-sleep solution? We should know this for certain.
Busy-loop is a no-go, at least without some non-default build-time option (or
in later releases, a _ex() form of the create API which allows the flavor to be
selected).
apr-rwlock-AprMutex.patch
Description: Binary data
