System Worker Threads

During system initialization, Windows creates several threads in the System process, called system worker threads, that exist solely to perform work on behalf of other threads. In many cases, threads executing at DPC/dispatch level need to execute functions that can be performed only at a lower IRQL. For example, a DPC routine, which executes in an arbitrary thread context (because DPC execution can usurp any thread in the system) at DPC/dispatch level IRQL, might need to access paged pool or wait for a dispatcher object used to synchronize execution with an application thread. Because a DPC routine can't lower the IRQL, it must pass such processing to a thread that executes at an IRQL below DPC/dispatch level.

Some device drivers and executive components create their own threads dedicated to processing work at passive level; however, most use system worker threads instead, which avoids the unnecessary scheduling and memory overhead associated with having additional threads in the system. A device driver or an executive component requests a system worker thread's services by calling the executive functions ExQueueWorkItem or IoQueueWorkItem. These functions place a work item on a queue dispatcher object where the threads look for work. (Queue dispatcher objects are described in more detail in the section "I/O Completion Ports" in Chapter 9.) Work items include a pointer to a routine and a parameter that the thread passes to the routine when it processes the work item. The routine is implemented by the device driver or executive component that requires passive-level execution.

For example, a DPC routine that must wait for a dispatcher object can initialize a work item that points to the routine in the driver that waits for the dispatcher object, and perhaps points to a pointer to the object. At some stage, a system worker thread will remove the work item from its queue and execute the driver's routine. When the driver's routine finishes, the system worker thread checks to see whether there are more work items to process. If there aren't any more, the system worker thread blocks until a work item is placed on the queue. The DPC routine might or might not have finished executing when the system worker thread processes its work item. (On a uniprocessor system, a DPC routine always finishes executing before its work item is processed because thread scheduling doesn't take place when the IRQL is at DPC/dispatch level.)

There are three types of system worker threads:

• Delayed worker threads execute at priority 12, process work items that aren't considered time-critical, and can have their stack paged out to a paging file while they wait for work items.

• Critical worker threads execute at priority 13, process time-critical work items, and on Windows Server systems, have their stacks present in physical memory at all times.

• A single hypercritical worker thread executes at priority 15 and also keeps its stack in memory. The process manager uses the hypercritical work item to execute the thread "reaper" function that frees terminated threads.

The number of delayed and critical worker threads created by the executive's ExpWorkerInitialization function, which is called early in the boot process, depends on the amount of memory present on the system and whether the system is a server. Table 3-11 shows the initial number of threads created on different system configurations. You can specify that ExpInitializeWorker create up to 16 additional delayed and 16 additional critical worker threads with the AdditionalDelayedWorkerThreads and AdditionalCriticalWorkerThreads values under the registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Executive.

Table 3-11. Initial Number of System Worker Threads

	Windows 2000	Windows 2000 Server	Windows XP and Windows Server 2003
Delayed	3	3	7
Critical	5	10	5
Hypercritical	1	1	1

The executive tries to match the number of critical worker threads with changing workloads as the system executes. Once every second, the executive function ExpWorkerThreadBalanceManager determines whether it should create a new critical worker thread. The critical worker threads that are created by ExpWorkerThreadBalanceManager are called dynamic worker threads, and all the following conditions must be satisfied before such a thread is created:

• Work items exist in the critical work queue.

• The number of inactive critical worker threads (ones that are either blocked waiting for work items or that have blocked on dispatcher objects while executing a work routine) must be less than the number of processors on the system.

• There are fewer than 16 dynamic worker threads.

Dynamic worker threads exit after 10 minutes of inactivity. Thus, when the workload dictates, the executive can create up to 16 dynamic worker threads.

EXPERIMENT: Listing System Worker Threads

You can use the !exqueue kernel debugger command to see a listing of system worker threads classified by their type:

kd> !exqueue Dumping  ExWorkerQueue: 8046A5C0 **** Critical WorkQueue(  current  =0  maximum=  1) THREAD 818a2d40  Cid 8.c    Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a2ac0  Cid 8.10   Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a2840  Cid 8.14   Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a25c0  Cid 8.18   Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a2340  Cid 8.1c   Teb: 00000000  Win32Thread: 00000000 WAIT **** Delayed WorkQueue( current  =0  maximum  =1) THREAD 818a20c0  Cid 8.20   Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a1020  Cid 8.24   Teb: 00000000  Win32Thread: 00000000 WAIT THREAD 818a1da0  Cid 8.28   Teb: 00000000  Win32Thread: 00000000 WAIT **** HyperCritical  WorkQueue( current=  0maximum  =1  ) THREAD 818a1b20  Cid 8.2c   Teb: 00000000  Win32Thread: 00000000 WAIT