On Tue, Apr 20, 2010 at 5:07 AM, Bert Huijben <b...@qqmail.nl> wrote: >> -----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?
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.
