Thread::yield in a VirtualThread

[Eric Kolotyluk]

As someone who many be abusing Thread::yield at times, I really 
appreciate these little discussions...

I would love to see such gems captured somewhere in a document, blog, 
etc. as email is rather ephemeral... A Loom Best Practices Wiki would be 
nice, but the JavaDoc would be best... unfortunately, there seems to be 
a reluctance in JavaDocs for lengthy discussions. Personally, in my own 
JavaDocs, I embed links to Wikis, such as Confluence, for further 
explanations.

As far back as Java AWT (who remembers AWT?) and Swing, I routinely 
fixed scheduling problems by throwing operations on the Event Thread for 
reprocessing, even when I was already on the Event Thread. This was a 
simple fix that solved many synchrnization problems...

I have retained this practice, for good or bad, in Java Platform 
Threads. I have not used Virtual Threads yet in production, but I would 
probably continue to do so in Virtual Threads without some caveats. Now 
that I better understand the engineering intent of Thread::yield, I will 
be more mindful in the future. Thanks again for such clarifications.

I look forward to reading Ron Pressler's forthcoming book "The 
Metaphysics of Loom" 😉

Cheers, Eric

On 2023-01-03 2:18 a.m., Alan Bateman wrote:
> On 26/12/2022 22:59, KT Nabe wrote:
>> In writing a simulation for my students, I've encountered some 
>> unexpected behavior when virtual threads invoke Thread.yield 
>> (understanding that it isn't really clear what guarantees if any are 
>> provided).
>>
>> In short, if enough* virtual threads are concurrently executing 
>> Thread.yield, then no other suspended (sic? yielded/paused) virtual 
>> threads will ever be resumed (in my case the other vt's in question 
>> were Thread.sleeping, but their deadline has long since expired)
>>
>> :
>>
>> particulars:
>> Java: 19.0.1; OpenJDK 64-Bit Server VM 19.0.1+10
>> Runtime: OpenJDK Runtime Environment 19.0.1+10
> The implementation of virtual Thread.yield has changed in JDK 20 to 
> improve fairness a bit and should reduce surprises. The intention 
> isn't to use is to control scheduling but the changed implementation 
> may be useful for your teaching.
>
> -Alan