8012019: (fs) Thread.interrupt triggers hang in FileChannelImpl.pread (win)

[Chris Hegarty]

Nice fix Alan, and it really cleans up the commonly unused and confusing 
lock argument.

-Chris.

On 17/04/2013 13:05, Alan Bateman wrote:
>
> The FileChannel read/write methods that take a position are currently
> synchronized on Windows due ReadFile/WriteFile changing the global file
> position. This is something that will need to be looked again because it
> is a long standing (since jdk1.4) scalability issue.
>
> In the mean-time, it turns out that there is potential for deadlock on
> Windows when a position sensitive method is interrupted at around the
> time that a position insensitive method is executing. It's been there
> for some time but only reported recently. The problem is that a position
> sensitive method has the positionLock and if interrupted will close the
> channel causing it to wait until all threads have finished their I/O
> operations. With position insensitive methods then the positionLock is
> acquired as part of the I/O operation, hence the deadlock.
>
> The fix is very simple and just changes the two FileChannel methods to
> acquire positionLock (if needed) before doing the I/O operations. This
> means dropping the lock parameter from the IOUtil read/write methods so
> there are more files changed that might be obvious. The webrev with the
> changes is here:
>
> http://cr.openjdk.java.net/~alanb/8012019/webrev/
>
> -Alan.