Review request 6543863, 6429910, 6814948, 6822643

[Xueming Shen]

approved.

Alan Bateman wrote:
> Sherman, this is your locky day :-) 
>
> 6543863: (fc) FileLock.release can deadlock with FileChannel.close
>
> This is a long-standing deadlock (since 1.4) that can happen when 
> closing a FileChannel and releasing a FileLock (obtained from the 
> channel) at around the same time. Closing locks the FileLock while 
> synchronized on the list of file locks; Release locks the list while 
> holding the FileLock. The cycle is broken by changing the removeAll 
> method to remove and return the list of the channel's file locks.
>
>
> 6429910: (fc) FileChannel.lock() IOException: Bad file number, not 
> AsynchronousCloseException
>
> If the FileChannel#lock method is blocked waiting to acquire a lock on 
> the channel's file and the FileChannel is closed then the lock method 
> fails with IOException "Bad file number" whereas it is should throw 
> AsynchronousCloseException. The end method, marking the end of the I/O 
> operation was being invoked with true instead of false and so wasn't 
> suppressing the I/O operation.
>
>
> 6814948: (fc) test/java/nio/channels/AsynchronousFileChannel/Lock.java 
> failed intermittently
>
> The asynchronous close sub-test fails intermittently (about 1 per 1000 
> runs on the machines I tried). It's a timing issue that arises if the 
> preclose is done before the lock attempt, in which case it will appear 
> the file has been acquired (but the channel is closed). The lock and 
> tryLock methods were missing an isOpen check.
>
>
> 6822643: (fc) AsynchronousFileChannel.close does not invalidate FileLocks
>
> This is an embarrassing one. The close method attempts to release and 
> invalidate all locks but the "shared" FileLockTable removeAll 
> implementation checked the lock's channel using lock.channel() instead 
> of lock.acquiredBy() (and hence only worked for FileChannel).
>
>
> The webrev is here:
>  
> http://cr.openjdk.java.net/~alanb/6543863%2b6429910%2b6814948%2b6822643/webrev.00/ 
>
>
> Thanks,
> Alan.
>
>
>
>
>
>
>
>
>
>