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

[Roger Riggs]

Hi ALan,

Looks fine as a straightforward replacement of synchronized.

SocketChannelImpl.java: 764-5: re-wrap like 777?

Regards, Roger

Alan Bateman wrote:
>
>
> 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