Biased locking Obsoletion

[dean.long at oracle.com]

Does wrapping the while loop with

synchronized (newContent) {

synchronized (oldContent) {

...

}

}

allow lock coarsening to work in this case?

dl

On 10/20/22 6:00 AM, Andrew Dinn wrote:
> 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
>