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 [mailto:b...@qqmail.nl]
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:traw...@gmail.com]
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).
