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.

  • Does this answer your question? SOS_Scheduler_Yield wait type Commented Feb 14, 2022 at 11:18
  • I realize the linked to duplicate isn't exactly the same question as yours, but David's answer matches your question 😀 Commented Feb 14, 2022 at 17:08
  • @JoshDarnell Who's David :D? I did not see anyone such Commented Feb 14, 2022 at 17:56
  • I was referring to the accepted answer (by David Browne) from the Q&A here: dba.stackexchange.com/a/237755/6141 Commented Feb 14, 2022 at 18:54
  • Alright, got it. Initially I misunderstood the answer from David. I had to read it rephrased. I will delete question not to make mess Commented Feb 14, 2022 at 23:01

1 Answer 1


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.

  • 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? Commented Feb 14, 2022 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.
    Commented Feb 14, 2022 at 12:53
  • Alright I can accept that. It's exactly the part I wasn't sure about so thanks for claryfing. Commented Feb 14, 2022 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). Commented Feb 14, 2022 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." Commented Feb 14, 2022 at 17:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.