1. Базові дисципліни планування psjn, hprn

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

HPRN дисципліна без витіснення, що забезпечує як найкращі показники справедливості. Це досягається за рахунок динамічного пре визначення пріоритетів. Всякий раз при звільненні ЦП для всіх готових процесів обчислюється поточне штрафне відношення:

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

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

БІЛЕТ № 12

1. Базові дисципліни планування srr, mlfb

1. метод з витісненням, що дає додаткові переваги виконуваним процесам що дозволяє підвищити пропускну спроміжність. Всі процеси розділяються на 2 категорії нові і вибрані. Новими вважаються ті процеси, які не отримали ще жодного кванта часу ЦП, решта всіх процесів вибрані.

2. черга з великим номером не обслуговується до тих пір поки є процеси в чергах з меншими номерами.

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

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

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

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

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

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

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

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

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

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

• і так далі

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

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

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

Білет № 13