RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile
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.
You're of course free to attempt a better solution!
On 2018-10-08 21:35, Bernd Eckenfels wrote:
> 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)
More information about the core-libs-dev