It is taken for granted that operating system transparently schedules the applications. This is also true for any of the operating system kernel components such as Memory Manager or Synchronization primitive techniques.
A sound knowledge of the scheduler, its mechanics and its influence on an application’s execution could prove to be helpful while troubleshooting certain class of problems such as applications high CPU usage and System or application responsiveness. Alternatively, it could be utilized during the application design keeping in mind how the application design and scheduler algorithms could work effectively in tandem.
For operating systems that support multi-processing and multi-tasking, the kernel acts as a controlling authority for all the tasks that execute. It makes sure the tasks promptly use the system resources. The kernel component that controls the processor usage forms the Scheduler. It is very crucial to monitor the tasks and control the way they utilize the system resources that are shared by all the tasks. If this were not managed:
- Certain tasks can over-use global resources such as system memory or processors while depriving other tasks.
- Certain tasks could dominate the system itself, or may never get a chance to run at all.
Scheduler being part of the kernel manages the processors usage to be as efficient as possible and with utmost fairness that it could provide to all the tasks on the system. Apart from the scheduler at the core of the operating system, some applications such as SQL Server implement their own wrapper of user-mode scheduling on top of operating system scheduling policies.
Understanding the Evolution
For example, when a process itself was an execution unit and there was a blocking request made by the process, the operating system either scheduled a different process that had some work (if there was one) or put the processor into an idle loop. In either case, it put the blocking process into a wait state. While this worked very well, processor utilization was not efficient.
A process was a bundle of execution logic that could be executed independently of other processes. These could be executed in parallel, and when it was required to synchronize with each other, waits could be volunteered by these tasks.
Thus was the origin of multi-threaded applications. The process now became more a container than an execution unit itself, and new constructs called threads were born.
The scheduler then started scheduling the threads instead of processes. The original developers of Windows NT realized this and designed Windows NT to have threads as a basic scheduling entity.
Note: The multi-tasking scheme where the tasks regularly give up the execution time to other tasks on the system is generally referred to as co-operative multi-tasking. This approach relies on all tasks to co-operate and contribute to reliability of the system. A task that violates this rule could make the whole system starve.
I elaborated the session later with an extension and little research to complete this blog. This has nothing to do with SQL Server, but the 1 hour of back to college got me nostalgic. How many of you do this from time-to-time? I wish going back to college has its fun elements and gets us back to our roots of learning.
Reference: Pinal Dave (https://blog.sqlauthority.com)