IRQL ( Interrupt Request Level ) - tänd. " avbrottsbegäran nivå ". En mekanism för prioritering av hårdvara och mjukvara som används för synkronisering i operativsystem i Windows NT -familjen .
IRQL är ett mjukvaruattribut (på grund av att det inte stöds av hårdvara) hos en processor och indikerar prioritet för kod som exekveras på den processorn med avseende på avbrott och andra asynkrona händelser. För hårdvaruavbrott implementeras i de flesta fall IRQL i hårdvara (exempel: konceptet med avbrottsprioritet i i8259A-kontrollern eller uppgiftsprioriteten som anges i TPR-registret i APIC), men själva operativsystemets kod kan logiskt sett ha olika prioriteringar, i vilket fall ytterligare nivåer av IRQL implementeras i programvara . Till exempel är prioriteten för trådschemaläggaren eller DPC högre än prioriteten för användartrådar. Om detta inte var fallet, skulle trådar kunna föregripa schemaläggaren och därigenom "stänga av" förebyggande multitasking , i sin tur kan schemaläggaren göras avbrytbar av hårdvaruavbrott. Windows NT använder 32 IRQL-nivåer (siffror inom parentes):
Detta innebär till exempel att schemaläggaren (som körs på DPC/DISPATCH-nivån) kan avbrytas av hårdvaruavbrott, interprocessoravbrott (IPI) etc., men inte kan avbrytas av asynkrona procedurer (APC) och normala trådar som körs på PASSIV nivå.. IPI-interprocessoravbrott kan avbrytas av ett strömavbrott (strömavbrottsnivåavbrott), men kan inte avbrytas av normala hårdvaruavbrott från enheter etc.
IRQL hjälper också till att spåra och identifiera logiska fel i OS-design. Det legendariska felet med meddelandet IRQL_NOT_LESS_OR_EQUAL betyder följande situation: en drivrutin eller annan privilegierad kod med IRQL >= DPC/DISPATCH fick åtkomst till en sida som saknas [1] i minnet, ett anrop till ett undersystem som laddar sidor från disk krävs , men detta delsystem, i enlighet med Windows NT-arkitekturen, har IRQL är mindre än DPC/DISPATCH. Därför har den inte rätt att avbryta koden som orsakade sidfelet. Samtidigt kan privilegierad kod inte fortsätta att köras förrän sidan har laddats. Det finns en logisk återvändsgränd, som faktiskt leder till att operativsystemet kollapsar.
Vid exekvering av kod med IRQL >= DPC/DISPATCH, orsakar varje vänteläge på en synkroniseringsprimitiv ( mutex , semafor ) operativsystemet att krascha; När den aktuella tråden går in i detta tillstånd måste trådschemaläggaren schemalägga en annan tråd på den aktuella processorkärnan. Men eftersom schemaläggarens prioritet är DPC/DISPATCH, kommer den inte att kunna avbryta den aktuella tråden .
Linux använder liknande mekanismer. Till exempel kan avbrottshanterarkoden delas upp i två "halvor": övre halvan och nedre halvan, den "övre" delen är likvärdig med hanteraren själv, den "nedre" delen är den uppskjutna proceduren (analog i Windows är DPC ) . En nedre halvan procedur kan avbrytas av en övre halvan procedur, men inte vice versa. Således är övre halvan och nedre halvan logiskt ekvivalenta med IRQL-enhetens IRQL- respektive DPC/DISPATCH-nivåer.
Windows NT Technical Documentation ( MSDN Library ) begränsar den kontinuerliga körtiden för kod vid förhöjda IRQL. För hårdvaruavbrottsnivåer (DIRQL) är gränsen 10-20 µs [2] . För programnivån DISPATCH_LEVEL ges motstridiga värden vid 25 [3] och 100 [4] µs .
Dessa gränser överträds dock ofta även av inbyggd Windows-kärna och drivrutinskod, än mindre drivrutiner från tredje part, vilket skapar dolda förseningar . Detta har ingen märkbar effekt på systemets normala funktion, men det kan kraftigt försämra realtidsprestandan - till exempel i strömmande media (detta märks särskilt i ljud [5] [6] ). För att upptäcka sådana överträdelser har programmen DPC Latency Checker (otillgänglig länk) (engelska) och LatencyMon (engelska) utvecklats . En analys av driften av olika versioner av Windows med sådana program visar att dessa överträdelser gradvis korrigeras.