МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
ВОЛИНСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

ІМЕНІ ЛЕСІ УКРАЇНКИ
Кафедра прикладної математики
РЕФЕРАТ НА ТЕМУ:
РЕАЛІЗАЦІЯ ПОНЯТТЯ ПОСЛІДОВНОГО ПРОЦЕСУ. ДІАГРАМА СТАНІВ ПРОЦЕСУ
Виконав студент 34 групи

математичного факультету

спеціальності "інформатика"

Антончик Олександр
Перевірив:

Острей С. В.
ЛУЦЬК 2009

І.
Реалізація поняття послідовного процесу

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

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

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

В деяких операційних системах кількість дескрипторів визначається чітко і наперід (на етапі генерації варіантів операційної системи або в конфігураційному файлі, який використовується при завантаженні ОС), а інші – по мірі необхідності система може виділяти ділянки пам’яті під нові дескриптори. Наприклад, в ОS/2 максимальна кількість дескрипторів задається в конфігураційному файлі CONFIG.SYS, а в Windows NT вона в явному вигляді не задається. В цьому файлі вказується не кількість процесів, а саме задач, і під задачею в даному випадку розуміють як процес так і набір процесів.

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

Для більш ефективного опрацювання даних в системах реального часу необхідно мати постійні задачі, повністю або частково існуючі в системі, незалежно від того, виконується задача в даний момент чи ні. Кожна постійна задача має деяку область власної оперативної пам’яті, незалежно від того виконується ця задача в даний момент чи ні. Ця область може використовуватись для зберігання даних, отриманих раніше задач. Дані можуть зберігатися в ній, коли задача знаходиться в стані очікування і навіть в стані бездії.
ІІ.
Діаграма станів процесу

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

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

Активний процес може знаходитись в одному із наступних станів:

• 
  Виконання – всі необхідні процесу ресурси надані. В цьому стані в кожен момен часу може знаходитись лише один процес, якщо мова йде про однопроцесорну опбчислювальну систему.
  
• 
  Готовність до виконання – ресурси можуть бути надані, тоді процес перейде в стан виконання.
  
• 
  Блокування або очікування – потрібні ресурси не можуть бути надані, або ж не завершена операція вводу/виводу.
  

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

В звичайних ОС процес з’являється після запуску будь-якої програми. ОС організовує для нового процесу відповідний дескриптор, і процес починає виконуватись. В системах реального часу наперід визначається склад програм, який буде виконуватись. Відомо багато їхніх параметрів, які необхідно враховувати при розподіленні ресурсів, наприклад, об’єм пам’яті, пріорітет, середній час виконання. Тому для них наперід роблять дескриптор, щоб потім не тратити на це час.

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



Процес із стану бездіяльності може перейти в стан готовності в таких випадках:

1. 
   По команді оператора (користувача). Має місце в діалогових операційних системах, де програма може мати статус задачі, а не просто бути виконуваним файлом і тільки на час виконання отримувати статус задачі.
   
2. 
   При виборі з черги планувальником (характерно для операційних систем, що працюють в пакетному режимі).
   
3. 
   По виклику із іншої задачі.
   
4. 
   По перериванню від зовнішнього ініціативного пристрою.
   
5. 
   При настанні запланованого часу запуску програми.
   

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

Із стану виконання процес може вийти по таких знаступних причин:

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

При настанні необхідної події процес деблокується і переходить в стан готовності.

Таким чином, керуючою силою у зміні станів процесу є події. Один із основних видів подій – це переривання.