Review request 6543863, 6429910, 6814948, 6822643

[Alan Bateman]

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.