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

Post by Groxx » Tue, Jan 16, 2024, 7:25 AM UTC

lmm wrote: post #76

Groxx wrote: post #34

Earlier quoted context omitted.

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…

Java's virtual threads are supposed to be a drop-in replacement for real threads. But using virtual threads means you get a far smaller number of real threads, and things that were safe back when you had an unlimited number of real threads available (or at least, a larger number than your database connection pool) are no longer safe.

Post by gcau » Tue, Jan 16, 2024, 7:34 AM UTC

mrintegrity wrote: post #56

Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have

Post by samus » Tue, Jan 16, 2024, 7:40 AM UTC

Groxx wrote: post #39

saagarjha wrote: post #18

This 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, s…

Is that all that's happening here? There's an implicit limit on real threads, where before it was unlimited by virtue of not using the virtual thread's limited pool? If it doesn't spawn threads when all of them are blocked, that seems kinda dumb. And a severe change in semantics. It can be conservative and try running unpinned ones on fewer threads and shuffle them around and slowly spawn more to ensure eventual prog…

Post by Tomte » Tue, Jan 16, 2024, 7:44 AM UTC

minimaxir wrote: post #67

dmart wrote: post #59

Earlier quoted context omitted.

Not really. I wish the trend of giant generic hero images on every blog post would go away, they almost never add any value. I think it was Medium that started the trend.

Unfortunately all social media sharing requires a thumbnail for easy clicking, no real way around it. (with Hacker News as the lone exception of course) The default thumbnails in lieu of your own aren't good.

Post by samus » Tue, Jan 16, 2024, 7:52 AM UTC

dikei wrote: post #52

moonchild wrote: post #50

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?

No, synchronized is a very primitive lock implementation compared to what's available in java.util.concurrent.Locks. However, it's built directly into the JVM specification, so it's difficult to change while keeping compatibility, while j.u.c.Locks is just a library. In other words, they can't change synchronized schematic, so they created j.u.c.Locks as a replacement.