Hello, just noticed it is probably intended to not be synchronized for the reads (since it is volatile)?.
In that case using `this` monitor would also allow to remove the volatile. However not sure if that is good or bad for the Performance (close does not do DCL then anymore, but ist probably not called that often anyway) Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Montag, 8. Oktober 2018 21:28 An: core-libs-dev Betreff: AW: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?). I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse… Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 8. Oktober 2018 21:21 An: Claes Redestad; core-libs-dev Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan
