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).