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

Post by extractionmech » Thu, Jan 18, 2024, 12:47 AM UTC

samus wrote: post #110

extractionmech wrote: post #43

Earlier quoted context omitted.

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?

It's an explicitly documented shortcoming of the existing implementation that will be fixed soon. I knew immediately from the title of TA what probably happened. The other similar limitations (CPU-bound tasks, native calls) seem much more severe, but are ultimately unsolvable. Meanwhile, the issue with synchronized is regarded as a scalability bottleneck since the JDK is supposed to temporarily spawn additional platf…

Post by skyde » Mon, Jan 29, 2024, 4:38 PM UTC

dikei wrote: post #241

skyde wrote: post #234

Why synchronized block are not preemptible? When compiling public void syncMethod() { synchronized(lock) { // some code } } they could translate to public void syncMethod() { await reentrantLockAsync.lockAsync(); try { await somecodeAsync(); } finally { await lock.unlockAsync() } }

The first issue is your second code is not Java (no await/async literal for Java yet) The second issue is they're not completely equivalent. In the second case, you'd need extra memory for the `reentrantLock`, while `synchronized` works with any object. Furthermore, if you need to use `wait/notify`, then there need to be an extra `Condition` object to use in combination with the `ReentrantLock`. For sure, developers…

       await foreach (int item in RangeAsync(10, 3))

       Console.Write(item + " "); // Prints 10 11 12

  try {

    while (await e.MoveNextAsync()) Console.Write(e.Current + " ");

  } finally { 

    if (e != null) await e.DisposeAsync(); 

  }