> -----Original Message-----
> From: Bert Huijben [mailto:b...@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?
Bert
>
> (Another option would be to write a small direct file access layer in
> Subversion to fix only this case; but I think there are more projects that
> like to see this fixed)
>
> Bert
