Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

blog.ydb.tech

Post reply on HN
Print view View original

21–30 of 253 posts

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#21

Post by saagarjha »

NovaX wrote: post #10

It 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]. https://www.youtube.com/watch?v=WoQJnnMIlFY&t=421s

The problem is not “long running synchronization” but synchronization that relies on stuff running outside of virtual threads to unblock itself. There is no issue beyond performance if you perform filesystem operations in your mounted state.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#22

Post by NovaX »

saagarjha wrote: post #21
NovaX wrote: post #10

It 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]. https://www.youtube.com/watch?v=WoQJnnMIlFY&t=421s

The problem is not “long running synchronization” but synchronization that relies on stuff running outside of virtual threads to unblock itself. There is no issue beyond performance if you perform filesystem operations in your mounted state.

Yeah, I wasn’t being particular about this exact issue and was generalizing about synchronization pinning the carrier. A deadlock is trivial once the implications of that are thought through.

https://mail.openjdk.org/pipermail/loom-dev/2023-July/005993...

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#23

Post by Jtsummers »

jake_morrison wrote: post #19

Erlang 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.

You can have deadlock in Erlang, it's just a bit harder. It happens when two processes are both waiting on the other to send them a message which is analogous to two threads each waiting for a mutex the other holds. The same thing can happen in Go with its channels, another message passing based concurrency control mechanism.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#24

Post by koolba »

shermantanktop wrote: post #5
oldgradstudent wrote: post #2

Java 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.

This has nothing to do with postgres though. It’s part of a generic JDBC connection pool:

> The problem is that this 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.

I bet if you just checked out connections and slept a random amount of time you’d have the same problem.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#25

Post by FridgeSeal »

hn_throwaway_99 wrote: post #11

[flagged]

I’ve come to see a lot of ai generated images as a proxy for effort, or care, and whenever I see them, my first thought is mostly “the author doesn’t care enough to make an effort about the presentation of their post”.

Same reason I stopped using GitHub copilot to write PR bodies, I had a teammate say “I know you didn’t put any effort or thought into writing it,so why should I bother reading it?” Which I resonate with.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#26

Post by jfengel »

FridgeSeal wrote: post #25
hn_throwaway_99 wrote: post #11

[flagged]

I’ve come to see a lot of ai generated images as a proxy for effort, or care, and whenever I see them, my first thought is mostly “the author doesn’t care enough to make an effort about the presentation of their post”. Same reason I stopped using GitHub copilot to write PR bodies, I had a teammate say “I know you didn’t put any effort or thought into writing it,so why should I bother reading it?” Which I resonate wit…

I'm reminded of the way expensive restaurants use very simple descriptions, while less expensive ones load them up with superlatives and (uninformative) adjectives. The high end is confident enough that you assume it will be good.

The AI art assumes you need art to think that they've put in effort. More confidence would allow for simplicity.

But I cannot say if that confidence would be well placed. For all I know people really do think the art adds class.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#27

Post by eivanov89 »

FridgeSeal wrote: post #25
hn_throwaway_99 wrote: post #11

[flagged]

I’ve come to see a lot of ai generated images as a proxy for effort, or care, and whenever I see them, my first thought is mostly “the author doesn’t care enough to make an effort about the presentation of their post”. Same reason I stopped using GitHub copilot to write PR bodies, I had a teammate say “I know you didn’t put any effort or thought into writing it,so why should I bother reading it?” Which I resonate wit…

I would suggest looking at it from another perspective. Writing a text that precicely describes the image you want might require a lot of effort. Crafting this text to get as close as possible to the imagined picture also requires effort. Also, consider that some people can't draw (I also can't sing), but can write. AI gives a nice opportunity to add some color and visual humor, which is, in my humble opinion, great. But no doubt there are many examples of AI misusage (or overusage), which match your description.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#29

Post by eivanov89 »

jfengel wrote: post #26
FridgeSeal wrote: post #25

Earlier quoted context omitted.

I’ve come to see a lot of ai generated images as a proxy for effort, or care, and whenever I see them, my first thought is mostly “the author doesn’t care enough to make an effort about the presentation of their post”. Same reason I stopped using GitHub copilot to write PR bodies, I had a teammate say “I know you didn’t put any effort or thought into writing it,so why should I bother reading it?” Which I resonate wit…

I'm reminded of the way expensive restaurants use very simple descriptions, while less expensive ones load them up with superlatives and (uninformative) adjectives. The high end is confident enough that you assume it will be good. The AI art assumes you need art to think that they've put in effort. More confidence would allow for simplicity. But I cannot say if that confidence would be well placed. For all I know peo…

Your comparison is indeed thoughtful. I would note a counterexample, though: an expensive restaurant with a very simple description gives no guarantee that you will be delighted, while some inexpensive places (possibly with basic ads) might offer something very delightful.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#30

Post by eivanov89 »

papercrane wrote: post #17

Curious 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.

Perhaps we'll give HikariCP a chance. However, please keep in mind that the goal of the YDB team is to enhance database performance. We needed virtual threads to make TPC-C efficient enough to generate a reasonable load on a modest amount of hardware.
Post reply on HN