Bug: SelectionKey.interestOps ignores interestOps on Windows

[Frank Ding]

Hi guys,
   There is a bug in nio selector on Windows which is reported by bug 
4863822 (closed now) and 6429204 (open).

   The issue happens on Windows, where two threads, one doing a channel 
registration/deregistration with a selector and the other setting 
interestOps on one of the channels registered to the selector.
   The thread doing select() goes eventually to 
WindowsSelectorImpl.implDereg() that rearranges SelectionKeyImpls in 
array channelArray and then adjusts entries in pollWrapper.  Since 
implDereg method does not synchronize rearrangement of channelArray and 
accessing pollWrapper, the other thread calling interestOps has a 
possibility of updating ops on the already deleted fd in the poll array.

   The problem can be manifested by the test case in the webrev review 
[1].  The test loops a large number of times in thread 1 trying to 
change interest set for a SelectionKey.  The other thread(main thread) 
should be able to sense the change and notify thread 1 within a short 
period of time.  I admit that the test is not deterministic, which means 
it has a chance to pass with current JDK.  I think it would be better 
having a bootstrapped class to reproduce the problem in a stable way but 
don't have any idea whether jtreg can achieve this.
   Solution to the problem is quite straightforward.  See patch in [1].  
Simply extending closeLock sync scope from implRegister, putEventOps, 
implClose to implDereg.  I have concern on the scope of lock closeLock.  
In the patch I provided, I put synchronized(closeLock) within if 
statement.  This resolves the issue and also minimizes the potential 
performance degradation. However, in class WindowsSelectorImpl, 
closeLock should protect other variables such as totalChannels, fdMap, 
keys and selectedKeys.  So would it make more sense to increase scope to 
before deregister(ski) call?

   Thanks in advance for any comments and review offered.

[1] http://cr.openjdk.java.net/~dingxmin/6429204/webrev.00/

Best regards,
Frank