48. Задачі, що вирішуються на кожному з рівнів планування процесів.

1) Вибір моменту часу для заміни процесу, що виконується.

2) Вибір процесу на виконання з черги готових процесів.

3) Переключення контекстів „старих” і „нових” процесів.

та розв’язуються програмними засобами, а в значній мірі апаратно.

49. Основні вимоги до планування процесів.

Можливість паралельного виконання потоків залежить від кількості доступних процесорів. Якщо процесор один, паралельне виконання неможливе принципово (у кожен момент часу може виконуватися тільки один потік). Якщо кількість процесорів N>1, паралельне виконання може бути реалізоване тільки для N по токів (по одному потокові на процесор).

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

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

50.Планування процесів з переключенням та без переключення.

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

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

Наприклад: Якщо в системах реального часу пропаде хоча б один важливий сигнал переривання, це може привести до катастрофічних наслідків.

В системах без переключення, коротким завданням треба більше чекати через виконання тривалих завдань, але для всіх завдань створюються ніби-то рівні умови. Час відповіді тут легше передбачити, оскільки завдання високого пріоритету, що надходять, не можуть відтіснити завдання, що вже чекають.

51.Особливості процесів в ос unix.

Найбільш важлива інформація про процес зберігається в двох місцях:

- в таблиці процесів;

- в таблиці користувача (контекст процесу).

Перша – завжди знаходиться в пам’яті і містить на кожний процес по одному елементу, в якому відображається точний стан процесу:

– розташування процесу (адреса в пам’яті або адреса свопінгу);

– розмір;

– ідентифікатори процесу;

– ідентифікатори користувача що запустив процес.

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

52.Недоліки традиційної багатопотоковості в Linux.

Основи підтримки багатопотоковості в ядрі Linux не зазнали принципових змін від появи системного виклику clone(). За цей час Linux із експериментальної системи перетворився на систему промислового рівня, в якій виконують корпоративні застосування в цілодобовоу режимі з великим навантаженням.

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

Керування потоками є частиною стандарту POSIX з 1996 року, відповідний програмний інтерфейс дістав назву потоки POSIX.

53.Особливості нової реалізації багатопотоковості в Linux.

Нова реалізація багатопотоковості у ядрі системи має такі особливості.

• Підвищилася продуктивність операції створення і завершення потоків. Знято обмеження на загальну кількість потоків у системі. Система залишається ста більною за умов одночасного створення і завершення сотень тисяч потоків (за наявності достатнього обсягу оперативної пам'яті)

• Усі потоки процесу тепер повертають один і той самий ідентифікатор (pid), крім того, зв'язок ≪предок-нащадок≫між ними не підтримується (у створеного потоку зберігається той самий предок, що й у потоку-творця). Як процес у системі реєструють тільки початковий потік застосування.

• Реалізацію виклику сlone() розширено таким чином, щоб зробити непотрібним потік-менеджер.