Is the time slice (quantum) that the Windows Kernel Dispatcher allocates to threads the same length for every thread, or does it base the size of quantum on the priority of the thread like Linux does?


Since the days of Windows NT, higher priorities applications have a larger quantum, for example for foreground threads.

32 priority levels are defined, 0 through to 31, with priorities 0 through 15 being "normal" priorities and priorities 16 through 31 being soft real-time priorities, requiring privileges to assign. 0 is reserved for the Operating System. Users can select 5 of these priorities to assign to a running application from the Task Manager application, or through thread management APIs. The kernel may change the priority level of a thread depending on its I/O and CPU usage and whether it is interactive (i.e. accepts and responds to input from humans), raising the priority of interactive and I/O bounded processes and lowering that of CPU bound processes, to increase the responsiveness of interactive applications

In Vista, the scheduler makes use of cycle counter registers in modern processors, and is able to estimate how many cycles a thread uses per clock tick. This way, the scheduler can divvy up CPU time much more fairly. A thread is allowed to run for another time slice after being interrupted, while before Vista the scheduler assumed that an interrupted thread ran for its entire time slice. (This indirectly increases the priority of a much-interrupted thread.) Vista also uses a priority scheduler for the I/O queue so that disk defragmenters and other such programs don't interfere with foreground operations.

Sources: wikipedia Scheduling, Vista Kernel Improvements.

  • 1
    The second link is dead, but it's still available at archive.org: web.archive.org/web/20120323170914/http://blog.gabefrost.com/… – ComFreek Oct 7 '14 at 16:45
  • "Since the days of Windows NT, higher priorities applications have a larger quantum,". This is not accurate. A higher priority thread gets to pre-empt lower priority threads, but it doesn't get a longer quantum (timeslice) just because it has a higher priority. You are close, though, in mentioning foreground threads. Default behavior on client (non-Server) Windows OSs is that all threads in the process that owns the foreground window get timeslices 3x the normal length. But priority is a different thing. – Jamie Hanrahan Mar 27 '16 at 15:46
  • Not true. I quote from Microsoft : "When a window is brought into the foreground on a client system, all the threads in the process containing the thread that owns the foreground window have their quantums tripled". This happens when foreground jobs have priority. The quantum unit is the same, but not the number of units assigned to the process threads as their quantum. – harrymc Mar 31 '17 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy