Безліч переривань

Дотепер ми розглядали випадок виникнення одиночного переривання (запиту переривання). Але припустимо, що в системі існує кілька пристроїв, що є потенційними джерелами запитів переривання (наприклад, програма одночасно може одержувати інформацію від вилученого термінала і посилати оброблені дані на печатку). Принтер (точніше, модуль керування принтером) буде генерувати запит переривання після завершення виводу чергового символу, а контролер лінії зв'язку з вилученим терміналом буде генерувати свій запит переривання всякий раз, коли одержить чергову порцію даних. Цією порцією може бути блок фіксованої довжини чи окремий байт — усе залежить від конструкції контролера, а в кінцевому рахунку — від протоколу зв'язку. У будь-якому випадку немає ніякої гарантії, що один із запитів не надійде в той час, коли інший ще обробляється.

У роботі переривання з безліччю запитів, що надійшли одночасно існує два принципово різних підходи. Перший полягає в тому, що один із запитів, що надійшов, забороняє (блокує) всі інші доти, поки його обробка не буде завершена. Режим заборони переривання означає, що процесор ігнорує всі запити, що надходять. Сигнали відкинутих запитів не пропадають — просто процесор якийсь час на них не реагує. Як тільки заборона переривань буде знята, процесор відреагує на "зведений" запит як звичайно. Заборона переривання знімається відразу ж після завершення обробки поточного переривання, ще перед тим як буде відновлене виконання перерваної програми користувача. У результаті запити переривання, що надійшли, обробляються послідовно (мал. 7.10,а).

Такий підхід досить просто реалізується, але має істотний недолік — він не дозволяє "ранжувати" джерела переривання, виділити серед них більш і менш важливі — перед механізмом заборони усі рівні (воістину, закони комп'ютерного світу відбивають закони світу, у якому живуть їхні творці). Якщо, наприклад, з'являється запит переривання від каналу зв'язку з терміналом, бажано обробити його якнайшвидше і вважати порцію, що надійшла, оскільки за нею, швидше за все, піде інша. Якщо обробка першого переривання буде відкладена, то друга порція даних може бути попросту загублена (щоб цього не сталося, використовуються досить складні протоколи обміну).

Другий підхід полягає в тому, що обробка переривання, у свою чергу, може бути перервана іншим перериванням. Для керування цим процесом з перериваннями зв'язуються визначені атрибути, що відбивають значимість (пріоритет) кожного з них (приналежність до визначеного "стану"). Запит переривання з більш високим пріоритетом може перервати обробку переривання з більш низьким, але не навпаки (мал. 7.10,6).

Як приклад застосування другого підходу розглянемо комп'ютерну систему, у якій мається три пристрої вводу-виводу: принтер, диск і модуль передачі даних по лінії зв'язку з вилученим терміналом (контролер лінії зв'язку). Переривання від кожного з цих пристроїв мають свій пріоритет — 2, 4 і 5 відповідно для принтера, диска і контролера лінії зв'язку.

На мал. 7.11 показана можлива послідовність надходження запитів на переривання від цих пристроїв. Виконання основної програми починається в момент t =0. У момент t=10 принтер генерує запит переривання. Дані про поточні стані основної програми містяться в системний стек, і починається виконання програми обробки переривання (ПІП) принтера. У момент, коли ця програма ще знаходиться в стадії виконання, контролер лінії зв'язку з терміналом генерує свій запит переривання. Оскільки цей запит має більш високий пріоритет, ніж запит переривання від принтера, процесор реагує на нього, перериває виконання ПІП принтера, запам'ятовує стан цієї програми в стеці і починає виконання ПІП контролера. У момент генерується новий запит переривання, цього разу контролером диска. У цей час ПІП контролера лінії зв'язку усе ще виконується і, оскільки переривання диска має більш низький пріоритет, процесор на нього не реагує (але запит переривання при цьому не знімається). У результаті виконання ПІП контролера благополучно завершується в момент t =25. Після цей процесор відновлює стан останньої перерваної програми, якою є ПІП принтера. Але ще до того як буде виконана перша чергова команда цієї ПІП, процесор проаналізує наявні запити переривання. Оскільки запит контролера диска як і раніше зведений і переривання диска має більш високий пріоритет, чим переривання принтера, то йому буде віддана перевага, і виконання ПІП відновлена не буде. Замість нього керування буде передане ПІП диску. І тільки після завершення ПІП диска (момент t=35) буде відновлене виконання ПІП принтера. І нарешті, коли і виконання ПІП принтера завершиться, відновиться виконання основної програми (момент t =40).