
- •Процеси та потоки Процеси
- •Модель процесу
- •Створення процесу
- •Завершення процесу
- •Ієрархія процесів
- •Стани процесу
- •Реалізація процесу
- •Класична модель потоків
- •Реалізація потоків в просторі користувача
- •Реалізація потоків в просторі ядра
- •Активація планувальника
- •Спливаючі потоки
- •Взаємодія процесів
- •Змагання між процесами
- •Критична секція
- •Блокуючі змінні
- •Строге чергування
- •Алгоритм Петерсона
- •Команда tsl
- •Завдання виробника і споживача. Sleep і wakeup.
- •Семафори
- •М’ютекси
- •Монітори
- •Завдання алгоритму планування
Стани процесу
На рис. показана діаграма, що відображає три стани, в яких може перебувати процес:
-
виконується (що використовує в даний момент центральний процесор);
-
готовий (працездатний, але тимчасово призупинений, щоб дати можливість виконання іншому процесу);
-
заблокований (нездатний виконуватися, поки не виникне яка-небудь зовнішня подія).
Процес блокується через те, що, за логікою, він не може продовжуватися, як правило тому, що він очікує недоступних на даний момент вхідних даних. Може статися й так, що зупиняється той процес, який в принципі готовий до роботи і може бути запущений, а причина криється в тому, що операційна система вирішила на деякий час виділити центральний процесор іншому процесу. Ці дві умови повністю відрізняються одна від одної. У першому випадку призупинення породжене якою-небудь проблемою. У другому випадку на перший план виступає технічна сторона питання (не вистачає центральних процесорів, щоб кожному процесу виділити свій власний процесор).
Перехід 1 відбувається в тому випадку, якщо операційна система визначити, що процес в даний момент виконуватися не може. У деяких системах для переходу в заблокований стан процес може здійснити такий системний виклик, як pause.
Переходи 2 і 3 викликаються планувальником процесів, який є частиною операційної системи, без будь-якого сповіщення самого процесу. Перехід 2 відбувається в тому випадку, коли планувальник вирішить, що виконуваний процес просунувся досить далеко і настав час дозволити іншому процесу отримати частку робочого часу центрального процесора. Перехід 3 відбувається в тому випадку, коли всі інші процеси отримали належну їм частку часу і настав момент отримати центральний процесор першому процесу для відновлення його виконання.
Перехід 4 здійснюється в тому випадку, якщо відбувається зовнішня подія, очікувана процесом (наприклад, надходження вхідних даних).
Таким чином, замість того щоб думати про переривання, ми можемо думати про користувацькі процеси, процеси роботи з диском, процеси роботи з терміналом і т. д., які блокуються, коли очікують якихось подій.
В результаті такого подання виникає модель, показана на рис. На цьому малюнку самим нижнім рівнем операційної системи є планувальник, над яким зображений ряд процесів. Вся обробка переривань і подробиці дій, що запускають і зупиняють процеси, тут приховані під тим, що називається планувальником, для реалізації якого використовується порівняно невеликий обсяг коду.
Реалізація процесу
Для реалізації моделі процесів операційна система веде таблицю (що складається з масиву структур), що називається таблицею процесів, в якій кожен запис відповідає якому-небудь процесу. Ці записи містять важливу інформацію про стан процесу, включаючи лічильник команд, покажчик стека, розподіл пам'яті, стан відкритих ним файлів, його облікову та планувальну інформацію і все інше, що стосується процесу, що має бути збережене, коли процес перемикається з стану виконання в стан готовності або блокування, щоб пізніше він міг би відновити виконання, як ніби ніколи й не зупинявся.
У табл. 2.1 показаний ряд ключових полів типової системи.
Як же ж створюється ілюзія паралельної роботи послідовних процесів на одному процесорі. В пам’яті існує область пов’язана з кожним класом пристроїв вводу-виводу, яка називається вектором переривання.
У ньому міститься адреса процедури, яка обслуговує переривання. Припустимо, що при виникненні дискового переривання виконувався користувальницький процес № 3. Лічильник команд цього процесу, слово стану програми, а іноді й один або кілька регістрів поміщаються в поточний стек апаратними засобами переривання. Потім комп'ютер переходить на адресу, вказану в векторі переривання. На цьому робота апаратних засобів закінчується, і вступає в дію програмне забезпечення, а саме процедура обслуговування переривання.
Всі переривання спочатку зберігають стан регістрів, часто використовуючи для цього запис поточного процесу в таблиці процесів. Потім інформація, вміщена в стек перериванням, видаляється, і покажчик стеку встановлюється заново на тимчасовий стек, використовуваний оброблювачем переривання. Такі дії, як збереження регістрів і перевстановлення покажчика стеку, не можуть бути виражені на мовах високого рівня (наприклад, С), тому вони виконуються невеликою підпрограмою на мові асемблера.
Коли ця підпрограма завершує свою роботу, вона викликає С-процедуру, яка робить всю іншу роботу для даного конкретного типу переривання. Коли обробка переривання закінчиться і ми знову повернемось до готового до виконання процесу управління передасться назад коду, написаному на мові асемблера, щоб він завантажив для нового поточного процесу регістри і карту пам'яті і запустив виконання цього процесу.
Моделювання режиму багатозадачності
Для оцінки часу задіяння центрального процесора введемо функцію від аргументу n, який називається ступенем багатозадачності.
Час задіяна ЦП = 1 – pn, де p – час очікування завершення операції введення-виведення процесом, n – кількість процесів у пам’яті, отже pn - ймовірність того, що всі n процесів очікують завершення вводу-виводу (в разі чого процесор простоює).
Потоки
У традиційних операційних системах у кожного процесу є адресний простір і єдиний потік управління. Проте нерідко виникають ситуації, коли непогано було б мати декілька потоків управління в одному і тому ж адресному просторі, які б виконувались квазіпаралельно.
Причини використання потоків:
-
Основна причина використання потоків полягає в тому, що в багатьох додатках одночасно відбувається кілька дій, частина яких може періодично бути заблокованою. Модель програмування спрощується за рахунок розділення такого додатку на кілька послідовних потоків, які виконуються в квазіпаралельному режимі.
-
Другим аргументом на користь потоків є легкість (тобто швидкість) їх створення та ліквідації в порівнянні з більш «важкими» процесами. У багатьох системах створення потоків здійснюється в 10-100 разів швидше, ніж створення процесів.
-
Третій аргумент на користь потоків також стосується продуктивності. Коли потоки працюють в рамках одного центрального процесора, вони не приносять ніякого приросту продуктивності, але коли проводяться значні обчислення, а також значна частина часу витрачається на очікування введення-виведення, наявність потоків дозволяє цим діям перекриватися за часом, прискорюючи роботу програми.
-
І нарешті, потоки досить корисні для систем, що мають кілька центральних процесорів, де є реальна можливість паралельних обчислень.
Прикладом використання потоків може послужити веб-срвер показаний на малюнку:
Один з потоків - диспетчер - читає вхідні запити з мережі. Після аналізу запиту він вибирає заблокований робочий потік і передає йому запит, можливо, шляхом запису покажчика на повідомлення в спеціальне слово, пов'язане з кожним потоком. Потім диспетчер пробуджує сплячий робочий потік, переводячи його із заблокованого стану в стан готовності. При пробудженні робочий потік перевіряє, чи може запит бути задоволений з кешу веб-сторінок, до якого мають доступ усі потоки. Якщо ні, то він приступає до операції читання, щоб отримати веб-сторінку, з диска і блокується до тих пір, поки не завершитися дискова операція. Коли потік блокується на дисковій операції, вибирається виконання іншого потоку, можливо, диспетчера, з метою отримання наступного завдання або, можливо, іншого робочого потоку, який знаходиться в готовності до виконання.
Приблизний приклад коду багато поточного веб-сервера:
На противагу багато поточному веб-серверу розглянемо одно поточний. Основний цикл веб-сервера отримує запит, аналізує його і завершує обробку до отримання наступного запиту. Очікуючи завершення дискової операції, сервер простоює і не обробляє ніяких інших вхідних запитів. Якщо веб-сервер запущений на спеціально виділеній машині, а так найчастіше і буває, то центральний процесор, чекаючи завершення дискової операції, залишається без діла. У кінцевому підсумку відбувається значне скорочення запитів, що обробляються в секунду. Таким чином, потоки істотно підвищують продуктивність, але кожен з них програмується послідовно, тобто звичайним способом.
Досі ми бачили дві можливі конструкції: багато поточний і однопоточний веб-сервери, але існує і третій варіант, який зумовлений існуванням неблокуючих системних викликів. В таких системах при надходженні запиту його аналізує один-єдиний потік. Якщо запит може бути задоволений з кешу, то все в порядку, але якщо ні, то стартує неблокуюча дискова операція.
Сервер записує стан поточного запиту в таблицю, а потім очікує надходження наступної події. Цією подією може бути або запит на нове завдання, або відповідь від диску, пов'язаний з попередньою операцією. Якщо це нова задача, то процес починає її виконання. Якщо це відповідь від диску, то з таблиці вибирається відповідна інформація і відбувається обробка відповіді. При використанні неблокуючого введення-виведення відповідь, напевно, повинна прийняти форму сигналу або переривання.
Стан обчислення повинно бути явним чином збережено і відновлено з таблиці при кожному перемиканні сервера з обробки одного запиту на обробку іншого. В результаті потоки і їх стеки імітуються більш складним чином. Подібна конструкція, в якій у кожного обчислення є стан і є деякий набір подій, які можуть відбуватися з метою зміни стану, називаються машиною з кінцевим числом станів (finite-state machine), або кінцевим автоматом.