RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile

Claes Redestad claes.redestad at oracle.com
Mon Oct 8 20:31:40 UTC 2018


there's been a history of deadlocks when attempting to close() various 
streams which predates OpenJDK bug and source history, so I believe 
having close synchronize on this is a bad idea. This move from 
AtomicBoolean to a volatile for signaling should be semantically neutral 
and more or less partially back-tracks some more recent changes[1]. 
You're of course free to attempt a better solution!


[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/655c81c02331

On 2018-10-08 21:35, Bernd Eckenfels wrote:
> 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

More information about the core-libs-dev mailing list