Cooperative vs preemtive scheduling of virtual theads

[David Holmes]

On 8/06/2020 9:51 pm, Ron Pressler wrote:
> Preemptive scheduling is often mistakenly used to refer to time-sharing [1].
> When execution can return to the scheduler without user code being aware of
> it in any way, scheduling is preemptive.

In my old OS text books scheduling is preemptive if the CPU can be taken 
away from a task without it offering to give it up. So I tend to agree 
with Andrew that run-till-blocked would not typically be considered as 
preemptive as the task willingly gives the processor up while it waits 
for a lock/io-completion/etc.

Preemptive scheduling is usually associated with scheduling systems that 
can force a task off CPU e.g. priority-preemptive scheduling, or 
time-preemptive scheduling (a.k.a time-slicing), or a combination.

It is probably best to avoid using either "preemptive" or "cooperative" 
to describe virtual thread scheduling and instead just focus on the 
actual properties e.g. run-till-blocked.

> Cooperative scheduling [2] is when code is required to explicitly yield
> control back to the scheduler, like in the old 16-bit Windows or with an
> `await` keyword in some programming languages.

Does Thread.yield have defined semantics for virtual threads?

Cheers,
David
-----

> 
> [1]: https://en.wikipedia.org/wiki/Preemption_(computing)#PREEMPTIVE
> 
> [2]: https://en.wikipedia.org/wiki/Cooperative_multitasking
> 
> 
> 
> On 8 June 2020 at 10:06:23, Andrew Haley (aph at redhat.com(mailto:aph at redhat.com)) wrote:
> 
>> On 06/06/2020 16:59, Alan Bateman wrote:
>>> Virtual threads are pre-emptive, the scheduling points are locking or
>>> blocking I/O operations. It's not cooperative in the sense that there
>>> isn't the equivalent of an "await" in other languages.
>>   
>> Just a terminology nitpick, for clarity: every co-operative scheduler
>> I ever used switched tasks at locks and blocking I/O operations. I
>> believe this is standard terminology.
>>   
>> One of the problems with this way of thinking, though, is that beneath
>> abstraction layers client code can't tell what might block. For
>> example, any call might be to code that loads new classes, thus
>> blocking. So, in principle, any call site can switch tasks.
>>   
>> --
>> Andrew Haley (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd.
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>   
>