apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: Windows R/W lock comment
Date Mon, 07 Jul 2014 10:29:18 GMT
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:bert@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:trawick@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).

 


Mime
View raw message