IRQL

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

IRQL (англ. Interrupt Request Level — рівень запиту переривання) — механізм програмно-апаратної пріоритезації, що застосовується для синхронізації в операційних системах сімейства Windows NT.

IRQL є програмним атрибутом (через те, що не підтримується апаратно) процесора та вказує пріоритет коду, що виконується на цьому процесорі відносно переривань та інших асинхронних подій. Для апаратних переривань, у більшості випадків, IRQL реалізується апаратно (приклад: поняття пріоритету переривання в контролері i8259A чи пріоритет завдання, що вказується в регістрі TPR в APIC), проте, код операційної системи сам може логічно перебувати на різних пріоритетах, у такому випадку додаткові рівні IRQL реалізуються програмно. Наприклад, пріоритет планувальника потоків або DPC вищий за пріоритет користувацьких потоків. Якби це було не так, тоді потоки могли б витісняти планувальник і тим самим «вимкнути» витискальну багатозадачність, у свою чергу планувальник може бути зроблений таким, що переривається апаратними перериваннями. У Windows NT застосовуються 32 рівня IRQL (у дужках зазначено числове значення):

  • High (31)
  • Power fail (30)
  • IPI (29)
  • Clock (28)
  • Profile (27)
  • Діапазон апаратних переривань, званих Devices IRQL, або DIRQL (від 26 до 3)
  • DPC/DISPATCH (2)
  • APC (1)
  • PASSIVE (0)

Це означає, наприклад, що планувальник (який працює на рівні DPC/DISPATCH) може бути перерваний апаратними, міжпроцесорними перериваннями (IPI) і т. д., але не може бути перерваний асинхронними процедурами (APC) та звичайними потоками, що працюють на рівні PASSIVE. Міжпроцесорні переривання IPI можуть бути перервані збоєм електроживлення (переривання на рівні Power fail), але не можуть бути перервані звичайними апаратними перериваннями від пристроїв і т. д.

Також IRQL допомагає відстежувати та виявляти логічні помилки під час проектування ОС. Легендарна помилка з повідомленням IRQL_NOT_LESS_OR_EQUAL означає наступну ситуацію: драйвер або інший привілейований код із IRQL >= DPC/DISPATCH звернувся до відсутньої у пам'яті сторінки, вимагається виклик підсистеми, що довантажує сторінки з диску, проте ця підсистема, відповідно до архітектури Windows NT, має IRQL < DPC/DISPATCH. Отже, вона не має права переривати той код, який викликав помилку сторінки. В той же час привілейований код не може продовжити виконання, доки сторінку не буде завантажено. Виникає логічний тупик, який, власне, і спричинює крах ОС.

У Linux застосовуються подібні механізми. Наприклад, код обробника переривання може бути розділено на дві «половини»: верхню та нижню, «верхня» частина еквівалентна власне обробнику, «нижня» — відкладеній процедурі (аналог у Windows — DPC). Верхня половина процедури може бути перервана нижньою, але не навпаки. Таким чином, верхня та нижня половини логічно еквівалентні рівням IRQL Device IRQL і DPC/DISPATCH відповідно.

Дотримання системних погоджень[ред. | ред. код]

Технічна документація Windows NT (бібліотека MSDN[ru]) обмежує неперервний час роботи коду на підвищених IRQL. Для рівнів апаратних переривань (DIRQL) обмеження складає 10-20 мкс[1]. Для програмного рівня DISPATCH_LEVEL даються суперечливі значення в 25[2] і 100[3] мкс.

Тим не менше, ці обмеження часто порушуються навіть власним кодом ядра та драйверів Windows, не кажучи вже про драйвери сторонніх виробників, створюючи приховані затримки. Це не впливає помітного на звичайну роботу системи, проте може сильно погіршувати роботу в реальному часі — наприклад, у потоковому мультимедіа (особливо це помітно на звуку[4][5]). Для виявлення подібних порушень розроблено програми DPC Latency Checker[6] і LatencyMon[7]. Аналіз роботи різних версій Windows за допомогою подібних програм показує, що вказані порушення поступово виправляються[джерело?].

Примітки[ред. | ред. код]

Література[ред. | ред. код]