Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.160.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=gr2hQPLnSPx5K39hNBjLLVXtaD5kPkFzKScRTOoZaSZQtIq+K75wBt7n8BkhXPvfTC
         AnlDWI9j9z1nhodjd/epQ0wO+UXBXyCA3iI4/SG3S+GH0TluUJggKi3+gHHrSXTU6uB3
         vGnbPXBojBVNXd7EEXo7XhszYv4xVdUJjZPS0=
MIME-Version: 1.0
In-Reply-To: <002c01cae068$d7e5e970$87b1bc50$@qqmail.nl>
References: <002c01cae068$d7e5e970$87b1bc50$@qqmail.nl>
Date: Mon, 26 Apr 2010 15:19:13 -0400
Message-ID: <s2tcc67648e1004261219qdb99e608p4d9a408e3b4c545@mail.gmail.com>
Subject: Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
From: Jeff Trawick <trawick@gmail.com>
To: APR Developer List <dev@apr.apache.org>
Cc: Bert Huijben <bert@qqmail.nl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 20, 2010 at 5:07 AM, Bert Huijben <bert@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: vrijdag 16 april 2010 17:28
>> To: dev@apr.apache.org
>> Subject: Why does apr_file_read() with !APR_XTHREAD on Windows
>>
>> =A0 =A0 =A0 Hi,
>>
>> While profiling subversions file usage performance on Windows, one major
>> slowdown shows:
>>
>> When a file is opened with APR_BUFFERED on Windows all read and file
>> operations are slowed down by a mutex (or actually a critical section),
> even
>> though the function is not documented to be thread safe unless you use
>> APR_XTHREAD.
>>
>> I'm trying to find out why this is implemented this way on Windows, but
> not
>> on the other platforms.
>>
>> * Are all file operations supposed to be slow but thread safe on Windows=
?
>> * Or is this just to cover up old compatibility issues in other systems.
>> (httpd defaults to threading on Windows)
>> * Can we change this without breaking backwards compatibility?
>> (I'm willing to write patches, etc.)
>> * Or is it a better route to add a new flag that disables this mutex
> around
>> the buffering.
>>
>> Looking at the subversion history of this mutex, I found that it was
>> introduced in r60083 (may 2000) and the documentation on why the mutex
>> was
>> added is nonexisting.
>>
>> Going forward ten years since that revision, we got hyperthreading and
>> multicore systems and the critical section which used to be fast
>> (implemented as an interlocked exchange) is now much slower because it
>> has
>> to perform actual CPU and caching synchronization.
>>
>>
>> I would like to remove this performance penalty of using the mutexes for
>> Subversion (which explicitly documents that you can't use its instance
>> objects in multiple threads at the same time)... What are the recommende=
d
>> steps I should take?
>
> Ping. No response at all in this thread.
>
> Any suggestions on what steps to take to reduce the slowdown?

Does this look right based on your research?

The mutex was added when buffered files were introduced here:

http://svn.apache.org/viewvc/apr/apr/trunk/file_io/win32/readwrite.c?diff_f=
ormat=3Dh&r1=3D60082&r2=3D60083&

(That may be before the xthread flag was introduced.)

The Unix code was changed here to get that mutex only if XTHREAD was reques=
ted:

http://svn.apache.org/viewvc?view=3Drevision&revision=3D63133

but the Windows code wasn't changed at the same time.

So I don't think there's any hidden "reason" why a mutex should always
be obtained on Windows.  I too wouldn't be surprised if the fix breaks
some app code somewhere.

My 2cents: Leave alone for old branches up through and including
1.3.x.  Fix on trunk and newer branches.