What causes SQL Server worker thread to voluntarily yield



  • 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.



  • 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2