Loom And Synchronized

[Ron Pressler]

There is no conflict, just work that hasn’t been done yet.
We hope to eventually allow monitors (synchronized) to not pin the virtual threads, and I think 
it’s better to work on that than on some stop-gap measures.

— Ron


> On 6 Apr 2022, at 15:41, Jonas Nordin <jonas.j.nordin at gmail.com> wrote:
> 
> Hey fellow threaders. I've got an idea about how to possibly avoid some of
> the rewriting due to the 'conflict' between how Loom is implemented, and
> the 'synchronized' monitor mechanism.
> 
> The basic idea is simply to introduce a 'Synchronizable' interface type.
> This type might look something like this:
> 
> public interface Synchronizable {
>   AutoCloseable enterSynchronization();
> }
> 
> and, then modify compilers to check for this type in 'synchronized'
> constructs, and simply emit code similar to a try-with-resources block.
> Shouldn't be a complicated transformation. So then, types used in
> 'synchronized', can be slightly modified to not use monitors, but
> ReentrantLock or whatever is recommended instead.
> 
> The standard library might also supply a base class, maybe
> 'ReentrantSynchronizable'.
> 
> Now that I think about this, I realise this won't be exactly
> backwards-compatible, but, for older compilers, the old synchronized kicks
> in (not recognizing the 'Synchronizable') and should work the same (unless
> the 'enterSynchronization()' method is buggy), and that will only be used
> with older Java code, for which Loom is not used anyway.
> 
> Well that's the idea. Maybe it's been suggested before. What do you think?