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

Post by hoseja » Tue, Jan 16, 2024, 10:53 AM UTC

Post by orthoxerox » Tue, Jan 16, 2024, 11:14 AM UTC

Jtsummers wrote: post #23

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.

Post by hoseja » Tue, Jan 16, 2024, 11:24 AM UTC

mort96 wrote: post #148

minimaxir wrote: post #68

Earlier quoted context omitted.

There's a quality spectrum of AI-generated header images. Some are just random DALL-E output which aren't intrinsically relevant to the article (like the one used in this article), but you can have a little fun with it and do something distinct. This may require more control than just using Bing Image Creator. Also, a thumbnail tip: square thumbnails are bad. If you have to use a square 1024x1024 AI generation, crop…

There's a quality spectrum of AI-generated images, sure, but they're all equally artistically void.

Post by Rapzid » Tue, Jan 16, 2024, 11:45 AM UTC

neonsunset wrote: post #57

vvern wrote: post #45

Go has a mechanism to spawn a new thread (m in ho runtime parlance) if it thinks one of its threads might be blocked in a cgo (go’s “native function” equivalent). That prevents stuff like this.

So does C# with active blocking detection (which injects threads to counteract this) and hill climbing algorithm to scale threadpool threads automatically.

Post by avodonosov » Tue, Jan 16, 2024, 12:08 PM UTC

delusional wrote: post #80

avodonosov wrote: post #55

Earlier quoted context omitted.

Java does the same for Object.wait(), only the number of such compensating threads is limited by default, but can be extended via config option. They have exhausted the default number of compensating threads, I think. And they are mistaken to call this situation a "pinning" JEP 444: > The vast majority of blocking operations in the JDK will unmount the virtual thread, freeing its carrier and the underlying OS thread…

> The situation with Object.wait() is not what JEP 444 calls "pinning". The "pinning" happens, for example, when one calls `syncronized(....) {blockingQueue.take()}` [...] To call Object.wait() you need to own the objects monitor, which would imply that your code would actually look like `synchronized(....) {Object.wait()}` in which case you would indeed be pinned.