用户模式下的线程级别和核心模式下的IRQL是什么关系？

在USER MODE下的程序中可以调整一个线程的优先级别，有如下的优先级别：
THREAD_PRIORITY_ABOVE_NORMAL
THREAD_PRIORITY_BELOW_NORMAL.
THREAD_PRIORITY_HIGHEST.
THREAD_PRIORITY_IDLE.
THREAD_PRIORITY_LOWEST .
THREAD_PRIORITY_NORMAL .
THREAD_PRIORITY_TIME_CRITICAL

等等；
在KERNEL MODE的DRIVER中，有IRQL这个东西，那么？请问一下，用户太中的HIGHEST级别在KERNEL中算老几呢？：）

PASSIVE_LEVEL OR DISPATCH_LEVEL????

请大峡解或.

在USER MODE下的程序中可以调整一个线程的优先级别，有如下的优先级别：
THREAD_PRIORITY_ABOVE_NORMAL
THREAD_PRIORITY_BELOW_NORMAL.
THREAD_PRIORITY_HIGHEST.
THREAD_PRIORITY_IDLE.
THREAD_PRIORITY_LOWEST .
THREAD_PRIORITY_NORMAL .
THREAD_PRIORITY_TIME_CRITICAL

等等；
在KERNEL MODE的DRIVER中，有IRQL这个东西，那么？请问一下，用户太中的HIGHEST级别在KERNEL中算老几呢？：）

PASSIVE_LEVEL OR DISPATCH_LEVEL????

请大峡解或.
 

相对而言。。。。。。

USER MODE对于KERNEL MODE都是PASSIVE_LEVEL ！

只不过在USER MODE的等级上才有差别！

 :)

CPU Priority Levels
Since different CPU architectures have different ways of handling hardware interrupt priorities, Windows 2000 presents an idealized, abstract scheme to deal with all platforms. The actual implementation of the abstraction utilizes HAL routines that are platform-specific.

The basis for this abstract priority scheme is the interrupt request level (IRQL). The IRQL (pronounced irk-al) is a number that defines a simple priority. Code executing at a given IRQL cannot be interrupted by code at a lower or equal IRQL. Table 3.1 lists the IRQL levels used in the Windows 2000 priority scheme. Regardless of the underlying CPU or bus architectures, this is how IRQL levels appear to a driver. It is important to understand that at any given time, instructions execute at one specific IRQL value. The IRQL level is maintained as part of the execution context of a given thread, and thus, at any given time, the current IRQL value is known to the operating system.

Table?.1. IRQL Level Usage  IRQL Levels  
Generated By  IRQL Name  Purpose  
Hardware HIGHEST_LEVEL Machine checks and bus errors
?/Font> POWER_LEVEL Power-fail interrupts
?/fONT> IPI_LEVEL Interprocessor doorbell for MP systems
?/Font> CLOCK2_LEVEL Interval clock 2
?/fONt> CLOCK1_LEVEL Interval clock 1
?/font> PROFILE_LEVEL Profiling timer
?/font> DIRQLs Platform-dependent number of levels for I/O device interrupts
Software DISPATCH_LEVEL Thread schedule and deferred procedure call execution
?/fONT> APC_LEVEL Asynchronous procedure call execution
?/foNt> PASSIVE_LEVEL Normal thread execution level


The actual hardware interrupt levels fall between DISPATCH_LEVEL and PROFILE-LEVEL of the IRQL abstraction. These hardware interrupt levels are defined as the device IRQLs (DIRQLs).

Interrupt Processing Sequence
When an interrupt reaches the CPU, the processor compares the IRQL value of the requested interrupt with the CPU\'s current IRQL value. If the IRQL of the request is less than or equal to the current IRQL, the request is temporarily ignored. The request remains pending until a later time when the IRQL level drops to a lower value.

On the other hand, if the IRQL of the request is higher than the CPU\'s current IRQL, the processor performs the following tasks:

Suspends instruction execution.

Saves just enough state information on the stack to resume the interrupted code at a later time.

Raises the IRQL value of the CPU to match the IRQL of the request, thus preventing lower priority interrupts from occurring.

Transfers control to the appropriate interrupt service routine for the requested interrupt.

