Запуск застосування одним системним викликом
Керування введенням-виведенням
Операційна система відповідає за керування пристроями введення-виведення, підключеним до комп’ютера. Підтримка таких пристроїв в ОС звичайно здійснюється на двох рівнях. До першого, нижчого, рівня належать драйвери пристроїв – програмні модулі, які керують пристроями конкретного типу з урахування усіх їхніх особливостей. До другого рівня належить універсальний інтерфейс введення-виведення, зручний для використання у прикладних програмах.
ОС має реалізовувати загальний інтерфейс драйверів введення-виведення, через який вони взаємодіють з іншими компонентами системи. Такий інтерфейс дає змогу спростити додавання драйверів для нових пристроїв.
Сучасні ОС надають великий вибір готових драйверів для конкретних периферійних пристроїв. Що більше пристроїв підтримує ОС, то більше в неї шансів на практичне використання.
1.3.4 Керування файлами та файлові системи
Для користувачів ОС і прикладних програмістів дисковий простір надається у вигляді сукупності файлів, організованих у файлову систему.
Файл – це набір даних у файловій системі, доступ до якого здійснюється за іменем. Термін “файлова система” може вживатися для двох понять: принципу організації даних у вигляді файлів і конкретного набору даних (зазвичай відповідної частини диска), організованих відповідно до такого принципу. У рамках ОС може бути реалізована одночасна підтримка декількох файлових систем.
Файлові системи розглядають на логічному і фізичному рівнях. Логічний рівень визначає зовнішне подання системи як сукупності файлів (які звичайно перебувають у каталогах), а також виконання операцій над файлами і каталогами (створення, вилучення тощо). Фізичний рівень визначае принципи розміщення структур даних файлової системи на диску або іншому пристрої.
1.3.5 Мережна підтримка
Мережні системи
Сучасні операційні системи пристосовані до роботи в мережі, їх називають мережгими операційними системами. Засоби мережної підтримки дають ОС можливість:
· надавати локальні ресурси (дисковий простір, принтери тощо) у загальне користування через мережу, тобто функціювати як сервер;
· звертатися до ресурсів інших комп’ютерів через мережу, тобто функціонувати як клієнт.
Реалізація функціональності сервера і клієнта базується на транспортних засобах, відповідальних за передачу даних між комп’ютерами відповідно до правил, обумовлених мережними протоколами.
Розподілені системи
Мережні ОС не приховують від користувача наявність мережі, мережна підтримка в них не визначає структуру системи, а збагачує її додатковими можливостями.Є також розподілені ОС, які дають змогу об’єднати ресурси декількох комп’ютерів у розподілену систему. Вона виглядає для користувача як один комп’ютер з декількома процесорами, що працюють паралельно. Розподілені та багатопрцесорні системиє двома основними категоріями ОС, які використовують декілька процесорів.
Безпека даних
Під безпекою даних в ОС розуміють забезпечення надійності системи (захисту даних від втрати у разі збоїв) і захист даних від несакціонованого доступу (випадкового чи навмісного).
Для захисту від несакнціонованого доступу ОС має забезпечувати наявність засобів аутентифікації користувачів (такі засоби дають змогу з’ясувати, чи э користувач тим, за кого себе видає; зазвичай для цього використовують систему паролів) та їхньої авторізації (дозволяють перевірити права користувача, що пройшов аутентифікацію, на виконання певної операції).
Інтерфейс користувача
Розрізняють два типи засобів взаємодії користувача з ОС: командний інтерпретатор (shell) і графічний інтерфейс користувача (GUI).
Командний інтерпретатор дає змогу користувачам взаємодіяти з ОС, викоритовуючи спеціальну командну мову (інтерактивно або через запуск
на виконання командних файлів). Команди такої мови змушують ОС виконувати певні дії (наприклад, запускати програми. Працювати із файлами).
Графічний інтерфейс користувача надає йому можливість взаємодіяти з ОС відкриваючи вікна і виконуючи команди за допомогою меню або кнопок. Підходи до реалізації графічного інтерфейсу доволі різноманітні: наприклад, у Windows-системах засоби його підтримки вбудовані в систему, а в UNIX вони є зовнішніми для системи і спираються на стандартні засоби керування введенням-виведенням.
Висновки
· Операційна система – це рівень програмного забезпечення, що перебуває між рівнями прикладних програм й апаратного забезпечення комп’ютера. Головне її призначення – зробити використання комп’ютерної системи простішим і підвищити ефективність її роботи.
· До основних функціональних компонентів ОС належать: керування процесами, керування пам’яттю, керування введенням-виведенням, керування файлами і підтримка файлових систем, мережна підтримка, забезпечення захисту даних, реалізація інтерфейсу користувача.
Розділ 2 Архітектура операційних систем
Операційну систему можна розглядати як сукупність компонентів, кожен з яких відповідає за певні функції. Набір таких компонентів і порядок їхньої взаємодії один з одним та із зовнішнім середовищем визначається архітектурою операційної системи.
Розглянемо основні поняття архітектури операційних систем, підходи до їх, особливості взаємодії ОС із зовнішнім середовищем. Реалізацію архітектури розглянемо на прикладі Linux.
2.1 Базові поняття архітектури операційних систем
2.1.1 Ядро системи. Привілейований режим і режим користувача
Базові компоненти ОС, які відповідають за найважливіши її функції, зазвичай перебувають у пам’яті постійно і виконуються у привілейованому режимі, називають ядром операційної системи (operating system kernel).
Існуючі на сьогодні підходи до проектування архітектури ОС по-різному визначають функціональність ядра. До найважливіших функцій ОС, викладання яких, звичайно, покладають на ядро, належать обробка переривань, керування пам’яттю, керування введенням-виведенням. До надійності та продуктивності ядра висувають підвищені вимоги.
Основною характерною ознакою ядра є те, що воно виконується у привілейованому режимі. Розглянемо особливості цього режиму.
Для забезпечення ефективного керування ресурсами комп’ютера ОС повинна мати певні привілеї щодо прикладних програм. Треба, щоб прикладні програми не втручалися в роботу ОС, і в одночас ОС повинна мати можливість втрутитися в роботубудь-якої програми, наприклад для перемикання процесора або розв’язання конфлікту в боротьбі за ресурси.
Для реалізації таких привілеїв потрібна апаратна підтримка: процесор має підтримувати принаймні два режими роботи – привілейований (захищений режим, режим ядра, kernel mode) і режим користувача (user mode). У режимі користувача недопустимі команди, які є критичними для роботи системи (перемикання задач, звертання до пам’яті за заданими межами, доступ до пристроїв введення-виведення тощо).
Розглянемо, яким чином використовуються різні режими процесора під час взаємодії між ядром і застосуваннями.
Після завантаження ядро перемикає процесор у привілейований режим і отримує цілковитий контроль над комп’ютером. Кожне застосування запускається і виконується в режимі користувача, де воно не має доступу до ресурсів ядра й інших програм. Коли потрібно виконати дію, реалізовану в ядрі, застосування робить системний виклик (system call). Ядро перехоплює його, перемикає процесор у привілейований режим, виконує дію, перемикає процесор назад у режим користувача і поветрає результат застосування.
Системний виклик виконується повільніше за виклик функції, реалізованої в режимі користувача, через те що процесор двічі перемикається між режимами. Для підвищення продуктивності в деяких ОС частина функціональності реалізована в режимі користувача, тому для доступу до неї системні виклики використовувати не потрібно.
2.2 Реалізація архітектури операційних систем
Розглянемо кілька підходів до реалізації архітектури операційних систем. У реальних ОС звичайно використовують деяку комбінацію цих підходів.
2.2.1 Монолітні системи
ОС, у яких усі базові функції сконцентровані в ядрі, називають монолітними системами. У разі реалізації монолітного ядра ОС стає продуктивнішою (процесор не перемикається між режимами під час взаємодії між її компонентами), але менш надійною (весь їїкод виконується у привілейованому режимі, і помилка в кожному з компонентів є критичною).
Монолітність ядра не означає, що всі його компоненти мають постійно перебувати у пам’яті. Сучасні ОС дають можливість динамічно розміщувати в адресному просторі ядра фрагменти коду (модулі ядра). Реалізація модулів ядра дає можливість також досягти його розширюваності (для додання нової функціональності досить розробити і завантажити у пам’ять відповідний модуль).
2.2.2 Багаторівневі системи
Компоненти багаторівневих ОС утворюють ієрархію рівнів (шарів, layers), кожен з яких спирається на функції попереднього рівня. Найнижчий рівень безпосередньо взаємодіє з апаратним забезпеченням, на найвищому рівніреалізуються системні виклики.
У традіційних багаторівневих ОС передача керування з верхнього рівня на нижчий реалізується як системний виклик. Верхній рівень повинен мати права на виконання цього виклику, перевірка ціх прав виконується за підтримки апаратного забезпечення. Прикладом такої системи є ОС Multics, розроблена у 60-роки. Практичне застосування цього підходу сьогодні обмежене через низьку продуктивність.
Рівні можуть виділятися й у монолітному ядрі; у такому разі вони підтримуються програмно і спричиняють спрщення реалізації системи. У монолітному ядрі визначають рівні:
· засоби абстрактування від устаткування, які взаємодіють із апаратним забезпеченням безпосередньо, звільняючи від реалізації такої взаємодії інші компоненти системи;
· базові засоби ядра, які відповідають за найфундаментальніші, найпростіші дії ядра, такі як запис блоку даних на диск. За допомогою цих засобів виконуються вказівки верхніх рівнів, пов’язані з керуванням ресурсами;
· засоби керування ресурсами (або менеджери ресурсів), що реалізують основні функції ОС (керування процесами, пам’яттю, введення—виведенням тощо). На цьому рівні приймаються найважливіші рішення з керування ресурсами, які виконуються з використанням базових засобів ядра;
· інтерфейс системних викликів, який служить для реалізації зв’язку із системним і прикладним програмним забезпеченням.
2.2.3 Системи з мікроядром
Одним із напрямів сучасних ОС полягає в тому, що у првілейованому режимі реалізована невелика частка функцій ядра, які і є мікроядром (microkernel). Інші функції ОС виконуються процесами режиму користувача (серверними процесами, серверами). Сервери можуть відповідати за підтримку файлової системи, за роботу із процесами, пам’яттю тощо.
Мікроядро здійснює зв’язок між компонентами системи і виконує базовий розподіл ресурсів. Щоб виконати системний виклик, процес (клієнтський процес, клієнт) звертається до мікроядра. Мікроядро посилає серверу запит, сервер виконує роботу і пересилає відповідь назад. А мікроядро переправляє його клієнтові. Клієнтами можуть бути не лише процеси користувача, а і інші модулі ОС.
Перевагами мікроядрового підходу є:
· невеликі розміри мікроядра, що спрощує його розробку й налагодження;
· висока надійність системи, внаслідок того що сервети працюють в режимі користувача й у них немає прямого доступу до апаратного забезпечення;
· більша гнучкість і розширюваність системи (непотрібні компоненти не займають місця в пам’яті, розширення функціональності системи зводиться до додавання в неї нового сервера);
· можливість адаптації до умов мережі (спосіб обміну даними між клєнтом і сервером не залежить від того, зв’язані вони мережою чи перебувають на одному комп’ютері).
Головним недоліком мікроядрового підходу є зниження продуктивності. Замість двох перемикань режиму процесора у разі системного виклику відбувається чотири (два - під час обміну між клієнтом і мікроядром, два – сервером і мікроядром).
Зазначений недолік є, швидше, теоретичним, на практиці продуктивність і надійність мікроядра залежить насамперед від якості його реалізації. Так, в ОС QNX мікроядро займає кілька кілобфйтів пам’яті й забезпечує мінімальний набір функцій, при цьому система за продуктивністю відповідає ОС реального часу.
2.2.4 Концепція віртуальних машин
У системах віртуальних машин програмним шляхом створюють копії апаратногозабезпечення (відбувається його емуляція). Ці копії (віртуальні машини) працюють паралельно, на кожній із них функціонує програмне забезпечення, з яким взаємодіють прикладні програми і користувачі.
2.3 Особливості архітектури: UNIX і Linux
2.3.1 Базова архітектура UNIX
UNIX є прикладои досить простої архітектури ОС. Більша частина функціональності цієї системи міститься в ядрі, ядро спілкується їз прикладними програмами за допомогою системних викликів Базова структура класичного ядра UNIX зображена на рис. 2.1.
Рисунок 2.1 Архітектура UNIX
Система складається із трьох основних компонентів: підсистеми керування процесами, файлової системи та підсистеми введення-виведення.
Підсистема керування процесами контролює створення та вилучення процесів, розподілення системних ресурсів між ними, міжпроцесову взаємодію, керування пам’яттю.
Файлова підсистема забезпечує єдиний інтерфейс доступу до даних, розташованих на дискових накопичувачах, і до периферійних пристроїв. Такий інтерфейс є однією з найважливіших особливостей UNIX. Одні й ті самі системні виклики використовують як для обміну даними із диском, так і для виведення на термінал або принтер (програма працює із принтером так само, як із файлом). Прицьому файлова система переадресовує запити відповідним модулям підсистеми введення-виведення, а ті – безпосередньо переферійним пристроям. Крім того, файлова підсистема контролює права доступу до файлів, які значною мірою визначають привілеї коритувача в системі.
Підсистема введення-виведення виконує запити файлової системи, взаємодіючи з драйверами пристроїв. В UNIX розрізняють два типи пристроїв: символьні (наприклад, принтер) і блокові (наприклад, жорсткий жиск). Основна відмінність між ними полягає в тому, що блоковий пристрій допускає прямий доступ. Для підвищення продуктивності роботи із блоковими пристроями використовують буферний кеш – ділянку пам’яті, у якій зберігаються дані, зчитані з диска останніми. Під час наступних звертань до цих даних вони можуть бути отримані з кеша.
2.3.2 Архітектура Linux
В ОС Linux можна виділити три основні частини:
· ядро, яке реалізує основні функції ОС (керування процесами, пам’яттю, введенням-виведенням тощо);
· системні бібліотеки, що визначають стандартний набір функцій для використання у застосуваннях (виконання таких функцій не потребує переходу у привілейований режим);
· системні утиліти (прикладні програми, які виконують спеціалізовані задачі).
Призначення ядра Linux йі його особливості
Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра перебувають в одному адресному просторі. У ядрі можна виділити кілька функціональних компонентів.
· Планувальник процесів – відповідає за реалізацію багатозадачності в системі (обробка переривань, робота з таймером, створення і завершення процесів, перемикання контексту).
· Менеджер пам’ті – виділяє окремий адресний простір для кожного процесу і реалізує підтримку віртуальної пам’ятті.
· Віртуальна файлова система – надає універсальний інтерфейс взаємодії з різними файловими системами та пристроями введння-виведення.
· Драйвери пристроїв – забезпечують безпосередню роботу з периферійними пристроями. Доступ до них здійснюється через інтерфейс віртальної файлової системи.
· Мережний інтерфейс – забезпечує доступ до реалізації мережних протоколів і драйверів мережних пристроїв.
· Підсистема міжпроцесової взаємодії – пропонує механізми, які дають змогу різним процесам у системі обмінюваться даними між собою.
Деякі із цих підсистем є логічними компонентами системи, вони завантажуються у пам’ять разом із ядром і залишаються там постійно. Компоненти інших підсистем (наприклад, драйвери пристроїв) вигідно реалізовувати так, щоб їхній код міг завантажуватия у пам’ять на вимогу. Для розв’язання цього завдання Linux підтримує концепцію модулів ядра.
Модулі ядра
Ядро Linux дає можливість на вимогу завантажувати у пам’ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) і виконують у привілейованому режимі.
Модулі ядра надають низку переваг.
· Код модулів може завантажуватися в пам’ять у процесі роботи системи, що спрощує налагодження компонентів ядра, насамперед драйверів.
· З’являється можливість змінювати набір компонентів ядра під час виконання: ті з них, які в цей момент не використовуються, можна не завантажувати у пам’ять.
· Модулі є винятком із правила, за яким код, що розшитює функції ядра, відповідно до ліцензії Linux має бути відкритим. Це дає змогу виробникам апаратного забезпечення розробляти драйвери під Linux, навіть якщо не заплановано надавати доступ до їхнього вихідгого коду.
Підтримка модулів у Linux складається із трьох компонентів.
· Засоби керування модулями дають можливість завантажувати модулі у пам’ять і здійснювати обмін даними між модулями та іншою частиною ядра.
· Засоби реєстрації драйверів дозволяють модулям повідомляти іншу частину ядра про те, що новий драйвер став доступним.
· Засоби розв’язання конфліктів дають змогу драйверам пристроїв резервувати апаратні ресурси і захищати їх від випадкового використання іншими драйверами.
Один модуль може зареєструвати кілька драйверів, якщо це потрібно (наприклад, для двох різних механізмів доступу до пристрою).
Модулі можуть бути завантажені заздалегідь – під час старту системи (завантажувальні модулі) або у процесі виконання програми, яка викликає їхні фукції. Після завантаження код модуля перебуває в тому ж самому адресному просторі, що й інший код ядра. Помилка в модулі є критичною для системи.
Особливості системних бібліотек
Системні біліотеки Linux є динамічними бібліотеками, котрі завантажуються у пам’ять тільки тоді, коли у них виникеє потреба. Вони виконують ряд функцій:
· реалізацію пакувальників системних викликів;
· розширення функціональності системних викликів (до таких бібліотек належить бібліотека введення-виведення мови С, яка реалізує на основі системних викликів такі функції, як printf();
· реалізацію службових функцій режиму користувача (сортування, функції обробки рядків тощо).
Застосування користувача
Застосування користувача в Linux використовують функції із системних бібліотек і через них взаємодіють із ядром за допомогою системних викликів.
Висновки
· Архітектура ОС визначає набір ії компонентів, а також порядок їхньої взаємодії один з одним та із зовнішнім середовищем.
· Найважливішим для вивчення архітектури ОС є поняття ядра системи. Основною характеристикою ядра є те, що воно виконується в привілейованому режимі.
· Основними типами архітектури ОС ємонолітна архітектура і архітектура на базі мікроядра. Монолітна архітектура вимагає, щоб головні функції системи були сконцентровані в ядрі, найважливішою її перевагою є продуктивність. У системах на базі мікроядра в привілейованому режимі виконуються тільки базові функції, основними перевагами таких систем є надійність і гнучкість.
· Операційна система безпосередньо взаємодіє з апаратним забезпечення комп’ютера. Сучасні комп’ютерні архітектури пропонують багато засобів підтримки операційних систем. Для зв’язку з апаратним забезпеченням в ОС виділяють рівень абстрагування від устаткування.
· Операцйна система взаємодіє із прикладнимим програмами. Вона надає набір системних викликиків для доступу до функцій, реалізованих у ядрі. Для прикладних програм системні виклики разом із засобами системних бібліотек доступні через інтерфейс програмування застосувань.
Розділ 3 Керування процесами і потоками
Розглянемо дві основні абстракції операційної системи, які описують виконання програмного коду – процеси і потоки – особливості їхньої реалізації в операційній системі, стани, в яких вони можуть перебувати, базові механізми роботи з ними (засоби створення, завершення, припинення виконання тощо).
3.1 Базові поняття процесів і потоків
3.1.1 Процеси і потоки в сучасних ОС
У сучасній операційній системі одночасно виконуються код ядра (що належить до його різних підсистем) і код програм коритувача. При цьому відбуваються різні дії: одні програми і підсистеми виконують інструкції процесора., інші зайняті введенням-виведенням, ще деякі очікують на запити від користувача або інших застосувань. Для спрощення керування цими діями в системі доцільно виділити набір елементарних активних елементів і визначити інтерфейс взаємодії ОС із цими елементами. Коли активний елемент зв’язати із програмою, яка виконується, ми прийдемо до поняття процесу.
Під процесом розуміють абстракцію ОС, яка об’єднує все необхідне для виконання однієї програми в певний момент часу.
Програма – це деяка послідовність машинних команд, що зберігається на диску, в разі необхідності завантажується у пам’ять і виконується. Можна сказати, що під час виконання програму представляє процес.
Однозначна відповідність між програмою і процесом встановлюється тільки в конкретний момент часу: один процес у різний час може виконувати код декількох програм, код однієї програми можуть виконувати декілька процесів одночасно.
Для успішного виконання прогами потрібні певні ресурси. До них належать:
· ресурси, необхідні для послідовного виконання пограмного коду (передусім, процесорний час);
· ресурси що дають можливість зберігати інформацію, яка забезпечує виконання програмного коду (регістри процесора, оперативна пам’ять тощо);
Ці групи ресурсів визначають дві складові частини процесу:
· послідовність виконуваних команд процесора;
· набір адрес пам’яті (адресний простір), у якому розташовані ці команди і дані для них.
Виділення ціх частин виправдане ще й тим, що в рамках одного адресного простору може бути кілька паралельно виконуваних послідовностей команд, що спільно використовують одні й ті ж самі дані. Необхідність розмежування послідовності команд і адресного простору підводить до поняття потоку.
Потоком (потік керування, нитка, thread) називанють набір послідовно виконуваних команд процесора, які використовують загальний простір процесу. Оскільки в системі може одночасно бути багато потоків, завдання ОС є організація перемикання процесора між ними і планування їхнього виконання. У багатопроцесорних системах код окремих потоків може виконуватися на окремих процесорах.
Таким чином, процесом називають сукупність одного або декількох потоків і захищеного адресного простору, у якому ці потоки виконуються.
Захищеність адресного простору процесу є його найважливішою характеристикою. Код і дані процесу не можуть бути прямо прочитані або перезаписані іншим процесом; у такий спосіб захищаються від богатьох
програмних помилок і спроб несанкціонованого доступу. Природно, що неприпустимим э тыльки прямий доступ (наприклад, запис у пам’ять за допомогою простої інструкції перенесення даних); обмін даниими між процесами принципово можливий, але для цьго мають бути використані спеціальні засоби, які називають засобами міжпроцесової взаємодії. Такі засоби складніше за прямий доступ і працюють повільніше, але при цьому забезпечують захист від випадкових помилок у разі доступу до даних.
На відміну від процесів, потоки розпоряджаються загальною пам’яттю. Дані потоку не захищені від доступу до них інших потоків за умови, що всі вони виконуються в адресному просторі одного процесу. Це надає додаткоаі можливості для розробки застосувань, але ускладнює програмування.
Захищений алресний простір процесу задає абстракцію виконання коду на окремій машині, а потік забезпечує абстракцію послідовного виконання команд на одному виділеному процесорі.
Адресний простір процесу не завжди відповідає адресам оперативної пам’яті. Наприклад, у ньому можуть відображатисяфайли або регістри контолерів введення –виведення, тому запис за певною адресою в цьому просторі призведе до запису у файл, або до виконання операції введення-виведення. Таку технологію називають відображенням у пам’ять (memory mapping).
3.1.2 Моделі процесів і потоків
Максимально можлива кількість процесів (захищених адресних просторів ) і потоків, які в них виконуються, може варіюватися в різних системах.
· В однозадачних системах є тільки один адресний простір, у якому в кожен момент часу може виконуватися один потік.
· У деяких вбудованих системах теж є один адресний простір (один процес), але в ньому дозволене виконання багатьох потоків. У цьому
разі можна організовувати паралельні обчислювання, але захист даних не реалізовано.
· У системах, подібних до традиційних версій UNIX, допускаэться наявнсть багатьох процесів, але в рамках адресного простору процесу виконується тільки один потік. Це традиційна однопотокова модель процесів. Поняття потоку в данній моделі не застосовують, а використовують термін “перемикання між процесами”, “планування процесів”, “послідовність команд процесу” тощо (тут під процесом розуміють єдиний потік).
· У більшості сучасних ОС (таких, як лінія Windows XP, сучасні версії UNIX) може бути багато процесів, а в адресному просторі кожного процесу – багато потоків. Ці системи підтримують багатопотоковість або реалізують модель потоків. Процес у такій системі називають багатопотоковим процесом.
Надалі для позначення послідовності виконуваних команд вживатемо термін “потік”, за винятком ситуацій, коли обговорютиметься реалізація моделі процесів.
3.1.3 Складові елементи процесів і потоків
До елеметів процесу належать:
· захищений адресний простір;
· дані, спільні для всього процесу (ці дані можуть спільно використовувати всі його потоки);
· інформація про використання ресурсів (відкриті файли, мережні з’єднання);
· інформація про потоки процесу;
Потік містить такі елементи:
· стан процесора (набір поточних даних із його регістрів), зокрема лічильник поточної інструкції процесора;
· стек потоку (ділянка пам’яті, де перебувають локальні змінні потоку й адреси повернення функцій, що викликані у його коді);
3.2 Стани процесів і потоків
Для потоку дозволені такі стани:
· створення (new) – потік перебуває у процесі створення;
· виконання (running) – інструкції потоку виконує процесор (у конкретний момент часу на одному процесорі тільки один потік може бути в такому стані);
· очікування (waiting) – потік очікує деякої події (наприклад, завершення операції введення-виведення); такий стан називають також заблокованим, а потік – припиненим;
· готовність (ready) – потік очікує, що планувальник перемкне процесор на нього, прицьому він має всі необхідні йому ресурси, крім процесорного часу;
· завершення (terminated) – потік завершив виконання (якщо прицьому його рсурси не були вилучені з системи, він переходить у додатковий стан – стан зомбі);
Можливі переходи між станаит потоку зображені на рис. 3.1.
 |
Рисунок 3.1 Стани потоку
Перехід потіків між станами очікування і готовності реалізовано на основі планування задач, або планування потоків. Під час планування потоків визначають, який з потків треба відновити після завершення операції введення-виведення, як організувати очікування у системі.
Для здійснення переходу між станами готовносі та виконання необхідне планування процесорного часу. На основі алгоритмів такогопланування визначають, яуий з готових потоків потрібно виконувати в конкретний момент, коли потрібно перервати виконання потоку, щоб перемкнутися на інший готовий потік тощо.
Відносно систем, які реалізують модель процесів, прийнято говорити про стан процесів, а не потоків, і про планування процесів; фактично стани процесу в цьому разі однозначно відповідають станам його єдиного потоку.
3.3 Опис процесів і потоків
Як ми вже знаємо, одним із основних завдань операційної системи є розподіл ресурсів між процесами і потоками. Такими ресурсами є насамперед процесорний час (його розподіляють між потоками під час планування), засобивведення-виведення й оперативна пам’ять (їх розподіляють між процесами).
Для керування розподілом ресурсів ОС повинна підтримувати структури даних, які містять інформацію, що описує процеси, потоки і ресурси. До таких структур даних належать:
· таблиці розподілу ресурсів: таблиці пам’яті, таблиці введення-виведення , таблиці файлів тощо;
· таблиці процесів і таблиці потоків, де міститься інформація про процеси і потоки, присутні у системів конкретний момент.
3.3.1 Керуючи блоки процесів і потоків
Інформацію про процеси і потки в системі зберігають у спеціальних структурах даних, які називають керуючими блоками процесів і керуючими блоками потоків. Ці структури дуже важливі для роботи ОС, оскількі на підставі їхньої інформації система здійснює керування процесами і потоками.
Керуючий блок потоку (Thread control Block, TCB) відповідає активному потоку, тобто тому, який перебуває у стані готовності, очікування або виконання.
Цій блок може міститу таку інформацію:
· ідентифікаційні дані потоку (зазвичай його унікальний ідентифікатор);
· стан процесору потоку: користувацьки регістри процесора, лічильник інструкцій, покажчик на стек;
· інформацію для планування потоків.
Таблиця потоків – це зв’язний список або масив керуючих блоків потоку. Вона розташована в захищеній області пам’яті ОС.
Керуючий блок процесу (Process Control Block, PCB) відповідає процесу, що присутній у системі. Такий блок може містити:
· ідентифікаційні дані процесу (унікальний ідентифікатор, інформацію про інші процеси, пов’язані з аданим);
· інформаію про потоки, які виконуються в адресному просторі процесу (наприклад, покажчики на їхні керуючи блоки);
· інформацію, на основі якої можна визначити права процесу на використання різних ресурсів (наприклад, ідентифікатор користувача, який створив процес);
· інформацію з розподілу адресного просору процесу);
· інформацію про ресурси введення-виведення та файли, які використовує процес.
3.3.2 Образи процесу і потоку
Сукупність інформації, що відображує процес у пам’яті, називають образом процесу (process image), а всю інформацію про потік – образом потоку (thread image). До образу процесу належать:
· керуючий блок процесу;
· програмний код користувача;
· дані користувача (глобальні дані програми, загальні для всіх потоків);
· інформація образів потоків процесу.
Програмний код користувача, дані користувача та інформація про потоки завантажуються в адресний простір процесу. Образ процесу звичайно не є безперервною ділянкою пам’яті, його частини можуть вивантажуватись на диск.
До образу потоку належать:
· керуючий блок потоку;
· стек ядра (стек потоку, який використовується під час виконання коду потоку в режимі ядра);
· стек користувача (стек потоку, доступний у користивацькому ражимі).
Схема розташування в пам’яті образів процесу і його потоків зображена на рисунку 3.2. Усі потоки конкретного процесу можуть користуватися загальною інформацією його образу.
3.4 Створення і завершення процесів і потоків
Засоби створення і завершення процесів дають змогу динамічно змінювати в операційній системі набір застосувань, що виконуються. Засоби створення і завершення потоків є основою для створення багатопотокових програм.
Образ процесу
 |
Адресний простір
Рис.3 2 Образи процесу і його потоків
3.4.1 Створення процесів
Базові принципи створення процесів
Процеси можуть створюватись ядром системи під час її ініціалізацїї. Наприклад, в UNIX-сумісних системахтаким процесом може бути процес ініціалізації системи init, у Windows XP – процеси підсистем середовища (Win32 або POSIX). Таке створення процесі, однак, є винятком, а не правилом.
Найчастіше процеси створюються під час виконання інших процесів.У цьому разі процес, який створює інший процес, називають предком, а створений ним процес – нащадком.
Нові процеси можуть бути створені під час роботи застосування відповідно до його логіки (компілятор може створювати прцеси для кожного етапу компіляцїї, веб-сервер – для обробки прибулих запитів) або
безпосередньо за запитом користувача (наприклад, з командного інтерпретатора, графічної оболонки або файлового менеджера).
Інтерактивні та фонові процеси
Розрізняють два типи фонових процесів з погляду їхньої взаємодії з користувачем.
· Інтерактивні процеси взаємодіють із користувачами безпосередньо, приймаючи від них дані, введені за допомогою клавіатури, миші тощо. Прикладом інтерактивного процесу може бути процес текстового редактора або інтегрованого середовища розробки.
· Фонові процеси із користувачем не взаємодіють безпосередньо. Зазвичай вони запускаються під час старту системи і чекають на запити від інших застосувань. Деякі з них (системні процеси) підтримують функціонування системи (реалізують фонове друкування, мережні засоби тощо), інші виклнують спеціалізовані задачі (реалізують веб-сервери, сервери баз даних тощо).фонові процеси також називають службами (services, у системах лінії windows XP) або демонами (daemons, в UNIX).
3.4.2 Керування адресним простором під час створення процесів
Оскільки основним елементом процесу є захищений адресний простір, дуже важливо вирішити проблему його розподілу під час створення нового процесу. Розглянемо два різні підходи.
Системні виклики fork() exec()
У першому підході адресний простір нащадка створюють як точну копію адресного простору предка. Така операція реалізована системним викликом, який у POSIX-системах називають fork().
У цьому разі копіюється не тільки адресний простір, а й лічильник команд головного потоку процесу, тому після виклику fork() предок і нащадок виконуватимуть ту саму інструкцію. Розробник має визначити, у
якому з двох процесів перебуває керування. Це можна зробити на підставі відмінностей між кодами повернення fork() для предка і нащадка.
Коли створення нового процесу відбувається шляхом дублювання адресного простору предка, виникає потреба у спеціальних засобах завантаження програмного коду в адресний простір процесу. Такі засоби реалізує системний виклик, який у POSIX-системах називають exec(). Як параметр для виклику exec() треба вказувати весь шлях до виконуваного файла програми, який буде завантажено у пам’ять.
У системах із підтримкою fork() для того щоб запускати на виконання програми, після виклику fork() потрібно негайно викликати exec() (це називають технологією fork+exec).
Запуск застосування одним системним викликом
Другий підхід не розділяє дублювання адресного простору і завантаження коду – ці етапи тут поєднані в один. У даному разі системний виклик запускає на виконання задане застосування (зазвичай для цього йому потрібно вказати весь шлях до виконуваного файла цього застосування). Можна виділити два етапи виконання такого системного виклику:
· виділення пам’яті під адресний простір нового процесу (жодна інформація при цьому з адресного простору предка не копіюється).
· Завантаження виконуваного коду із зазначеного файла у виділений адресний простір.
Підхід із використанням fork() і exec() є гнучкішим, бо він дає змогу в разі необхідності обмежитись якимось одним етапом запуску застосування. Сучасні ОС переважно реалізують комбінацію першого та другого підходів.
3.4.3 Особливості завершення процесів
Розглянемо три варіанти завершення процесів.
Процес коректно завершується самостійно після виконання своєї задачі (для інтерактивних процесів це нерідко відбувається з ініціативи користувача, який, приміром, скористався відповідним пунктом меню). Для цього код процесу має виконати системний виклик завершення процесу. Такий виклик у POSIX-системах називають _exit(). Він може повернути процесу, що його викликав, або ОС код повернення, який дає змогу оцінити результат виконання процесу.
Процес аврійно завершується через помилку. Такий вихід може бути передбачений програмістом (під час обробки помилки приймається рішення про те, що далі продовжувативиконання програми неможливо), а може бути наслідком генерування переривання (ділення на нуль, доступу до захищеної області пам’яті тощо).
Процес завершується іншим процесом або ядром системи. Наприклад, перед закінчення работи ОС ядро припиняє виконання всіх процесів. Процес може припинити виконання іншого процесу за допомогою системного виклику, який у POSIX-системах називають kill().
Після того як процес завершить свою роботу, пам’ять, відведена під його адресний простір, звільняється і може бути використана для інших потреб. Усі потоки цього процесу теж припиняють свою роботу. Якщо у даного процесу є нащадки, їхня робота переважно не припиняється слідом за роботою предка. Інтерактивні процеси звичайно завершуються у разі виходу користувача із системи.
3.4.4 Синхронне й асинхронне виконання процесів
Коли у системі з’являється новий процес,для старого процесу є два основних варіанти дій:
· продовжити виконання паралельно з новим процесом – такий режим роботи називаютьасинхронним виконанням;
· призупинити виконання доти, поки новий процес не буде завершений, - такий режим роботи називають синхронним виконанням. (У цьому разі використовують спеціальний системний виклик, який у POSIX-системах називають wait().
Вибір того чи іншого режиму залежить від конкретної задачі. Так, наприклад, веб-сервер може створювати процеси-нащадки для обробки запитів (якщо наявно набору нащадків недостатньо для такої обробки). У цьому разі обробка має бути асинхронною, бо відразу після створення нащадкуа предок має бути готовий до отримання наступного запиту. З іншого боку, компілятор С під час запуску процесів, що відповідають етапам компіляції, має чекати завершення кожного етапу, перш ніж перейти до наступного, - у такому разі використовують синхронну обробку.
3.4.5 Створення і завершення потоків
Особливості створення потоків
Процедура створення потоків має свої особливості, пов’язані насамперед із тим, що потоки створюють у рамках вже існуючого адресного простору (конкретного процесу або, можливо, ядра системи).Існує кілька ситуацій, у яких може бути створений новий потік.
Якщо процес створюється за допомогою ссистемного виклику fork(), після розподілу адресного простору автоматично створюється потік усередині цього процесу (найчастіще це – головний потік застосування).
Можна створити потоки з коду користувача за допомогою відповідного системного виклику.
У багатьох ОС є спеціальні потоки, які створює ядро системи (код ядра теж може виконуватися в потоках). Під час створення потоку система повинна виконати такі дії.
1. Створити структури даних, які відображають потік в ОС.
2. Виділити пам’ять під стек потоку.
3. Встановити лічильник команд процесора на початок коду, який буде виконуватися в потці; цей код називають процедурою або функцією потоку, покажчик нга таку процедуру передають у системний виклик створення потоку.
Слід відзначити, що під час створення потоків, на відміну від створення процесів немає необхідності виділяти нову пам’ять під адресний простір, тому зазвичай потоки створюються швидше і з меншими затратами ресурсів.
Особливості завершення потоків
Під час завершення потоків його ресурси вивільняються (насамперед, тек); ця операція звичайно виконується швидше, ніж завершення процесу. Потік може бути завершений, коли керування дійде до кінця процедури потоку; єтакож спеціальні системні виклики, призначені для дострокового припинення виконання потоків.
Як і процеси, потоки можуть виконуватися синхронно й асинхронно. Потік, створивший інший потік, може призупинити своє виконання до його завершення. Таке очікування називають приєднанням потоків (thread joining, очікує той, хто приєднує). Після завершення приєднаного потоку потік, який очікував його завершення, може дістати статус виконання. Під час створення потоку можна визначіти, чи підлягає він приєднанню (якщо потік не можна приєднати, його називають від’єднаним – detached). Якщо потік не є від’єднаним (nondetached або joinable, такий потік називатимемо приєднуваним), після завершення його обов’язково потрібно приєднувати, щоб унікнути витікання пам’яті.
3. 5 Керування процесами в UNIX і Linux
Образ процесу
В UNIX-системах образ процесу містить такі компоненти:
· керуючий блок процесу;
· код програми, яку виконує процес;
· стек процесу, де зберігаються тимчасові дані (параметри процедур, повернені значення, локальні змінні тощо);
· глобальні дані, спільні для всього процесу.
Для кожного компоненту образу процесу виділяють окурему ділянку пам’яті.
3. 5. 2 Ідентифікаційна інформація та атрибути безпеки процесу
Із кожним процесом у системі пов’язана ідентифікаційна інформація.
Ідентифікатор процесу (pid) є унікальним у межах усієї системи, і його використовують для доступу до цього процесу. Ідентифікатор процесу init завжди дорівнює одиниці.
Ідентифікатор процесу-предка (ppid) задають під час його створення. Будьякий процес має мати доступ до цього ідентифікатора. Так в UNIX-системах обов’язково підтримується зв’язок “предок-нащадок”. Якщо предок процесу P завершує виконання, предком цього процесу автоматично стає init, тому ppid для P дорівнюватиме одиниці.
Із процесом також пов’язаний набір атрибутів безпеки.
· Реальні ідентифікатори користувача і групи процесу (uid, gid) відповідають користувачеві, що запустив програму, в наслідок чого в системі з’явивися відповідний процес.
· Ефективні ідентифікатори користувача і групи процесу (euid, egid) використовують у спеціальному режимі виконання процесу – виконані з правами власника.
Керуючий блок процесу
Розглянемо структуру керуючого блоку процесу в Linux.
Керуючий блок процесу в Linux відображається структурою даних task_struct. До найважливіших полів цієї структури належать поля, що містять таку інформацію:
· ідентифікаційні дані (зокрема pid – ідентифікатор процесу);
· стан процесу (виконання, очікування тощо);
· покажчики на структури предка і нащадків;
· час створення процесу та загальний час виконання (так звані таймери процесу);
· стан процесора (вміст регистрів і лічильник інструкцій);
· атрибути безпеки процесу (id, gid,euid, egid).
Зазначимо, що в ядрі Linux відсутня окрема структура даних для потоку, тому інформація про стан процесора міститься в керуючому блоці процесу.
Крім перелічених вище, task_struct має кілька полів спеціалізованого призначення, необхідних для різних підсистем Linux:
· відомості для обробки сигналів;
· інформація для планування процесів;
· інформація про файли і каталоги, пов’язані з процесом;
· структури даних для підсистеми керування пам’яттю.
Дані полів task_struct можуть спільно використовувати декілька процесів спеціалізованого призначення, у цьому випадку такі процеси фактично є потоками.
Керуючі блоки процесу зберігаються в ядрі у спеціальній структурі даних. До появи версії ядра 2.4 таку структуру називали таблицею процесів системи; це був масив,максимальна довжина якого не могла перевищувати 4 Кбайт. У ядрі версії 2.4 таблиця процесів була замінена двома динамічними структурами даних, що не мають такого обмеження на довжину:
· хеш-таблицею (де в ролі хеша виступає pid процесу), ця структура дає змогу швидко знаходити процес за його ідентифікатором;
· кільцевим двозв’язним списком, ця структура забезпечує виконання дій у циклі для всіх процесів системи.
Тепер обмеження на максимальну кількість процесів перевіряється тільки всередині реалізації функції fork() і залежить від обсягу доступної пам’яті (наприклад, є відомості, що у системі з 512 Мбайт пам’яті можна створити близько 32000 процесів).
Реалізація керуючого блоку в Linux відрізняється від його традиційної реалізації в UNIX-системах. У більшості версій UNIX (System V, BSD) керуючий блок процесу складається з двох струтур даних – струтури процесу (proc) і структури користувача (u).
Створення процесу
Реалізація fork() в Linux
В UNIX-сумісних системах процеси створює вже відомий нам системний виклик fork(). Розглянемо його реалізацію в Linux.
1. Виділяють пам’ять для нового керуючого блоку процесу (task_struct). Якщо пам’яті недостатньо, повертається помилка.
2. Усі значення зі структури даних предка копіюють у структуру даних нащадка. Після цього поля, значення яких мають відрізнятися від вихідних, будуть змінені.
Якщо користувач перевищить заданий для нього ліміт кількості процесів або якщо кількість процесів у системі перевищить максимально можливе значення (яке залежить від обсягу доступної пам’яті), створення процесу припиняється і повертається помилка.
3. Для процесу генерується ідентифікатор (pid), прицьому використовують спеціальний алгоритм, що гарантує унікальність.
4. Для нащадка копіюють необхідні додаткові структури даних предка (таблицю дескрипторів файлів, відомості про поточний каталог, таблицю оброблювачів сигналів тощо).
5. Формують адресний простір процесу.
6. Структуру даних процесу поміщають у список і хеш-таблицю процесів системи.
7. Процес переводять у стан готовності до виконання.