Question about virtual thread scheduling during a long running task

[Ron Pressler]

That will ultimately be up to the specific scheduler used. At this time, 
the default scheduler does not employ time-sharing. Here’s why: if a
million threads are CPU bound then no scheduling policy can help; the machine 
is over-subscribed by orders of magnitude. If only a few threads are
computation-heavy, then they can just use the kernel scheduler (i.e.
instantiated as platform threads). If a small number of different threads is
computation heavy at different times, then a work-stealing scheduler should be
able to smooth things over even without time-sharing.

This last point could be wrong and we might need to change the behaviour of the
default scheduler, but for that we need to see real-world use-cases where
time-sharing can help. In other words, for time-sharing to be a default
policy, we need to show: 1. That computations like that might be a problem
In practice and 2. That time-sharing can help in those situations.

In any event, Thread.yield() hints to the scheduler that other virtual
threads should be scheduled.

— Ron




On 9 August 2020 at 18:50:24, sam reddy (samarendra.kandala at gmail.com(mailto:samarendra.kandala at gmail.com)) wrote:

> I am going through the the State of Loom and saw this "Rather, they are
> preempted when they block on I/O or synchronization"
>  
> my question is if there is loop something like below
>  
> long k = 0;
> for(long i = 0; i<1000000000000L ; i ++)
> {k = k+i;}
>  
> Does the virtual thread executing the above code will give processing time
> to another virtual thread before completion of the for block. or this
> virtual thread will take all the time of underlying OS thread till the for
> loop competes? how scheduling works during execution of such loops?
>  
> In golang there is runtime.Gosched() , do we have anything similar to
> this?
>  
> Please note the above code is an example to illustrate the problem.
>  
>  
> Regards
> Samarendra