In Windows, the scheduler schedules threads. That is, all decisions regarding "what should run next" are really "what thread should run next", and are made based on attributes of the thread (its priority, its affinity setting, (sometimes) how long since it last ran, etc.). Not of processes.
Yes, Task Manager lets you change the priority or affinity of a process. But those changes are simply propagated to - ie inherited by- all of its threads. And a thread's priority, affinity, etc., can be changed from whatever it inherited from its process.
Since a thread is part of a process, and a running thread has to have its process mapped, it would make little sense to schedule processes independently.
When the scheduler selects a new thread for execution, then if the new thread is in a different process than the previous one that ran on the processor that's "switching", a process context switch is done as part of the thread context switch. That is the extent to which processes are "scheduled".
Changing process context btw involves little more than loading the CR3 register with the physical page number of the new process's top-level page table.
Yes... But wow this could be a book and is possibly outside of the scope of what could be written as an answer here. It is also possibly the application helps in the scheduling, such as when it needs to wait on one thread to complete before it can start/ continue another thread which it can sleep or wait... – Austin T French – 2014-06-29T15:37:28.743
1
This is somewhat OS-dependent. The currently preferred mechanism is 1:1 thread scheduling where the OS scheduling unit maps to a single thread. The M:N hybrid model has been used in the past where application layer scheduling was applied on top of OS scheduling. (See Wikipedia's Thread Models article section)
– Paul A. Clayton – 2014-06-29T17:45:43.7671Since a process is not a context of execution, it doesn't mean anything to "schedule a process". – David Schwartz – 2017-01-31T08:34:41.380