Biased locking Obsoletion

[Andrew Dinn]

On 20/10/2022 13:01, Alan Bateman wrote:
> A general point is that you are more likely to see this with the java.io 
> APIs because they date from early JDK releases where they was a tenancy 
> to synchronize everything. The synchronization is not specified and for 
> most of these classes it just doesn't make sense to have several threads 
> reading from a stream. However, there is 25+ years of usage, and there 
> is concurrency if there is async close, so it would not be easy to just 
> remove it. The DataOutputStream change that you linked to was okay 
> because the class wasn't thread safe already and part of the change was 
> to add a disclaimer on thread safety to the javadoc.

Yes, I realise this is a very unfortunate legacy issue and advised our 
customer of that.

> I don't know know which JDK release was used for the test but BIS 
> changed in JDK 19 to use j.u.concurrent locks when a BIS is constructed 
> directly. It may be that it could be changed further to use a stamped 
> lock but it would it would requires exclusive access. Just mentioning 
> this because I think lock coarsening is monitors only (BIS does use 
> monitors when subclassing as existing code may assume synchronization in 
> the super class).
Yes, understood -- indeed, Aleksey Shipilev just explained that to me in 
a separate, off-list email exchange. I also just noticed that the cited 
example is tricky to handle even on a JVM that precedes the switch to 
j.u.c locks because execution involves repeated, alternate 
synchronization on two different BIS instances.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill