Interrupt Request Level (IRQL)
Every Kernel developer is familiar with IRQL and Matt Wu has written an article to disclose it�s mysterious veil.
See these are the definitions from DDK :
The priority ranking of an interrupt. A processor has an IRQL setting that threads can raise or lower. Interrupts that occur at or below the processor's IRQL setting are masked and will not interfere with the current operation. Interrupts that occur above the processor's IRQL setting take precedence over the current operation.
The particular IRQL at which a piece of kernel-mode code executes determines its hardware priority. Kernel-mode code is always interruptible: an interrupt with a higher IRQL value can occur at any time, thereby causing another piece of kernel-mode code with the system-assigned higher IRQL to be run immediately on that processor. In other words, when a piece of code runs at a given IRQL, the Kernel masks off all interrupt vectors with a lesser or equal IRQL value on the microprocessor
Matt does explains the difference between the Thread Priorities and IRQL. Any thread, whatever its priority attribute, is always preemptible by a software or hardware interrupt. Every thread priority falls in to two classes, variable and real-time. These are sub divided in 16 levels 0-15 as variable and 16 to 31 are real time. The preemptive threads get into the Variable threads or I can say all the premptive threads are the variable priority threads. All the threads are preemptible by a software as well as the hardware interrupt.The thread priority only changes the decisions by system scheduler.
On x86 CPU, there are only 4 rings which can be definied by 0,1,2,3 and Windows uses only 0 and 3 (0 is used by Kernel and 3 by the user). IRQL only exists in kernel space. For user space, it�s meaningless. All user threads are running at PASSIVE_LEVEL, though they can result in a task switch to kernel space and change the IRQL. They could not access the IRQL directly. Spin locks are always reliable for getting the control on the driver specific data. Actually they protect the shared data or device registers from simultaneous access by one or more routines running concurrently on a symmetric multiprocessor platform. Because after the SpinLock is acquired , the current IRQL will be DISPATCH_LEVEL and then the NT dispatcher (scheduler) preemption will be disabled. Just FYI and I also donn know much about this, SpinLocks have three types:
1. Standard spin locks
2. ISR synchronization spin locks. Each type has its own IRQL associations
3. Default ISR (Interrupt Service Request) spin locks.
Let me read more on spin licks then will write more.
Refer :
Understanding IRQL
A Catalog of NT Synchronization Mechanisms - OSR 1997.
Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab
