[9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock

[Alan Bateman]

On 01/02/2018 01:56, Brian Burkhalter wrote:
>
> I created and tested an updated version which maintains a set of hard 
> references to the locks for the channel inside the FileLockTable itself:
>
> http://cr.openjdk.java.net/~bpb/8166253/webrev.05/ 
> <http://cr.openjdk.java.net/%7Ebpb/8166253/webrev.05/>
>
> Given that the set is always accessed inside a block synchronized on 
> the list corresponding to the FileKey in the global 
> FileKey-to-FileLockReference table, I think the Set could probably be 
> initialized at line 124 to a simple HashSet instead of a 
> ConcurrentHashMap.KeySetView<FileLock,Boolean> but I wanted to solicit 
> comments on that point.
>
Yes, it can be a HashSet. Also in the case of removeAll then you can 
invoke locks.clear(). In the case of replace then I think it would be 
more understandable if the remove+add are together.

-Alan