Project Loom VirtualThreads hang

[robert engels]

I posted a new branch ’no-lock-free’ that uses a traditional ring buffer using standard synchronization primitives.

It works fine - but take 52 seconds to complete - compared with 7 secs for the lock-free version.

So, I added a ’spin loop’ to the non-lock-free version which reduced the time to 8 secs! This points to opportunities to improve the synchronized/wait/notify handling under virtual threads.

Still, this is VERY promising. The ‘easy to read code’ has nearly the same performance as the difficult to get right lock-free versions.

Note, the RingBuffer in this version could be made even more performant by making it a true MPSC queue (it is actually a MPMC queue).

Note, all the tests are run using ‘8 8 500000’ to save on energy costs :)

> On Dec 28, 2022, at 7:07 AM, Robert Engels <rengels at ix.netcom.com> 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.  
> 
>> On Dec 28, 2022, at 6:51 AM, Robert Engels <rengels at ix.netcom.com> wrote:
>> 
>> 
>> Alex,
>> 
>> You write:
>> 
>>> I won't go into detail, but the producers not synchronizing between themselves leads to hangs.
>> 
>> 
>> Can you explain? Im fairly certain the producers do valid synchronization. As I said, using native threads the code runs to completion fine  
>> 
>> Now that I understand the issue I was able to reproduce the issue very simply without any queues. See SpinTest posted to the project. The “starver” thread fails to make any progress - this should not be possible is Thread.yield() was fair. 
>> 
>>> On Dec 27, 2022, at 11:15 PM, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>>> I won't go into detail, but the producers not synchronizing between themselves leads to hangs.