5 ms·

This is not news, it's documented in the official description of the virtual threads: https://openjdk.org/jeps/444 https://openjdk.org/jeps/444

bilbo0s 3y ago
OK. Good. I’m glad someone else said this, since it means I’m not crazy. I was reading that thinking, man, this sounds like the way it’s outlined to work? Where’s the new issue?
- smaudet 3y ago
  It's news if you are are uneducated about synchronization/threading in general (it's extremely difficult to do well so it stands to reason most people won't even understand the issues). It's also news that they are trying to provide some abstraction to help. Which is great, although as usual I suspect it will need to be applied per situation, not a one-size-fits all.
- CHY872 3y ago
  Nah, it's not normal or really documented. Normally when languages have async, they end up with dual primitives - the synchronous one and the asynchronous one, and everyone learns that if they do the blocking operation on the async thread, they deserve their deadlock. Generally you then end up with two variants of the API, with the standard function colouring problem where you can call lockBlocking() from a non-async context, lockAsync() from an async, and woe betide you if you get mixed up. Ideally your language can help you avoid these issues sometimes (e.g. with Rust you can't hold a non-async lock over await points). Java instead did a big thing where they made all the primitives work fine in both cases with one API, something which is honestly really hard and really reflects the level of thought put into modern Java features. But there's a long tail of stuff that's still getting cleaned up (e.g. various weird I/O apis), and honestly I think it _is_ weird that an actual language keyword made it into the long tail. It's extra fun that it's actually quite hard to hit performance problems as a result of this, as the JVM will actually detect that it's getting to this problem and boot up threads to compensate.
cesarb 3y ago
It's not news only if you carefully read that JEP (and even then, it's misleading, it says "Pinning does not make an application incorrect, but it might hinder its scalability" as if using "synchronized" could only lead to not getting the full performance advantage of virtual threads; there's no mention of potential thread starvation or deadlocks). But most people are not reading JEP pages; most people are getting their information from release notes and news articles, and AFAIK these didn't mention the important caveat that virtual threads can misbehave if anything waits within a synchronized block (which is very common, synchronized blocks and methods exist and are widely used since the early days of Java). For instance, a quick web search led me to a release notes page (https://www.oracle.com/java/technologies/javase/21-relnote-issues.html https://www.oracle.com/java/technologies/javase/21-relnote-i...) and a news article (https://www.infoworld.com/article/3689880/jdk-21-the-new-features-in-java-21.html https://www.infoworld.com/article/3689880/jdk-21-the-new-fea...), neither mention anything about synchronized blocks and methods. In fact, the later one says "Previously previewed in both JDK 20 and JDK 19, virtual threads will be finalized in JDK 21.", as if everything now works as expected with virtual threads on Java 21. Which is clearly not the case, if synchronized blocks are enough to make it misbehave. IMO, we can only say virtual threads are really "finalized" once synchronized blocks work as expected (releasing the carrier thread, like AFAIK ReentrantLock already does) when running on a virtual thread.
- karmakaze 3y ago
  Using "synchronized" by itself and calling anything has the potential thread starvation or deadlocks. Virtual threads only makes it worse. Kotlin has mutexes that presumably are compatible with coroutines: kotlinx.coroutines.sync.Mutex Until Java sorts this out, it could be its "Rust async" watershed moment.
  - DarkNova6 3y ago
    You can use Concurrent Locks from the standard library. And it has been communicated that you should not be using low level concurrency constructs for years. But people just… don’t.

bilbo0s 3y ago

OK. Good. I’m glad someone else said this, since it means I’m not crazy. I was reading that thinking, man, this sounds like the way it’s outlined to work? Where’s the new issue?

smaudet 3y ago
It's news if you are are uneducated about synchronization/threading in general (it's extremely difficult to do well so it stands to reason most people won't even understand the issues). It's also news that they are trying to provide some abstraction to help. Which is great, although as usual I suspect it will need to be applied per situation, not a one-size-fits all.
CHY872 3y ago
Nah, it's not normal or really documented. Normally when languages have async, they end up with dual primitives - the synchronous one and the asynchronous one, and everyone learns that if they do the blocking operation on the async thread, they deserve their deadlock. Generally you then end up with two variants of the API, with the standard function colouring problem where you can call lockBlocking() from a non-async context, lockAsync() from an async, and woe betide you if you get mixed up. Ideally your language can help you avoid these issues sometimes (e.g. with Rust you can't hold a non-async lock over await points). Java instead did a big thing where they made all the primitives work fine in both cases with one API, something which is honestly really hard and really reflects the level of thought put into modern Java features. But there's a long tail of stuff that's still getting cleaned up (e.g. various weird I/O apis), and honestly I think it _is_ weird that an actual language keyword made it into the long tail. It's extra fun that it's actually quite hard to hit performance problems as a result of this, as the JVM will actually detect that it's getting to this problem and boot up threads to compensate.

cesarb 3y ago

It's not news only if you carefully read that JEP (and even then, it's misleading, it says "Pinning does not make an application incorrect, but it might hinder its scalability" as if using "synchronized" could only lead to not getting the full performance advantage of virtual threads; there's no mention of potential thread starvation or deadlocks). But most people are not reading JEP pages; most people are getting their information from release notes and news articles, and AFAIK these didn't mention the important caveat that virtual threads can misbehave if anything waits within a synchronized block (which is very common, synchronized blocks and methods exist and are widely used since the early days of Java). For instance, a quick web search led me to a release notes page (https://www.oracle.com/java/technologies/javase/21-relnote-issues.html https://www.oracle.com/java/technologies/javase/21-relnote-i...) and a news article (https://www.infoworld.com/article/3689880/jdk-21-the-new-features-in-java-21.html https://www.infoworld.com/article/3689880/jdk-21-the-new-fea...), neither mention anything about synchronized blocks and methods. In fact, the later one says "Previously previewed in both JDK 20 and JDK 19, virtual threads will be finalized in JDK 21.", as if everything now works as expected with virtual threads on Java 21. Which is clearly not the case, if synchronized blocks are enough to make it misbehave. IMO, we can only say virtual threads are really "finalized" once synchronized blocks work as expected (releasing the carrier thread, like AFAIK ReentrantLock already does) when running on a virtual thread.

karmakaze 3y ago
Using "synchronized" by itself and calling anything has the potential thread starvation or deadlocks. Virtual threads only makes it worse. Kotlin has mutexes that presumably are compatible with coroutines: kotlinx.coroutines.sync.Mutex Until Java sorts this out, it could be its "Rust async" watershed moment.
- DarkNova6 3y ago
  You can use Concurrent Locks from the standard library. And it has been communicated that you should not be using low level concurrency constructs for years. But people just… don’t.