2. Керування процесами
Процес (process) - це користувальницька програма при її виконанні в комп'ютерній системі. Для виконання процесу потрібен ряд ресурсів, включаючи час процесора, пам'ять, файли, пристрої вводу-виводу, мережні пристрої й ін.
У класичній схемі UNIX, при створенні процесу для нього створюється новий простір віртуальної пам'яті, тобто таблиця сторінок для відображення віртуальних адрес у фізичні, своя для кожного нового процесу. При цьому витрачаються значні ресурси. Якщо врахувати, що в UNIX кожна команда користувача (наприклад, ls – вивід умісту поточної директорії) запускається як окремий процес, то стає зрозумілим, наскільки "дорога" операція створення процесу в класичному змісті. Тому ще в 1980-х рр. з'явилася концепція полегшеного процесу (lightweight process) – виконуваного в тім же просторі віртуальної пам'яті, що й процес-батько. При створенні нового полегшеного процесу ОС створює для нього тільки стік – системний резидентний масив у пам'яті, призначений для підтримки виконання процедур процесу й хранящий їхні локальні дані й сполучну інформацію між ними.
ОС відповідає за наступні дії, пов'язані з керуванням процесами:
Створення й видалення процесів. При створенні процесу необхідно створити в пам'яті відповідні системні структури (таблицю сторінок, стік й ін.). При видаленні процесу пам'ять, займана ними, звільняється, а також виконується закриття всіх файлів і звільнення всіх інших ресурсів, які використав процес, якщо останній не зробив цього явно.
Припинення й поновлення процесів. Виконання процесу припиняється при виконанні синхронного вводу-виводу, а також системного виклику або команди (типу suspend ). Відразу відзначимо, що використати подібні операції явного припинення процесів треба з обережністю, тому що припиняє процесс, що, може перебувати у своїй критичній секції – виконувати обробку загального ресурсу, до якого кожному процесу надається монопольний доступ, так що при його припиненні виникає ситуація тупика (deadlock ) – припинений процес не може звільнити ресурс, а конкуруючий процес не може його одержати. При припиненні процесу ОС зберігає стан його виконання, а при поновленні - відновлює.
Синхронізація процесів. Процеси працюють паралельно й при цьому конкурують за загальні ресурси, а також повинні в деякі моменти обчислень очікувати настання деяких подій. Для запобігання можливих конфліктів і непогодженостей, наприклад, race condition - неузгодженого доступу до загальних даних, при якому один процес читає старі дані, а інший їх у цей же момент обновляє, - ОС надає кошти синхронізації (наприклад, семафори й монітори, розглянуті в наступному розділі).
Взаємодія процесів. При своїй паралельній роботі процесам необхідне взаємодія, з метою погодженого рішення різних частин однієї й того ж завдання. Процеси можуть взаємодіяти за допомогою передачі повідомлень один одному, а також за допомогою так званих умовних змінних і рандеву . ОС надає всі ці засоби, у вигляді системних викликів, для організації адекватної й зручної взаємодії процесів.
Семафори.В 1966 р. у роботі [16] проф. Эдсгер Дейкстра запропонував новий спосіб синхронізації процесів, що став класичним, - семафори.
Двійковий семафор (binary semaphore) – змінна S, що може перебувати у двох станах: "відкритий" й "закритий"; над S визначені дві операції ( "семафорні дужки"): P(S) – закрити, V(S) – відкрити. При спробі закрити вже закритий семафор відбувається переривання, і ОС додає поточний процес у чергу до закритого семафора. Операція V(S) активізує перший вартий у черзі до S процес, що успішно завершує операцію P(S). Якщо семафор S уже відкритий, операція V(S) не має ніякого ефекту.
Таким чином, якщо припустити, що апаратури й ОС підтримують подібну концепцію семафора, то вона є зручним інструментом для синхронізації по ресурсах. Назвемо критичною секцією код, що може виконуватися декількома процесами паралельно й здійснює доступ до деякого загального для всіх процесів ресурсу – глобальної області пам'яті, загальному файлу й т.д. Позначимо код критичної секції critical_section.Якщо допустити, що даний код може виконуватися паралельно в декількох процесах прямо, то може виникнути вже відома нам ситуація race condition ( конкуренція за загальні дані): один процес може змінювати ресурс, а другий у цей момент зчитувати його (некоректне) стан, або два процеси одночасно будуть намагатися змінювати той самий ресурс, що приведе до порушення його цілісності. Таким чином, для критичних секцій необхідно вирішити завдання взаємного виключення (mutual exclusion) – у кожен момент часу не більш ніж один з паралельних процесів може виконувати критичну секцію. За допомогою семафорів Дейкстры це завдання вирішується легко й добірно: код критичної секції повинен мати вигляд
P(S); critical_section; V(S);
Справді, припустимо, що кілька процесів виконують даний код. Перший з них, що почав виконувати операцію P(S), закриває семафор S й одержує доступ до критичної секції. Всі інші процеси, які намагаються виконати операцію P(S) над закритим семафором S, перериваються й попадають у чергу до закритого семафора. Коли перший процес закінчив роботу з ресурсом, він відкриває семафор S операцією V(S) для першого процесу із черги, що, виконавши P(S), знову закриває семафор, і т.д.
Дуже важлива властивість операцій P й V у наступному: вони атомарны (atomic) для інших процесів, тобто якщо процес почав виконувати операцію P(S) або V(S), те ніякий інший процес до її завершення не може також почати виконувати аналогічну операцію.
Підіб'ємо підсумок: для синхронізації процесів по загальному ресурсі необхідне взаємне виключення виконання критичних секцій й атомарность операцій синхронізації.
Однак варто помітити, що використання семафорів – далеко не ідеальний спосіб синхронізації, з погляду надійності. При їхньому неакуратному використанні можлива ситуація тупика (взаємного блокування, deadlock ), при якій утвориться ланцюжок процесів, що нескінченно чекають один одного. Найпростіший спосіб створити deadlock – використати два семафори S1 й S2, так, що перший паралельний процес намагається виконати код P(S1); P(S2),а другий – код P(S2); P(S1).Очевидно, що при будь-якому співвідношенні часів виконання операцій будуть закриті обидва семафори, на яких і будуть "висіти" обидва процеси, не в змозі рушити далі. Як же уникнути подібних ситуацій? Адже ні компілятор, ні операційна система не підкажуть програмістові правильний спосіб використання семафорів. Дуже легко також "забути" виклик V(S) і, тим самим, зробити загальний ресурс "навіки" недоступним для інших процесів. Один зі способів рішення цього завдання полягає в тім, щоб використати спеціальні інструменти й технології, що автоматично забезпечують "правильну" послідовність застосування операцій над семафорами. Один з таких інструментів – аспектно-орієнтоване програмування.
Монітори – ще один, більше надійний спосіб синхронізації, запропонований в 1974 р. одним із класиків комп'ютерних наук професором Чарльзом Хоаром.
Монітор – многовходовый модуль M, у якому визначені загальні для процесів дані D (сховані) і (абстрактні) операції P1, … PN над цими даними (у вигляді процедур).
У кожен момент не більш ніж один з паралельних процесів може викликати яку-небудь із операцій: M.Pi (X, Y, ...)
Виклик кожної операції монітора - атомарен (як й операції над семафором).
Монітор - ще один зручний механізм синхронізації процесів по ресурсах. Він більше надійний, чим семафори, оскільки виклик операції монітора автоматично забезпечує розблокування ресурсу після завершення виклику.
Монітори включені Ч. Хоаром у розроблений їм мова Concurrent Pascal для паралельного програмування й розробки операційних систем.
Докладніше про семафори й монітори - у спеціальних розділах курсу, присвячених керуванню процесами й синхронізації процесів.
Система підтримки командного інтерпретатора
Більшість команд для ОС задаються за допомогою спеціальних керуючих операторів, призначених для виконання наступних основних функцій:
створення процесів і керування процесами ; наприклад, в UNIX команда ps –a виводить у стандартний вивід процесу інформацію про всі активні процеси в системі, із вказівкою їхніх номерів (PID);
виконання вводу-виводу; наприклад, у системі MS DOS команда type file_name виконує вивід на термінал умісту заданого текстового файлу;
керування вторинною пам'яттю; наприклад, в UNIX команда share /mydir додає директорію /mydir до списку спільно використовуваних у локальній мережі файлових систем;
керування основною пам'яттю; наприклад, команда swap в ОС Solaris дозволяє управляти розміром простору дискової пам'яті для реалізації віртуальної пам'яті (swap) і виводити інформацію про його стан;
доступу до файлової системи; наприклад, у більшості ОС команд cd new_dir установлює задану директорію в якості поточної (робочої);
захисту; наприклад, у системі UNIX команда chmod 700 my_home_dir захистить Вашу домашню директорію від непрошених цікавих очей – "вивідач" не зможе навіть виконати команду cd для цієї директорії й, тим більше, читати в ній які-небудь файли;
керування мережею; наприклад, команди telnet host_name й rlogin host_name (остання доступна в системі UNIX) служать для віддаленого входу на інший комп'ютер мережі.
Програма, що читає й інтерпретує оператори керування, називається командним інтерпретатором. В Windows це інтерпретатор command.com, доступний для виконання команд у вікні MS DOS prompt. В UNIX, Linux, Solaris це вже згадувані всілякі "шеллы": sh, csh, ksh, bash – процесори для інтерпретації потужних командних мов. Функція командного процесора полягає в тому, щоб прочитати й виконати черговий керуючий оператор (команду).
Сервис (служби) ОС
Операційна система надає для користувачів цілий ряд сервісних можливостей, або, коротко, сервісів (служб ):
Виконання програм – завантаження програми на згадку і її виконання; наприклад, в Windows при запуску програми ОС знаходить у файлі її двійкового коду ( .exe ) так називану заглушку для виконання (execution stub), що містить посилання на код головного методу main, і запускає його. У середовищі .NET цей же execution stub у файлі двійкового коду використається системою для виклику не програми, що виконує безпосередньо, а загального оточення часу виконання - Common Language Runtime (CLR), що забезпечує особливий режим (managed execution) виконання програми.
Підтримка вводу-виводу – забезпечення інтерфейсу для роботи програм із пристроями вводу-виводу. Наприклад, в UNIX у кожної програми є свої стандартне ввод й стандартний вивід (за замовчуванням це термінал). У більше старих ОС, наприклад, IBM 360, прив'язку програми до пристроїв вводу-виводу було потрібно специфицифікувати за допомогою громіздких DD (Data Definition) - пропозицій спеціальною мовою керування завданнями.
Робота з файловою системою – надання програмам інтерфейсу для створення, іменування, видалення файлів.
Комунікація – обмін інформацією між процесами, виконуваними на одному комп'ютері або на інших системах, зв'язаних у мережу. В операційних системах реалізується за допомогою загальної пам'яті ( shared memory) або передачі повідомлень.
Виявлення помилок у роботі процесора, пам'яті, пристроїв вводу-виводу й програмах користувачів.
Системні виклики (system calls) є інтерфейсом між виконуваною програмою й операційною системою
Звичайно системні виклики доступні як спеціальні ассемблерні команди, наприклад, в IBM 360 ассемблерна команда svc 10 виконує виклик супервізора (керуючої програми ОС) з номером системної функції 10.
Деякі мови (C, C++, Java й ін.) дозволяють виконувати системні виклики безпосередньо, не "опускаючись" до ассемблерного рівня, за допомогою викликів спеціальних бібліотечних функцій (методів) типу System("cd my_dir").
При системному виклику ОС із програми користувача виникає проблема передачі параметрів. Використаються три основних способи передачі параметрів виконує программой, що, операційній системі:
Передача параметрів у регістрах;
Запись параметрів у таблицю, розташовану в пам'яті, і передача адреси цієї таблиці в регістрі.
Запис (проштовхування) параметрів у стек програмою й читання (виштовхування) їх зі стека операційною системою. Такий спосіб набагато краще, тому що він є стандартним способом передачі параметрів при будь-якому виклику процедури або методу.
На рис. 6.1 зображено спосіб передачі параметрів при системному виклику через таблицю, адресу якої передається в регістрі.
Рис. 6.1. Передача параметрів системного виклику в таблиці.
Розрізняються наступні основні види системних викликів:
Керування процесами; наприклад, в UNIX системний виклик fork створює новий паралельний процес із новим простором віртуальних адрес.
Керування файлами; наприклад, в UNIX системний виклик open (f, "rw") здійснює відкриття заданого файлу для читання й запису.
Керування пристроями; наприклад, системний виклик rewind здійснює перемотування (позиціювання) магнітної стрічки на початок.
Супровідна інформація; наприклад, системний виклик env видає в стандартний вивід інформацію про значення змінних оточення – змінних із символьними значеннями, наприклад, PATH.
Коммунікації; наприклад, системний виклик CreateSocket створює новий сокет – системну структуру для обміну інформацією клієнта із сервером через TCP/IP – мережа.
Лекція 7. Рівні абстракції ОС. ОС с архітектурою мікроядра. Віртуальні машини. Мета проектування і розробки ОС.
План
Рівні абстракці ОїС
Операційні системи с мікроядром
Віртуальні машини – другий поширений подхід при розробці операційних систем і їх користувальницьких інтерфейсів
Віртуальна машина Java (JVM)
Цілі проектування і розробки ОС
Механізми і політики
Реалізация операційних систем
Генерація операційної системи
Проектування й реалізація операційних систем адекватно відповідають принципу рівнів абстракції, сформульованому Э. Дейкстром. На рис. 7.1 зображено рівні абстракції при розробці ОС.
Рис. 7.1. Рівні абстракції ОС.
Кожен новий рівень абстракції M визначає нові операції, у реалізації яких використаються операції попереднього рівня M-1. Крім того, рівень M-1 може мати сховані операції, використовувані тільки на цьому рівні й недоступні іншим рівням.
На рис. 7.2 зображено рівні абстракції операційної системи OS/2 – другий ОС (слідом за MS DOS), розробленою фірмою Microsoft (у середині 1980-х рр.) для персональних комп'ютерів PS/2. OS/2 є значно більше развитой ОС, чим MS DOS, як видно з малюнка.
Рис. 7.2. Рівні абстракції OS/2
На верхньому рівні абстракції прикладні програми користувачів звертаються до інтерфейсу прикладного програмування (application programming interface – API),що являє собою набір бібліотечних функцій. API структурований по підсистемах, причому набір підсистем розширюємо. Нижні рівні абстракції реалізують ядро ОС, що виконує функції керування пам'яттю, диспетчеризації завдань і керування пристроями. Нарешті, на найнижчому рівні абстракції реалізовані драйвери пристроїв.
Операційні системи з мікроядром
Мікроядро (micro-kernel) – один з найважливіших принципів розробки ОС, що полягає в переносі максимально можливого числа модулів із системного в користувальницьке "простір", тобто ОС розробляється таким чином, що більшість її модулів виконуються в користувальницькому режимі. Комунікація виконується між користувальницькими модулями за допомогою передачі повідомлень. Переваги такого підходу:
мікроядро легше розширювати;
легше переносити ОС на нові апаратні платформи;
збільшується надійність ОС, тому що більше число програм виконуються в непривілейованому режимі;
поліпшується безпека ОС.
По такому принципі розроблені всі операційні системи сімейства Windows NT. Структура Windows NT зображена на рис. 7.3.
Рис. 7.3. Клієнт - серверна структура Windows NT.
Система Windows NT (від New Technology), розроблена в середині 1990-х рр., втілила в собі новий підхід Microsoft до розробки операційних систем. Його відмінні риси: модульна клієнт-серверна архітектура, мікроядро, забезпечення сумісності з розповсюдженими видами додатків для інших ОС (наприклад, OS/2), розширені мережні можливості, підвищена надійність. Windows NT із середини 1990-х рр. широко поширилася як серверна ОС. Для сумісності з додатками для інших ОС, в Windows NT реалізовані відповідні сервери. Взаємодія клієнтських додатків з ними показано на схемі. Абревіатура Win32 означає "бібліотеки (API) ОС Windows для 32-розрядних процесорів". POSIX (Portable Operating Systems of unIX type) – стандарт для бібліотек, системних викликів і системних програм для операційних систем типу UNIX. POSIX-сумісність означає, що додаток, призначений для UNIX, використає тільки стандартні можливості. Всі сучасні ОС (починаючи з Windows NT) забезпечують сумісність із POSIX-додатками. Помітимо, що всі сервери для сумісності з іншими ОС в Windows NT виконуються в непривілейованому режимі, але звертаються до мікроядра.