effectiveness of jdk.virtualThreadScheduler.maxPoolSize

[robert engels]

But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ‘batch/idle’ - i.e. only run when nothing else needs to run).

So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making “progress”) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say.

> On Jan 7, 2023, at 6:48 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 06/01/2023 19:48, Robert Engels wrote:
>> The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn’t happen.
> 
> Spinlocks are usually only used for locks that that are held for very brief periods. If a virtual thread is doing I/O or running other code that causes it to preempted while hold such a lock then yes, then deadlocks like this could arise.
> 
> We expect that the maintainers of low level code with their own lock implementations, or code doing spin waits to avoid parking, will need to make some changes to work efficiently with virtual threads and with greedy schedulers. Given that parking is cheap then it might be that code goes straight to park when running in a virtual thread. For spin locks it might be that it changes to be more hybrid so that it is efficient when executed by both platform and virtual threads, and when used together.
> 
> -Alan
> 
> 
>