IRQL ( megszakítási kérelem szintje ) - világít. " megszakítási kérés szintje ". Hardver-szoftver prioritási mechanizmus, amelyet a Windows NT család operációs rendszereinek szinkronizálására használnak .
Az IRQL a processzor szoftveres attribútuma (a hardver nem támogatja), és jelzi a processzoron végrehajtott kód prioritását a megszakítások és más aszinkron események tekintetében. Hardveres megszakításoknál a legtöbb esetben az IRQL hardverben valósul meg (például: a megszakítási prioritás fogalma az i8259A vezérlőben vagy az APIC TPR regiszterében megadott feladatprioritás), azonban maga az operációs rendszer kódja logikailag eltérő lehet. prioritásokat, ebben az esetben további IRQL szinteket implementálnak a szoftverben. Például a szálütemező vagy a DPC prioritása magasabb, mint a felhasználói szálak prioritása . Ha ez nem így lenne, akkor a szálak megelőzhetik az ütemezőt, és ezáltal „kikapcsolhatnak”preemptive multitasking , viszont az ütemező hardveres megszakításokkal megszakíthatóvá tehető. A Windows NT 32 IRQL szintet használ (a számok zárójelben vannak):
Ez például azt jelenti, hogy az ütemező (DPC/DISPATCH szinten fut) megszakítható hardveres megszakításokkal, processzorközi megszakításokkal (IPI) stb., de nem szakíthatja meg aszinkron eljárások (APC) és normál szálak, amelyek a rendszerben futnak. PASSZÍV szint.. Az IPI processzorközi megszakításokat megszakíthatja áramkimaradás (Power fail level interrupt), de nem szakíthatja meg normál hardveres megszakítások eszközöktől stb.
Az IRQL emellett segít nyomon követni és azonosítani a logikai hibákat az operációs rendszer tervezésében. A legendás hiba az IRQL_NOT_LESS_OR_EQUAL üzenettel a következő helyzetet jelenti: egy illesztőprogram vagy más privilegizált kód IRQL >= DPC/DISPATCH olyan oldalhoz fértek hozzá, amely hiányzik [1] a memóriából, egy alrendszer hívása szükséges, amely oldalakat tölt be a lemezről , de ennek az alrendszernek a Windows NT architektúrájának megfelelően az IRQL kisebb, mint a DPC/DISPATCH. Ezért nincs joga megszakítani az oldalhibát okozó kódot. Ugyanakkor a privilegizált kód nem futhat tovább, amíg az oldal be nem töltődik. Logikai patthelyzet van, ami valójában az operációs rendszer összeomlásához vezet.
Ha kódot hajt végre IRQL >= DPC/DISPATCH mellett, a szinkronizálási primitív ( mutex , szemafor ) bármely várakozási állapota az operációs rendszer összeomlását okozza; Amikor az aktuális szál ebbe az állapotba kerül, a szálütemezőnek egy másik szálat kell ütemeznie az aktuális processzormagon. De mivel az ütemező prioritása a DPC/DISPATCH, nem tudja megszakítani az aktuális szálat .
A Linux hasonló mechanizmusokat használ. Például a megszakításkezelő kódja két „félre” osztható: felső és alsó fele, a „felső” rész magával a kezelővel egyenértékű, az „alsó” rész a késleltetett eljárás (a Windows analógja a DPC ) . Egy alsó fél eljárás megszakítható egy felső fél eljárással, de fordítva nem. Így a felső fele és az alsó fele logikailag egyenértékű az IRQL eszköz IRQL és DPC/DISPATCH szintjével.
A Windows NT Technical Documentation ( MSDN Library ) korlátozza a kód folyamatos futási idejét megemelt IRQL-ek esetén. A hardveres megszakítási szintek (DIRQL) esetében a határ 10-20 µs [2] . A DISPATCH_LEVEL programszinten az ütköző értékek 25 [3] és 100 [4] µs értéknél vannak megadva .
Ezeket a korlátokat azonban gyakran még a natív Windows kernel és illesztőprogram kódja is megsérti, nem beszélve a harmadik féltől származó illesztőprogramokról, rejtett késéseket okozva . Ennek nincs észrevehető hatása a rendszer normál működésére, viszont nagymértékben ronthatja a valós idejű teljesítményt - például a streaming médiában (ez hangzásban különösen észrevehető [5] [6] ). Az ilyen jogsértések észlelésére a DPC Latency Checker (elérhetetlen hivatkozás) (angol nyelven) és a LatencyMon (angol nyelvű) programokat fejlesztették ki . A Windows különböző verzióinak ilyen programokat használó működésének elemzése azt mutatja, hogy ezeket a jogsértéseket fokozatosan kijavítják.