apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Mon, 26 Aug 2013 14:58:21 GMT
On Mon, Aug 26, 2013 at 6:43 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On Sat, 24 Aug 2013 00:33:38 +0400
> Ivan Zhakov <ivan@visualsvn.com> wrote:
>> >
>> > Append is special, in that POSIX has an append flag on open() which
>> > handles atomicity of seek-to-end+write; so that mutex isn't needed
>> > on all operating systems.  This is a case where Windows needs a
>> > mutex but Unix doesn't.
>> Actually Windows supports atomic seek-to-end+write: file should be
>> opened with FILE_APPEND_DATA access right only [1] or Offset and
>> OffsetHigh should be 0xFFFFFFFF if overlapped I/O is used [2].
>> I'm reopening this thread because in Subversion we found case where we
>> need true atomic append across processes/threads. So I'm willing to
>> create a patch implementing atomic append on Windows. Is right idea
>> for APR or not? Any concerns will be very helpful.
>> [1]
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363778%28v=vs.85%29.aspx
>> [2]
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365747%28v=vs.85%29.aspx
> This is even worse than I thought...
> 1. we aren't protecting segments of writev within the apr_file_writev
>    call with the mutex (as Ivan notes)
> 2. the mutex is used for buffered output (which makes sense, if
>    you have multiple threads with the same apr_file_t context which
>    write to the same buffer...)
> 3. The mutex -> file lock looks backwards and we release the mutex...
>    it is a complete mess.
> 4. If the file lock doesn't support nested locks (have yet to check)
>    then this whole code path is foobar for anyone using the file lock
>    API within their own code (as would be appropriate for complex
>    write operations).
> 5. On failure we use pOverlapped with a thread-shared overlapped IO
>    structure and hEvent signal.  This is not unique per-thread and is
>    clearly a design error if we pass this without holding the mutex.
> I need to go a decade back in svn to pick up the initial principals
> and we need to recode both write and writev appropriately.
> If opened for append, unbuffered, non-xthread then I can see us finding
> our way to the atomic write-for-append method on unix and windows.  But
> that method will force us to create the overlapped and hEvent on each
> call to write to ensure they are unique per-thread, slowing things down
> considerably, in the write failure case.
Alternative solution would be take file->lock mutex on write operation
and user shared OVERLAPPED structure. Also note that MSDN states that
opening file with FILE_APPEND permissions only will perform atomic
move-to-end + write without overlapped I/O.

Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

View raw message