необхідно на час обробки переривання замаскувати всі запити з більш низьким пріоритетом. При цьому можливо багаторівневе переривання, тобто переривання програм обробки переривань. Число рівнів переривання в цьому режимі змінюється і залежить від пріоритету запиту;
- по принципу стека, чи, як іноді говорять, по дисципліні LCFS (last come fіrst served - останнім прийшов - першим обслужений), тобто запити з більш низьким пріоритетом можуть переривати обробку переривання з більш високим пріоритетом. Для цього необхідно не накладати маски ні на один сигнал переривання і не виключати систему переривань.
Слід особливо зазначити, що для правильної реалізації останніх двох дисциплін потрібно забезпечити повне маскування системи переривань при виконанні кроків 1-4 і 6-7. Це необхідно для того, щоб не втратити запит і правильно його обслужити. Багаторівневе переривання повинне відбуватися на етапі власне обробки переривання, а не на етапі переходу з одного процесу на інший.
З появою запиту на переривання система переривань ідентифікує сигнал і, якщо переривання дозволені, керування передається на відповідну підпрограму обробки. З мал. 14 видно, що і підпрограмі обробки переривання маються дві службові секції. Це - перша секція, у якій здійснюється збереження контексту перерваної задачі, що не зміг бути збережений на 2-му кроці, і остання, заключна секція, у якій, навпаки, здійснюється відновлення контексту. Для того щоб система переривань не зреагувала повторно на сигнал запиту на переривання, вона звичайно автоматично "закриває" (відключає) переривання, тому необхідно потім у підпрограмі обробки переривань знову включати систему переривань Установка розглянутих режимів обробки переривань (з відносними й абсолютними пріоритетами, і за правилом LCFS) здійснюється наприкінці першої секції підпрограми обробки. Таким чином, на час виконання центральної секції (у випадку роботи в режимах з абсолютними пріоритетами і по дисципліні LCFS ) переривання дозволені. На час роботи заключної секції підпрограми обробки система переривань повинна бути відключена і після відновлення контексту знову включена. Оскільки ці дії необхідно виконувати практично в кожній підпрограмі обробки переривань, у багатьох операційних системах перші секції підпрограм обробки переривань виділяються в спеціальний системний програмний модуль, називаний супервізором переривань. Супервізор переривань зберігає в дескрипторі поточної задачі робочі регістри процесора, що визначають контекст обчислювального процесу, що переривається. Далі він визначає ту підпрограму, що повинна виконати дії, зв'язані з обслуговуванням поточного запиту на переривання. Нарешті, перед тим як передати керування цій підпрограмі, супервізор переривань установлює необхідний режим обробки переривання. Після виконання підпрограми обробки переривання керування знову передається супервізору, цього разу вже на той модуль, що займається диспетчеризацією задач. І вже диспетчер задач, в свою чергу, і відповідності з прийнятим режимом розподілу процесорного часу (між процесами, що виконуються,) відновить контекст тієї задачі, який буде вирішено виділити процесор. Розглянута нами схема проілюстрована на мал. 15.
Як ми бачимо з мал. 15, тут немає безпосереднього повернення в перервану раніше програму прямо із самої підпрограми обробки переривання. Для прямого безпосереднього повернення досить адреса повернення зберегти в стеці, що і робить апаратура процесора. При цьому стек легко забезпечує можливість повернення у випадку вкладених переривань, оскільки він завжди реалізує дисципліну LCFS (last come - fіrst served).
Супервізор переривань
Переривання
Рис. 15. Обробка переривання при участі супервізорів ОС.
Однак якби контекст процесів зберігався просто в стеці, як це звичайно реалізується апаратурою, а не в описаних вище дескрипторах задач, то в нас не було би можливості гнучко підходити до вибору тієї задачі, який потрібно передати процесор після завершення роботи підпрограми обробки переривання. Природно, що це тільки загальний принцип. У конкретних процесорах і в конкретних ОС можуть існувати деякі відступи від розглянутої схеми чи доповнення до неї. Наприклад, у сучасних процесорах часто маються спеціальні апаратні можливості для збереження контексту процесу, що переривається, безпосередньо в його дескрипторі; тобто дескриптор процесу (принаймні, його частина) стає структурою даних, що підтримує апаратура.