Project Loom VirtualThreads hang

[Robert Engels]

I can describe the scenario a bit more. In a message passing system N producers send messages to M consumers. When a message is sent to a consumer it isn’t necessarily flushed to the os tcp buffers immediately - since the cross into the os is expensive and if a consumer just received a message there’s a good chance they will receive one again soon so a timer is set for 500us after which the messages are flushed. 

This sacrifices single message latency for throughout and is configurable if the delay occurs. 

The way I had to address it was to use LockSupport park() instead and use an external thread to wake the thread if needed. It is actually more efficient since the single thread can handle the timers for all consumers. 

> On Jan 3, 2023, at 8:11 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 28/12/2022 13:07, Robert Engels wrote:
>> Alan,
>> 
>> I tested with JDK 20 and both the VThreadTest and SpinTest complete successfully using Thread.yield!
>> 
>> Surprisingly, it is slower than using LockSupport.parkNanos(1) - 14 secs vs 7 secs  I am not sure this makes sense - as conceptually a thread yield should be at least as efficient as a 0 time sleep - and probably more efficient.
> A timed park for very short <1us durations (or in particular <250ns) is problematic in that the timeout may be reached before the virtual thread has fully parked. In that case, it may get re-scheduled on the same carrier rather than bouncing between carriers as might happen with Thread.yield. So that might partly explain what you are seeing. Also 7 and 14s is very short run for a benchmark. I think I'd need to see the benchmark to know what you are testing.
> 
> -Alan
> 
> 
> 
> 
> 
>