[flagged]
We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
11–20 of 253 posts
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#12Java virtual threads did not cause a deadlock here. The deadlock was a usage error. A better title would be: Naively switching to Java virtual threads caused a deadlock in TPC-C for Progress SQL.
I would like to reply with a quote of sir Tony Hoare's 1980 ACM Turing Award Lecture: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies".
This one was a very large caveat pointed out loudly every time the feature was mentioned to the community. So, yes the limitation/flaw was very well known and is ideally going to be addressed in a future JDK release.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#13Java virtual threads did not cause a deadlock here. The deadlock was a usage error. A better title would be: Naively switching to Java virtual threads caused a deadlock in TPC-C for Progress SQL.
Article won’t load for me. My understanding was that the switch to virtual was supposed to be relatively simple, allowing the programmer to be naive. But a user deadlock is a user deadlock, no matter the threading impl.
The adoption guide tells you not to switch to virtual threads just for their own sake. They're not meant as a straight replacement for OS threads.
https://docs.oracle.com/en/java/javase/21/core/virtual-threa...
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#14Concurrency, parallelism. These are among the most misunderstood concepts in programming/software development.
TLS (especially mutual TLS) and Oauth also join this club.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#15"Our PostgreSQL TPC-C implementation utilizes c3p0 for connection pooling...The problem is that...synchronized code might be deeply embedded within the libraries you use. In our case, it was within the c3p0 library. So, the fix is straightforward: we simply wrapped the connection with a java.util.concurrent.Semaphore. With this change, virtual threads are blocked on the semaphore and, crucially, release the carrier t…
[deleted]
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#16Earlier quoted context omitted.
Article won’t load for me. My understanding was that the switch to virtual was supposed to be relatively simple, allowing the programmer to be naive. But a user deadlock is a user deadlock, no matter the threading impl.
The adoption guide tells you not to switch to virtual threads just for their own sake. They're not meant as a straight replacement for OS threads. https://docs.oracle.com/en/java/javase/21/core/virtual-threa...
No mentions of deadlocks. Just this:
> Pinning does not make an application incorrect, but it might hinder its scalability.
The documentation is wrong.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#17Curious if you considered switching to a different connection pooling library. These days I usually use HikariCP which is fast an actively maintained. c3p0 hasn't had any activity for years, I'm not sure if it's still maintained.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#18This is a common problem when migrating a system from threads to virtual threads. In general, using primitives which block the current thread and prevent forward progress can quickly lead to deadlocks. It’s a hard issue to catch because in the past usually this would get “solved” by spawning a new thread to complete the task but in a world with virtual threads the runtime is usually reluctant to spawn more threads, so there’s nothing that can service more work if you’ve blocked all the threads.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#19Erlang is based on virtual threads (confusingly called processes).
The Erlang virtual machine schedules them on OS threads.
Erlang processes communicate using message passing, preventing deadlocks.
You can use millions of Erlang processes without problems, e.g., to handle millions of Elixir LiveView sessions.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#20Earlier quoted context omitted.
The adoption guide tells you not to switch to virtual threads just for their own sake. They're not meant as a straight replacement for OS threads. https://docs.oracle.com/en/java/javase/21/core/virtual-threa...
No mentions of deadlocks. Just this: > Pinning does not make an application incorrect, but it might hinder its scalability. The documentation is wrong.
Yes, it is. That’s because their discussion of pinning is incomplete: it needs to mention forward progress.