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

41–50 of 253 posts

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

#41

Post by MBCook »

jayd16 wrote: post #32
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.

What was the user error? Was there something obvious they did or didn't do or is it a "you're holding it wrong" kind of issue?

c3p0 appears to have been working under the assumption that their threads can always run when whatever they’re waiting on is done. Their only dependency is the OS giving them cycles.

Virtual threads changed the contract a little bit. Now one virtual thread running certain code can prevent a different virtual thread from ever getting any cycles even though they are not dependent on each other in the Java code. It’s a side effect of the current Java implementation.

The rules changed, and it tripped up c3p0. Unless they explicitly said somewhere that they were completely ready for virtual threads I’m not sure anyone is at fault here.

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

#42

Post by mattgreenrocks »

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.

It is hard to be confident whether the entire dependency tree is free of this issue.

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

#43

Post by extractionmech »

Groxx wrote: post #34
papercrane wrote: post #9

Earlier quoted context omitted.

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.

From a relatively brief skim and past Go and Java experience: synchronized blocks the current normal thread, so that doesn't really seem any different to me. If you starve your threads, you starve your threads. It definitely leaves room to optimize by not pinning that thread, which would be great, but that shouldn't change semantics at all. Or is there something actually screwed up in the implementation of virtual th…

It’s a thread that supports n virtual threads. You want synchronized in virtual thread a and not the carrier thread which will block all the virtual threads.

Been away from Java land for a while. How did something like that even get into release? That’s like a pretty big loaded shotgun to leave lying around with lots of kids playing, no?

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

#44

Post by andrewxdiamond »

hn_throwaway_99 wrote: post #11

[flagged]

Is this really that distracting to you that you cannot appreciate the content of the article? Just ignore it. Why are you in charge of how people express themselves on the internet.

We are in the goofy geo-cities days of AI. The art is strange and often illegal. The chatbots are vulnerable to "Grandma attacks". Enjoy the madness before the corpos kill the fun

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

#46

Post by shermantanktop »

schizofunky wrote: post #33

I think i have a more elegant solution for this deadlock: "Switch to haskell".

If serious: that’s dismissive, superior, and a low-effort appeal to Haskell fans.

If not serious: it’s still low effort, but while it is framed as a zinger, it’s not funny at all. I don’t even understand what the humor might be, maybe it’s serious after all.

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

#48

Post by dang »

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.

Submitted title was "Java virtual threads caused a deadlock in TPC-C for PostgreSQL". We've reverted it now to the article's own title (truncated to fit HN's 80 char limit).

"Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html

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

#49

Post by dang »

hn_throwaway_99 wrote: post #11

[flagged]

"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."

https://news.ycombinator.com/newsguidelines.html

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

#50

Post by moonchild »

I am extremely confused.

> There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:

> When it executes code inside a synchronized block or method

Isn't 'synchronized' effectively sugar for taking a kind of lock? Why can't it be treated uniformly by the scheduler?

Post reply on HN