apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject Why does apr_file_read() with !APR_XTHREAD on Windows
Date Fri, 16 Apr 2010 15:28:05 GMT
	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?

(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


Mime
View raw message