8222774: (ch) Replace uses of stateLock and blockingLock with explicit locks

[Alan Bateman]

In JDK 11 we changed most of the locking in the network channels to use 
explicit locks in preparation for a future world of user-mode threads 
[1]. I'd like to do another round of update in this area to change the 
stateLock to an explicit lock and also re-visit the implementation of 
the socket adaptors that currently make use of the channel blockingLock.

The motivation for changing stateLock is that closing a channel is a 
blocking operation when it must coordinate the close with threads that 
are blocked in I/O operations on the channel. Changing this to an 
explicit lock it a simple translation although it touches a lot of 
places. As part of this the closeLock used in 
AbstractInterruptibleChannel also needs to be changed.

The changes to support the socket adaptors is a bit trickery. Timed 
connect/accept/read (via the adaptors) require the underlying socket to 
be temporarily changed to non-blocking mode whilst the channel remains 
in blocking mode. In the case of timed read then this should be possible 
while another thread is doing a blocking write - that blocking write 
will happen while the underlying socket is in non-blocking mode. To keep 
it simple, and avoid another round of changes later, all the blocking 
operations are changed so that they can work even if the underlying 
socket is non-blocking.

While re-visiting the socket adaptors I spotted several issues/bugs that 
have not been reported. I'll create issues to follow-up on those. 
However in passing, there are a few small changes to the socket adaptor, 
one of which is to create each socket adaptos with a dummy SocketImpl. 
Michael McMahon is working on JDK-8216978 [2] to drop support for pre 
JDK 1.4 SocketImpls - if that change gets rid the annoying references 
from the SocketImpl to the enclosing Socket/ServerSocket then it will 
allow all socket adaptors to share a dummy SocketImpl.

The existing tests provide reasonable coverage of the changes. The only 
area that wasn't tested (as it never really worked) is concurrent use of 
the input and output streams obtained from a socket adaptor. The new 
test attempts to exercise all the possible scenarios.

There are two items that aren't addressed in this webrev:

1. DatagramSocket's socket adaptor. The send/receive methods defined by 
legacy DatagramSocket synchronizes on the datagram packet. It requires 
further investigation although I suspect it may not be feasible to do 
anything here for compatibility reasons.

2. Interrupting a thread blocked in I/O operation will close the channel 
so that makes Thread.interrupt a blocking operation. The changes for 
this to play well with user mode threads touches other areas so I'll 
separate that out for now.

The webrev with the proposed changes is here:
    http://cr.openjdk.java.net/~alanb/8222774/0/webrev/index.html

-Alan

[1] 
https://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004683.html
[2] https://bugs.openjdk.java.net/browse/JDK-8216978
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190422/496202fa/attachment.html>