Code review request 7132889: Possible race conditions in AbstractSelectableChannel

[Alan Bateman]

On 14/08/2012 03:19, Shirish Kuncolienkar wrote:
>
> I see that regLock is not limited to blocking mode. Many places the 
> keyLock is acquired while the regLock is held.
It guards the blocking mode, and may have been clearer if it were named 
blockingLock. Locking regLock and keyLock (in that order) should be 
fine, just not in implCloseSelectableChannel because you need to be able 
to invoke close when there is a blocking operation in progress.

> If we do not guard the implCloseSelectableChannel() and key 
> cancellation within the regLock we would not be able to avoid a key 
> being added while a channel is closed. Do you think such a behavior 
> should be documented ?
> I will run the channel tests as suggested by you.
Yes, it would be great if you could run the tests with your patch as I 
am concerned that it will break asynchronous close causing several tests 
will either hang or deadlock.

I think the residual issue with register returning a valid key can be 
solved by checking the channel status when holding the keyLock, eg:

synchronized (keyLock) {
     if (!isOpen())
         throw new ClosedChannelException();
     addKey(k);
}

and change addKey to assert Thread.holdsLock(keyLock);

So I'm curious as to the background to this issue, is this a patch that 
you have in the IBM JDK?

-Alan.