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:25:00 GMT
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)





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


View raw message