Simultaneous Thread Execution

In most ways, the single-processor and multiprocessor versions of Windows are identical. The major difference of interest to driver writers involves thread scheduling and execution.

By default, Windows schedules all threads—including user-mode and kernel-mode threads—across all processors; no processors are reserved for system use. The highest-priority ready thread on the system is guaranteed to be running at all times. On multiprocessor systems, Windows tries to schedule the next-highest priority ready threads on additional processors, but does not guarantee such scheduling. For example, on a four-processor system, at any given time one processor will be running the highest priority thread, but the other three processors will not necessarily be running the next three highest-priority threads. For more detailed information about the thread scheduling algorithm for multiprocessor systems, see Inside Microsoft Windows 2000, Third Edition, as listed in the Resources section.

Because more than one thread runs at the same time, more than one driver routine can run at the same time. Thus, it is possible—even likely—that code from a single driver will be running in two or more different thread contexts, on different processors, simultaneously.

Figure 2 shows a simplified example of how two different processors run different threads simultaneously.

Figure 2. Simultaneous Threads on Multiprocessor Systems

In Figure 2, the following operations occur in sequence:

1. At the start, Thread A is running on Processor 0 and Thread B is running on Processor 1. In Thread A the DispatchDeviceControl routine for Device 1 (Dev1) is running at IRQL PASSIVE_LEVEL. In Thread B, arbitrary code for some process is running, also at PASSIVE_LEVEL.

2. Device 1 interrupts on Processor 1, indicating that it has finished an earlier I/O request. Processor 1 raises IRQL to DIRQL to run the InterruptService routine (ISR). The InterruptService routine stops the device from interrupting and queues a DpcForIsr routine. Meanwhile, the DispatchDeviceControl routine continues running on Processor 0 at PASSIVE_LEVEL.

3. The InterruptService routine completes on Processor 1, which then lowers IRQL to DISPATCH_LEVEL and runs the DpcForIsr previously queued by the InterruptService routine for Device 1. The DispatchDeviceControl routine continues running on Processor 0 at PASSIVE_LEVEL.

Because the IRQL is associated with an individual CPU, the hardware interrupt on Processor 1 has no effect on Processor 0. Therefore, the DispatchDeviceControl routine continues running on Processor 0 while the device interrupts on Processor 1 and the InterruptService and DpcForIsr routines run. The DispatchDeviceControl routine thus runs concurrently with the InterruptService routine and with the DpcForIsr routine. If DispatchDeviceControl shares writable data with either of the other two routines, the driver must use locks to ensure that only one routine accesses the shared data at a time.

The need for locks in such situations is not limited to multiprocessor systems. For example, assume that the DispatchDeviceControl routine (which runs at PASSIVE_LEVEL) shares writable data with the DpcForIsr routine (which runs at DISPATCH_LEVEL). The DispatchDeviceControl routine must acquire a lock that raises IRQL to DISPATCH_LEVEL or higher before accessing the shared data. On single-processor systems, Windows implements spin locks by raising IRQL to DISPATCH_LEVEL, thus preventing preemption while the lock is held. ExInterlockedXxx and InterlockedXxx routines also prevent preemption at DISPATCH_LEVEL.

Date: 2015-12-24; view: 784