apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Tue, 20 Apr 2010 09:07:02 GMT
> -----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),
> though the function is not documented to be thread safe unless you use
> I'm trying to find out why this is implemented this way on Windows, but
> 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
> 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?


> (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

View raw message