apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: [Patch] R/W lock slowness on Windows (Was: Windows R/W lock comment / Reader Writer lock performance on Windows)
Date Sun, 03 Aug 2014 22:27:46 GMT
On 2 August 2014 13:02, Bert Huijben <bert@qqmail.nl> wrote:
>         Hi,
>
> With this mail I would like to ping the original problem with the second
> patch I send to the list. This patch doesn't have the likely original
> problems of potentially changing the lock behavior to a spin lock, but
> provides all the performance improvements anyway.
>
> It just replaces the Windows inter-proces mutex in the apr code with the
> already existing apr-mutex implementation, which is usually implemented as
> the far more efficient Windows in-process Critical section.
>
> This makes the implementation 10* to 140* times more efficient on Windows
> and more similar to the performance on other platforms. A performance fix
> like this is critical for Subversion, or we would have to implement our own
> r/w locking implementation for our caching infrastructure.
>
Hi Bert,

Comments on your patch:
1. It seems behavior of apr_thread_rwlock_create() functions changes a
bit: code in trunk intializes output *rwlock pointer to NULL in case
of error, while your patch returns pointer to partially initialized
object. It seems that apr_thread_rwlock_create() doesn't have API
promise to initalize output to NULL, but I think it's better to leave
current behavior.

2. The apr_thread_rwlock_unlock() currently uses checked mutex
behavior for its logic. This is possible reason why current rwlock
implementation uses OS mutexes instead of cirtical sections. I don't
see problem with proposed change  though.


-- 
Ivan Zhakov

Mime
View raw message