Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 3 Sep 2001 21:42:34 -0700
From: Aaron Bannert <aaron@clove.org>
To: dev@apr.apache.org
Subject: Re: [PATCH] new lock APIs, rwlocks, condition variables
Message-ID: <20010903214234.D6340@clove.org>
References: <20010903210824.C6340@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010903210824.C6340@clove.org>;
 from aaron@clove.org on Mon, Sep 03, 2001 at 09:08:24PM -0700

On Mon, Sep 03, 2001 at 09:08:24PM -0700, Aaron Bannert wrote:
[...]
>  - I've spent the entire weekend testing this code, and although I can't
>    yet say it's as fast (2-5% slower) as the old code (some places are
>    still lagging, haven't figured out why), I would not be posting it
>    here unless I was confident enough in it's functional correctness
>    for public review.
[...]
>  - From my rather extensive testing, this is in my opinion as functional
>    as the old apr_lock_t api. I have tested the new functions in modified
>    httpd-2.0 and found them to operate correctly (although surprisingly
>    slightly slower in the various MPMs :( I'm still working though -- and
>    with this patch we get more eyes staring at the code).
> 
>  - As a side effect I've found a way to speed up a thread_mutex a wee bit.
[...]

Just a point of clarification: I have every expectation that the new lock
API will indeed be faster. In my own performance tests using the new
lock code, it is operating faster. When I say "slower" above, I should
have said that in my changes to httpd-2.0 to implement the new locks,
I was seeing a reduced requests/second rating. I expect this to go away
when all the kinks are worked out of the API.

It implementation should be identical to the old API, with a small number
of the function pointers removed, with some other small performance fixes.

-aaron