We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
1–10 of 253 posts
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#2Java 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.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#3"Why not to use java virtual threads" -> Fundamental features of the language treated as implementation details in libraries for more than two decades cause deadlock.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#4Did they get a deadlock again? https://news.ycombinator.com/item?id=38939165
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#5Java 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.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#6Java 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".
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#7"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 thread instead of delving inside c3p0. Thus, we never block inside c3p0 because we enter c3p0 code only when there is a free session available."
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#8Did they get a deadlock again? https://news.ycombinator.com/item?id=38939165
Haha, but quite frankly we had one more in TPC-C for YDB. But unrelated to the virtual threads.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#9Java 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 issue here is currently virtual threads don't work well with the 'sychronized' keyword. Right now synchronized will pin the carrier thread. The fix was to switch to a higher-level abstraction that works with virtual threads.
My understanding is there is work to make synchronized not pin the carrier thread, but that's some pretty complex and important code to change.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#10It is a known caveat that virtual threads do not work well with long running synchronization by pinning the thread. That unfortunately means that for many applications it may be premature to adopt them, but it is mature enough for broader evaluation by the libraries and frameworks. The Java team provided a status of their efforts recently [1].