8196787: (ch) Moving network channels to use j.u.c locks

[Pavel Rappo]

It's not immediately obvious why the ensureOpen method went into the critical
section in SinkChannelImpl (x2):

   161     public int write(ByteBuffer src) throws IOException {
   162         writeLock.lock();
   163         try {
-> 164             ensureOpen();

and in SourceChannelImpl (x2)

     161     public int read(ByteBuffer dst) throws IOException {
     162 
     163         readLock.lock();
     164         try {
->   165             ensureOpen();

From what I can see in the ensureOpen body, the close field doesn't seem to be
guarded by neither of those locks, on the other hand the visibility is fully
ensured by the close field being volatile. I feel like I definitely missing
something though.

> On 5 Feb 2018, at 16:27, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> I have a number of patches in the works that re-work some of the locking in the NIO networking channels and also split the blocking and non-blocking code paths. Part of the motivation is the complexity/overhead dealing with async close and interrupt of blocking operations, another part is preliminary work to prepare the implementations for fibers.
> 
> To get started, I'd like to replace the read/write locks used in the networking channels to use j.u.c. locks. The changes are easy to review:
>    http://cr.openjdk.java.net/~alanb/8196787/webrev/
> 
> There are a few small clean-ups in the patch, this is mostly to keep as much noise out of the follow-up changes. The dropping of the ready parameter from the native checkConnect is clean-up as the readyToConnect flag (dates from 1.4) isn't always reliable to use.
> 
> -Alan
>