0

I'm reading about SOS_SCHEDULER_YIELD and after lots of readings about internals, like clock intervals, threads and quantums I've got ok understanding of how it works.

But still one fundamental question bothers me - Why would worker thread voluntarily yield processor after 4ms quantum? As per my understanding because it's non-preemptive:

If it's running it should complete task

If it needs resource it will go back to wait queue.

It's not like thread is jumping between RUNNING and RUNNABLE statuses every 4ms, right? But there are cases where it will yield as we know and I am not sure why this would happen. What is happening with the thread at the time decision is made to remove it from RUNNING state.

EDIT: I realize there is a lot of questions about this wait type, but I am not looking into troubleshooting now, but instead I'd like to understand what can make hypotethical running thread yield CPU.

crookedteeth
  • 3
  • 2

1 Answers1

3

As you probably know, there is one scheduler per core. The scheduler decides "who goes next".

All workers on the scheduler is defined to the OS as to not be executed, except one. The one which is viable is the one who "owns" the core. We still have pre-emptive multitasking in the OS, but there's only one thread (per core) that the OS is allowed to schedule. I.e., SQL Server wants to be in control of which thread that can use the CPU.

So, how can we switch from the owning (active) thread to any of the inactive threads? Should it complete its query/task and have all others not doing anything while this 5 minute CPU intensive thing is running? We don't want that, and that is why it yields after 4 ms, so the scheduler can decide which to go next.

Tibor Karaszi
  • 17,101
  • 2
  • 14
  • 26
  • Ok so yielding happens, becaue scheduler needs to make a decision. But what if we do want to keep running? For example: There are no other processes running and resource intensive sort can run as long it needs to. Will it still yield, go back to the queue and resume where it left off? – crookedteeth Feb 14 '22 at 12:09
  • 1
    @crookedteeth If there's literally nothing else running for the entirety that the one process is running, then it doesn't matter. My understanding is that it will still follow the same workflow of yielding and resuming, but the performance impact is negligible since it'll happen near instantaneously, being the only process running. As Tibor pointed out, this is normal CPU architecture, even at an OS level, to ensure that all other processes aren't doing 0 work for the entirety of a single process running, which would otherwise simulate a serial workflow & defeat the purpose of multi-threading. – J.D. Feb 14 '22 at 12:53
  • Alright I can accept that. It's exactly the part I wasn't sure about so thanks for claryfing. – crookedteeth Feb 14 '22 at 13:28
  • 2
    The yield is that gives the schedules a chance to do something. Without the yield, the scheduler could be starved from CPU resources and would never be able to make the decision regarding who's on next (be it the current thread or some other thread). – Tibor Karaszi Feb 14 '22 at 13:59
  • 1
    FYI sometimes tasks are allowed to consume multiple quantums without yielding (from here): "In this simplistic example Worker 2 is allowed to consume repeated quantum's preventing Worker 1 from monopolizing the scheduler in an unfriendly pattern." – Josh Darnell Feb 14 '22 at 17:13
  • Interesting. The way I read the text is that w2 does indeed yields and then get another quanta directly. Pretty academic difference.... – Tibor Karaszi Feb 14 '22 at 19:35
  • @Tibor very true! That's probably the case. And you're right, it's pretty academic. I was just mentioning it out of interest. – Josh Darnell Feb 14 '22 at 21:05