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

[Alan Bateman]

On 05/02/2018 17:00, Pavel Rappo wrote:
> 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.
The async close of these Pipe source/sink classes has been incorrect 
since 1.4. It will be fixed in a follow-up patch that re-works the async 
close where it will be clearer why the isOpen must be checked while 
holding the readLock.

-Alan