When finished, the service routine executes a special instruction that dismisses the interrupt. This instruction restores the CPU state information from the stack (which includes the previous IRQL value) and control is returned to the interrupted code.

Notice that this scheme allows higher-IRQL requests to interrupt the service routines of lower-IRQL interrupts (an interrupt of an interrupt). Because the whole mechanism is stack-based, this doesn\'t cause confusion. It does, however, raise synchronization issues addressed in chapter 5.

Software-Generated Interrupts
The lower entries in the IRQL list of Table 3.1 are tagged as being software-generated. Some interrupt processing is initiated by kernel-mode code by the execution of a privileged instruction. Windows 2000 uses these software interrupts to extend the interrupt prioritization scheme to include thread scheduling. It can be used to synchronize activity among competing threads by arbitrarily raising the IRQL of one thread to prevent interruption by the others. The next section describes the use of software interrupts and IRQL levels to schedule medium-priority driver tasks.

< BACK  NEXT >
[oR]

Deferred Procedure Calls (DPCs)
While a piece of kernel-mode code is running at an elevated IRQL, nothing executes (on the same CPU) at that or any lower IRQL. Of course, if too much code executes at too high an IRQL, overall system performance will degrade. Time-critical event handling could be deferred and cause more disastrous results.

To avoid these problems, kernel-mode code must be designed to execute as much code as possible at the lowest possible IRQL. One important part of this strategy is the Deferred Procedure Call (DPC).

Operation of a DPC
The DPC architecture allows a task to be triggered, but not executed, from a high-level IRQL. This deferral of execution is critical when servicing hardware interrupts in a driver because there is no reason to block lower-level IRQL code from executing if a given task can be deferred. Figure 3.1 illustrates the operation of a DPC. Subsequent chapters present more specific information about the use of a DPC in a driver, but an overview is presented below.

Figure 3.1. Deferred Procedure Call flow.
 
When some piece of code running at a high (e.g., hardware) IRQL wants to schedule some of its work at a lower IRQL, it adds a DPC object to the end of the system\'s DPC dispatching queue and requests a DPC software interrupt. Since the current IRQL is above DISPATCH_ LEVEL, the interrupt won\'t be acknowledged immediately, but instead remains pending.

Eventually, the processor\'s IRQL falls below DISPATCH_LEVEL and the previously pended interrupt is serviced by the DPC dispatcher.

The DPC dispatcher dequeues each DPC object from the system queue and calls the function whose pointer is stored in the object. This function is called while the CPU is at DISPATCH_LEVEL.

When the DPC queue is empty, the DPC dispatcher dismisses the DISPATCH_LEVEL software interrupt.

Device drivers typically schedule cleanup work with a DPC. This has the effect of reducing the amount of time the driver spends at its DIRQL and improves overall system throughput.

Behavior of DPCs
For the most part, working with DPCs is easy because Windows 2000 includes library routines that hide most details of the process. Nevertheless, there are two frustrating aspects of DPCs that should be highlighted.

First, Windows 2000 imposes a restriction that only one instance of a DPC object may be present on the system DPC queue at a time. Attempts to queue a DPC object that is already in the queue are rejected. Consequently, only one call to the DPC routine occurs, even though a driver expected two. This might happen if two back-to-back device interrupts occurred before the initial DPC could execute. The first DPC is still on the queue when the driver services the second interrupt.

The driver must handle this possibility with a clever design. Perhaps a count of DPC requests could be maintained or a driver might choose to implement a separate (on the side) queue of requests. When the real DPC executes, it could examine the count or private queue to determine exactly what work to perform.

Second, there is an issue of synchronization when working with multiprocessor machines. One processor could service the interrupt and schedule the DPC. However, before it dismisses the interrupt, another parallel processor could respond to the queued DPC. Thus, the interrupt service code would be executing simultaneously with the DPC code. For this reason, DPC routines must synchronize access to any resources shared with the driver\'s interrupt service routine.

The DPC architecture prevents any two DPCs from executing simultaneously, even on a multiprocessor machine. Thus, resources shared by different DPC routines do not need to worry about synchronization.

< BACK  NEXT >
 

USER MODE线程的IRQL都是PASSIVE_LEVEL