Блок управління процесом і контекст процесу

Для того щоб операційна система могла керувати процесами, вона повинна мати всю необхідну для цього інформацією. З цією метою на кожен процес зводиться спеціальна інформаційна структура, яка називається дескриптором процесу (блоком управління процесом, Process Control Block - PCB). У загальному випадку дескриптор процесу містить наступну інформацію:

- ідентифікатор процесу (так званий PID - process identificator);

- тип (або клас) процесу, який визначає для супервізора деякі правила надання ресурсів;

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

- змінну стану, яка визначає, в якому стані знаходиться процес (готовий до роботи, в стані виконання, очікування пристрої введення / виводу і т.д.);

- інформацію про ресурсах, якими процес володіє і / або має право користуватися (покажчики на відкриті файли, інформація про незавершені операції введення / виводу і т. п.);

- параметри часу запуску (момент часу, коли процес повинен активізуватися, і періодичність цієї процедури);

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

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

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

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

Для апаратної підтримки роботи операційних систем з цими інформаційними структурами (дескрипторами завдань) в процесорах можуть бути реалізовані відповідні механізми. Так, наприклад, в мікропроцесорах Intel80х86, починаючи з 80286, є спеціальний регістр TR (task register), який вказує місцезнаходження TSS (сегмента стану завдання), в якому при перемиканні з задачі на задачу автоматично зберігається вміст регістрів процесора. Як правило, в сучасних ОС для цих мікропроцесорів дескриптор завдання включає в себе TSS. Іншими словами, дескриптор завдання більше за розміром, ніж TSS, і включає в себе такі традиційні поля, як ідентифікатор завдання, її ім'я, тип, пріоритет і т. П.

Схожі статті