IRQL ( Interrupt Request Level ) - tændt. " interrupt request level ". En hardware-software- prioriteringsmekanisme , der bruges til synkronisering i operativsystemer i Windows NT -familien .
IRQL er en softwareattribut (på grund af, at den ikke understøttes af hardware) for en processor og angiver prioriteten af kode, der udføres på denne processor med hensyn til afbrydelser og andre asynkrone hændelser. For hardwareafbrydelser er IRQL i de fleste tilfælde implementeret i hardware (eksempel: konceptet med afbrydelsesprioritet i i8259A-controlleren eller opgaveprioriteten angivet i TPR-registret i APIC), men selve operativsystemkoden kan logisk set være anderledes prioriteter, i hvilket tilfælde yderligere niveauer af IRQL implementeres i software . For eksempel er prioriteten af trådplanlæggeren eller DPC højere end prioriteten af brugertråde . Hvis dette ikke var tilfældet, så kunne tråde foregribe planlæggeren og derved "deaktivere" forebyggende multitasking , igen kunne planlæggeren gøres afbrydelig af hardwareafbrydelser. Windows NT bruger 32 IRQL-niveauer (tal i parentes):
Dette betyder for eksempel, at planlæggeren (kører på DPC/DISPATCH-niveau) kan afbrydes af hardware-afbrydelser, interprocessor-afbrydelser (IPI) osv., men ikke kan afbrydes af asynkrone procedurer (APC) og normale tråde, der kører på PASSIVT niveau.. IPI interprocessor afbrydelser kan afbrydes af et strømsvigt (Strømsvigt niveau afbrydelse), men kan ikke afbrydes af normale hardware afbrydelser fra enheder osv.
IRQL hjælper også med at spore og identificere logiske fejl i OS design. Den legendariske fejl med meddelelsen IRQL_NOT_LESS_OR_EQUAL betyder følgende situation: en driver eller anden privilegeret kode med IRQL >= DPC/DISPATCH fik adgang til en side, der mangler [1] i hukommelsen, et opkald til et undersystem, der indlæser sider fra disken , er påkrævet , men dette undersystem, i overensstemmelse med Windows NT-arkitekturen, har IRQL er mindre end DPC/DISPATCH. Derfor har den ikke ret til at afbryde den kode, der forårsagede sidefejlen. Samtidig kan privilegeret kode ikke fortsætte med at køre, før siden er indlæst. Der er et logisk dødvande, som faktisk fører til sammenbruddet af operativsystemet.
Når kode udføres med IRQL >= DPC/DISPATCH, får enhver ventetilstand på en synkroniseringsprimitiv ( mutex , semafor ) OS til at crashe; Når den aktuelle tråd går ind i denne tilstand, skal trådplanlæggeren planlægge en anden tråd på den aktuelle processorkerne. Men da planlæggerens prioritet er DPC/DISPATCH, vil den ikke være i stand til at afbryde den aktuelle tråd .
Linux bruger lignende mekanismer. For eksempel kan afbrydelseshåndteringskoden opdeles i to "halvdele": øverste halvdel og nederste halvdel, den "øvre" del svarer til selve behandleren, den "nedre" del er den udskudte procedure (analog i Windows er DPC ) . En procedure i den nederste halvdel kan afbrydes af en procedure i den øverste halvdel, men ikke omvendt. Således er den øverste halvdel og den nederste halvdel logisk ækvivalent med IRQL Device IRQL og DPC/DISPATCH niveauerne, henholdsvis.
Windows NT Technical Documentation ( MSDN Library ) begrænser den kontinuerlige køretid for kode ved forhøjede IRQL'er. For hardware interrupt levels (DIRQL) er grænsen 10-20 µs [2] . For programniveauet DISPATCH_LEVEL er modstridende værdier givet ved 25 [3] og 100 [4] µs .
Disse grænser bliver dog ofte overtrådt, selv af indbygget Windows-kerne- og driverkode, endsige tredjepartsdrivere, hvilket skaber skjulte forsinkelser . Dette har ikke en mærkbar effekt på systemets normale drift, dog kan det i høj grad forringe realtidsydelsen - for eksempel i streaming-medier (dette er især mærkbart i lyd [5] [6] ). For at opdage sådanne overtrædelser er programmerne DPC Latency Checker (utilgængeligt link) (engelsk) og LatencyMon (engelsk) blevet udviklet . En analyse af driften af forskellige versioner af Windows ved hjælp af sådanne programmer viser, at disse overtrædelser gradvist bliver rettet.