apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Mon, 26 Apr 2010 19:19:13 GMT
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
>>
>>       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 recommended
>> 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_format=h&r1=60082&r2=60083&

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

The Unix code was changed here to get that mutex only if XTHREAD was requested:

http://svn.apache.org/viewvc?view=revision&revision=63133

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.

Mime
View raw message