Grant Johnson, Tim Dudra, anyone else criticising the Windows scheduler: you're wrong. Windows does indeed run threads by priority. It is fully pre-emptive, but that word means something different from what you think it does. Pre-empting means that when something occurs that causes a higher-priority thread to become runnable than is currently executing on the current, or any, processor, the current thread's run is ended early (with the scheduler noting how much of the quantum has been used, the thread getting the rest of its quantum next time) and the higher-priority thread beginning its run immediately, rather than having to wait until either the next timer tick or to the end of the current thread's quantum. The pre-empted thread gets pushed onto the front of the queue at its priority level, so it will be the next thread to run once all higher-priority threads have blocked (see next paragraph).

Windows' scheduler is a round-robin priority-based scheduler. What that means is that it will take into account the priority of all runnable threads on the system. It runs all threads at the highest priority level at which there _are_ runnable threads in a round-robin fashion - running each thread in turn. It will only start to consider lower-priority threads when those higher-priority threads are no longer runnable, which basically means when they're blocked waiting for something to happen. The exception is when it has more CPUs than high-priority threads - in this case it will find work for the otherwise-spare CPUs to do.

Multi-CPU (or {logical} core) scheduling is more tricky since Windows has both an affinity mask which governs which cores a thread is allowed to run on (which is also misused!), an 'ideal' core for each thread (set when the thread is created, rotating across the cores within a process, so thread 0 might be on CPU 0, then thread 1 will be on CPU 1, thread 2 on CPU 2, then 3 on CPU 0 again, and so on), and remembering the last core that a thread ran on. These last two settings are a hint to try to improve cache locality - with luck the thread's code or data may still be in the core/processor's cache. You might find that the two highest priority threads on a two-core system wouldn't actually both run concurrently if they have the same ideal core and there's a runnable lower-priority thread which has the other core as its ideal core.

Windows stores two priority values: a base priority, and a dynamic priority. The scheduling is done based on the dynamic priority - the base priority is a low water mark below which a thread will never go. When a thread that was blocked becomes runnable, its dynamic priority is boosted - the amount it is boosted by depends on the reason it becomes unblocked. For disk I/O it's boosted by 1, for network or serial port activity by 2, for keyboard and mouse input by 6, and if the sound card needs more data, by 8. If it was waiting for an event or a semaphore, it's normally by 1. There are special functions which can cause a higher boost for events - the event used in a critical section boosts the unblocking thread to the priority of the thread which left the critical section plus one. If a thread unblocks due to GUI activity its priority is boosted by 2.

Joe Duffy mentions the balance set manager thread which wakes up once per second for various management duties. One of those is to look for threads that are runnable but haven't run for 4 seconds. It temporarily gets boosted to priority 15 (the highest non-real-time priority) then, after its quantum expires, drops back to its base priority. It only examines 16 threads on the ready queue at a time, and will only boost 10 threads in any pass, so if there are a lot of runnable threads, it may take some time for any given thread to get its boost.

Full details are in 'Windows Internals, Fourth Edition' by Mark Russinovich and David Solomon, which I recommend to any programmer. If abstractions leak, you'd best understand the leaks.

Windows hasn't had the concept of 'yield' since Windows 3.1. 16-bit applications do still act this way with each other on Windows NT-family systems but the whole 16-bit environment is pre-emptable against 32-bit applications.

The main problems are threads which poll rather than blocking, and applications which are thread-happy. Polling is brain-dead. The operating system offers numerous ways to wait for changes to occur, and they should be used. Polling wastes laptop batteries, because the CPU cannot be put into a low power state, and often causes disks to be kept spinning because the polling thread's code and data may be pulled back into memory if trimmed from the working set.

A thread-happy application is one which creates, and keeps runnable, more threads than can be actually serviced by the system's processors. The system spends its time thrashing the processor's cache rather than doing useful work. Put one of these at high priority and suddenly very little else will get done.

Coleman: the difference is that other threads actually do get CPU time if the badly-behaved thread is at normal priority. You don't see it because the well-behaved threads have normally woken up, done their work, and gone back to sleep again before their time slice has elapsed, and are therefore using far less than 1% of the CPU time. Process Explorer from www.sysinternals.com can show fractional CPU. It can also show the Context Switch Delta, the number of times this thread was switched to - some threads are doing such tiny amounts of work that they don't even get credited with any CPU time by the thread time accounting.

If the badly-behaved thread is at high priority and the other runnable threads are at normal priority, at the end of every quantum for the badly-behaved thread, the scheduler will look at the priority queues, see that there's no other thread at this priority level and just run the badly-behaved thread again. This is what it's designed to do. It's only when the balance set manager thread boosts the priority of the starved thread that the starved thread will get to run, and it will only get up to one quantum (about 270ms with XP's default settings for the foreground application, 90ms for a background application or a special quantum of 4 ticks = 60ms on Windows Server 2003) before its dynamic priority drops back down and the badly-behaved thread gets full control again.

The scheduler _is_ doing its job. Its job is to run higher priority threads until they block. If the threads don't block, that's a programming error. Unfortunately developers have a tendency to use all the resources of the system for their task, not considering that it may not be the most important task for the user at that time.

A spinlock is meant to spin for a _short_ time. If it spins for as long as a timer tick (15ms) it's spinning too long and should have blocked.

A thread doesn't just block when Sleep or the WaitFor{Single,Multiple}Object{s} family are called. It also blocks when GetMessage is called (PeekMessage does not block and should be avoided where possible). Never use Application.DoEvents - that's a polling function (it calls PeekMessage) and can cause re-entrancy problems as well. Blocking also occurs whenever disk accesses are needed to satisfy a request, either explicitly using ReadFile (or anything on top of that, e.g. fgets, fscanf, StreamReader), or implicitly when paging code or data from the executable or the page file, or from a memory-mapped file.

If you genuinely have a compute-bound operation whose code and data fits in a small area of memory, then there's no need to yield as long as you leave the priorities alone - the scheduler will pick another thread at the same priority to run (the one which ran least recently) when your thread's quantum elapses, if there is a runnable thread. High priorities are for responsiveness where the OS dynamic boosts are not sufficient. I can't honestly think of a reason to use this.

If you find any operation where you're polling a value and the API doesn't offer a blocking version (or a version that signals a synchronisation object), complain to the maker of the API.