Віртуальні переривання або сигнали

Дужки критичних секцій.

Системні засоби взаємодії процесів

Виділення критичних секцій, як системний засіб, доцільно застосовувати для відносно сильно зв'язаних процесів - таких, які розділяють великий об'єм даних. Крім того, при застосуванні програмістом дужок критичних секцій можливі помилки, що приводять до придушення одних процесів іншими, важливо, щоб конфлікти між процесами не приводили до конфліктів між користувачами. Ці властивості характерні для ниток - частин одного і того ж процесу, що паралельно виконуються: вони всі належать одному процесу - одному користувачеві і розділяють майже всі ресурси цього процесу. Отже, критичні секції доцільно застосовувати тільки для взаємного виключення ниток. ОС може надавати для цих цілей елементарні системні виклики, функціонально аналогічні розглянутим нами в попередньому розділі csBegin і csEnd. Коли нитка входить в критичну секцію, решта всіх ниток цього процесу блокується. Блокування не зачіпає інші процеси і їх нитки. Природно, що така політика вельми консервативна і знижує рівень мультипрограмування, але це може вплинути на ефективність тільки в рамках одного процесу. Програміст може самостійно організувати і ліберальнішу політику доступу до ресурсів, що розділяються, використовуючи, наприклад, семафори, які будуть описані нижчим.

Крім того, роль таких дужок можуть грати системні виклики типу suspend і release, перший з яких припиняє виконання нитки, а другий - відміняє припинення.

Ми вже говорили про віртуальні переривання, як про засіб, за допомогою якого ОС сигналізує процесу про закінчення асихронно виконуваної операції введення-виводу. Розширюючи цю концепцію, можна застосовувати віртуальні переривання для повідомлення процесу про будь-яку зовнішню по відношенню до нього подію. Зокрема, віртуальне переривання може використовуватися для того, щоб видавати синхронізуючий сигнал з одного процесу в іншій. ОС може надавати в розпорядження процесів системний виклик:

raiseInterrupt (pid, intType );

де pid - ідентифікатор процесу, якому посилається переривання, intType - тип (можливо, номер) переривання. Ідентифікатор процесу - це не зовнішнє його ім'я, а маніпулятор, що встановлюється для кожного запуску процесу ОС. Для того, щоб процес міг послати сигнал іншому процесу, процес-відправник повинен знати ідентифікатор процесу-одержувача, тобто, знаходитися з ним в достатньо "конфіденційних" відносинах. Щоб запобігти можливості посилки непередбачених переривань, можуть бути введені додаткові обмеження: вирішити посилку переривань тільки від процесів-предків до нащадків або обмежити обмін перериваннями тільки процесами одного і того ж користувача.

Коли процесу посилається переривання, управління передається на обробник цього переривання у складі процесу. Процес повинен встановити адресу обробника за допомогою системного виклику типу:

setInterruptHandler (intType, action, procedure );

де action - вид реакції на переривання. Вид реакції може задаватися з переліку стандартних, в число яких можуть входити: реакція за умовчанням, ігнорувати переривання, відновити колишню установку або встановити як обробника переривання процедуру procedure, адреса якої є параметром системного виклику.

Зрозуміло, в системі повинні бути визначені допустимі типи віртуальних переривань. Віртуальні переривання можуть генеруватися в наступних випадках:

 завершення або інша зміна статусу процесу-нащадка;

 програмні помилки (переривання-пастки);

 помилки у виконанні системних викликів або неправильні звернення до системних викликів;

 термінальні дії (наприклад, натиснення клавіші "Увага" або Ctrl+Break);

 при необхідності завершення процесу (системний виклик kill);

 сигнал від таймера;

 сигнали, якими процеси обмінюються один з одним;

 і так далі

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

Ще одне рішення, яке повинен прийняти конструктор ОС, - чи є установка обробника постійною (до її явної відміни) або одноразовою (для обробки тільки одного переривання). Другий варіант є гнучкішим, оскільки кожна процедура обробки переривання може при необхідності закінчуватися новим системним викликом setInterruptHandler, яким буде задана установка на обробку наступного переривання цього типу. Це рішення можна також перекласти на програміста, включивши відповідний параметр в специфікації системного виклику.

Як повинна реагувати ОС на посилку переривання неіснуючому процесу? Мабуть, аварійне завершення процесу, що видав таке переривання, може бути нормальною реакцією системи. Можливо, втім, і ліберальніше рішення - завершити виклик raiseInterrupt з ознакою помилки. Аналогічний ефект може викликати виконання переривання, для якого в процесі-приймачі встановлений спеціальний режим обробки - неприпустиме переривання.

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

У більшості сучасних ОС (Unix, OS/2 і ін.) віртуальні переривання носять назву сигналів і використовуються перш за все для сигналізації про надзвичайні події. Сигнальні системи конкретних ОС, як правило, не надають у складі API універсального виклику типу raiseInterrupt, який дозволяв би користувачеві видавати сигнали будь-якого типу. Набір зарезервованих типів сигналів обмежений (у Unix, наприклад, їх 19, а в OS/2 - всього 7), не всі з них доступно процесам, і для кожного з доступних є власний системний виклик. Недопустимі також незарезервовані типи сигналів. У набір включається декілька (по 3 - в згаданих ОС) типів сигналів, зарезервованих за процесами, ці типи і використовують взаємодіючі процеси для посилки один одному сигналів, які вони інтерпретують по попередній домовленості.

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Структура файлової системи	\|	Модель віртуальних комунікаційних портів

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.017 сек.