A process is an instance of an application or system program that runs on a system. Examples of processes are winword.exe (Microsoft Word for Windows), lsass.exe (Windows NT's local security administration subsystem), and timeserv.exe (from Microsoft Windows NT Server 4.0 Resource Kit). A thread is a unit of work that can execute simultaneously with other units of work on the system. Some threads create (or spawn) other threads. A process is simply a collection of threads. A thread is an executable part of a process.
The NT dispatcher determines the order in which threads run and on which processors they run. Affinity is the tendency for a thread to run on a particular processor or set of system processors. NT uses soft affinity by default, running a thread on the same processor it ran on previously. NT also supports hard affinity to let you specify which processors a process or thread uses. Ideal affinity or preferred affinity lets you specify a preferred processor from the group of hard affinity processors. The NT dispatcher runs a process on the preferred processor if that processor is available. NCR's SMP Utilization Manager lets you set hard affinity and preferred affinity for process threads. Thus, a process can run on only a few processors, and the other processors remain free to run other processes.
For more information about processes and threads, see Christa Anderson, "Foreground Application Handling in NT 4.0," June 1997. For more information about the NT scheduler, see Mark Russinovich, "Inside the Windows NT Scheduler, Part 1," July 1997, and "Inside the Windows NT Scheduler, Part 2," August 1997.
The NT scheduler maintains a prioritized list of scheduled threads and dispatches the highest priority threads first. Each thread has a priority of 0 to 31. These priority values belong to priority classes: Real Time, Very High, Normal, and Idle. Within priority classes, a thread has a priority level: Highest, Above Normal, Normal, Below Normal, or Idle. These priority levels range from 2 points above to 2 points below the normal priority level.
When NT dispatches a thread, it assigns a CPU for a particular length of time. Realtime priority threads are an exception. These threads run until they complete or until they must stop to wait for another event. When a thread's time limit expires, the dispatcher moves to the next thread in the list.
NT treats less-CPU-intensive threads equally. It gives proportionately more CPU time to applications that consist of many threads than it gives to applications with fewer threads. NT lowers the priority of CPU-intensive threads to give priority to less-CPU-intensive tasks. This process creates problems if you need to execute a CPU-intensive application quickly. SMP Utilization Manager lets you allocate the necessary CPU time to give priority to either type of application.
In a symmetric multiprocessing (SMP) system, the dispatcher selects a processor to run a thread. The dispatcher first selects the thread's ideal processor. If the ideal processor is unavailable, the dispatcher selects the processor the thread ran on previously. If neither processor is available, the dispatcher selects another idle processor or a processor running a lower-priority thread.
Processor Cache Efficiency and Application CPU Requirements
NT typically runs a thread on the processor that ran the thread previously. When a process uses a processor repeatedly, the processor's cache memory stores the most commonly used instructions. The processor can then execute a process without having to retrieve the instructions from system RAM. Cache pollution occurs when a processor runs a new process and the second process' instructions overwrite the first process' instructions. If you have numerous processors in a busy multiple-application system, a thread rarely runs on the same processor each time.
In large multiprocessor systems running multiple applications, applications' CPU requirements are often stable. Thus, you can determine CPU requirements for each application. Suppose you have an 8-way system running SQL Server and Exchange Server, and Performance Monitor shows that SQL Server uses three times as many CPU cycles as Exchange uses. You can use SMP Utilization Manager to set hard CPU affinity, designating six processors to run SQL Server and two processors to run Exchange. Setting processor affinity improves the chance that the same processor or processors will repeatedly execute a process and thus reduces the instances of processor cache reload. Likewise, preventing an application from using certain processors ensures that the application cannot hog CPU time. Without hard CPU affinity settings, the dispatcher can select any system processor and perhaps produce cache pollution and suboptimal performance.