Обробка переривань і помилок

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

Одна і та ж процедура обробки переривання може застосовуватися для декількох пристроїв вводу-виводу (наприклад, якщо ці пристрої використовують одну лінію переривань, що йде від них до контроллера переривань), тому перша дія власне програми обробки полягає у визначенні того, яке саме пристрій видало переривання. Знаючи пристрій, ми можемо виявити процес, який ініціював виконання відповідної операції. Оскільки переривання виникає як при вдалому, так і при невдалому її виконанні, наступне, що ми повинні зробити, – це визначити успішність завершення операції, перевіривши значення біта помилки в регістрі стану пристрою. В деяких випадках операційна система може зробити певні дії, направлені на компенсацію виниклої помилки. Наприклад, у разі виникнення помилки читання з гнучкого диска можна спробувати кілька разів повторити виконання команди. Якщо компенсація помилки неможлива, то операційна система згодом сповістить про це процес, що запитав виконання операції (наприклад, спеціальним кодом повернення з системного виклику). Якщо цей процес був заблокований до виконання операції, що завершилася, то операційна система переводить його в стан готовність. За наявності інших незадоволених запитів до пристрою, що звільнився, операційна система може ініціювати виконання наступного запиту, одночасно сповістившись пристрій, що переривання оброблене. На цьому, власне, обробка переривання закінчується, і система може приступати до планування використання процесора.

Дії з обробки переривання і компенсації виникаючих помилок можуть бути частково перекладені на плечі відповідного драйвера. Для цього до складу інтерфейсу між драйвером і базовою підсистемою вводу-виводу додають ще одну функцію – функцію обробки переривання intr.

Планування запитів

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

Після завершення виконання поточного запиту операційна система (по ходу обробки виниклого переривання) повинна вирішити, який із запитів в списку має бути задоволений наступним, і ініціювати його виконання. Точно так, як і для вибору чергового процесу на виконання із списку готових нам доводилося здійснювати короткострокове планування процесів, тут нам необхідно здійснювати планування застосування пристроїв, користуючись яким-небудь алгоритмом цього планування. Критерії і цілі такого планування мало відрізняються від критеріїв і цілей планування процесів.

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