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

[Brian Burkhalter]

On Jan 30, 2018, at 12:58 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>> The proposed fix is:
>> 
>> http://cr.openjdk.java.net/~bpb/8166253/webrev.03/<http://cr.openjdk.java.net/%7Ebpb/8166253/webrev.03/>
>> 
> I think it would be simpler if FileChannel maintained a set of the valid locks obtained via the channel, the the unlock can remove the lock from the set.


I don’t see how to do this. The FileLock already holds a reference to the Channel and if the converse were to obtain there would be circular references and things blocked from being collected. I did however come up with a simpler change which passes the new test:

http://cr.openjdk.java.net/~bpb/8166253/webrev.04/

More comprehensive testing would need to be done if this looks better.

On Jan 30, 2018, at 2:16 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Should fileKey be made final (AFAICS the field
> is never mutated) and should isLockReleased
> be volatile (appears that it could be mutated/read
> from different threads)?

Fixed in the above webrev.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180130/a2c56df5/attachment-0001.html>