Застосування користувача

Застосування користувача можуть бути створені для різних підсистем середовища. Такі застосування використовують тільки функції відповідного API. Виклики цих функцій перетворюються в системні виклики за допомогою динамічних бібліотек підсистем середовища.

2.5.3. Об’єктна архітектура Windows XP

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

· Імена об’єктів організовані в єдиний простір імен, де їх легко знаходити.

· Доступ до всіх об’єктів здійснюється однаково. Після створення нового об’єкта або після отримання доступу до наявного менеджер об’єктів повертає у застосування дескриптор об’єкта (object handle).

· Забезпечено захист ресурсів. Кожну спробу доступу до об’єкта розглядає підсистема захисту – без неї доступ до об’єкта, а отже і до ресурсу, отримати неможливо.

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

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

Особливості отримання доступу до об’єктів із процесів режиму користувача буде розглянуто в розділі 3.

Структура заголовка об’єкта

Об’єкти складаються з двох частин: заголовка і тіла об’єкта. У заголовку міститься інформація, загальна для всіх об’єктів, у тілі – специфічна для об’єктів конкретного типу.

До атрибутів заголовка об’єкта належать:

· ім’я об’єкта і його місце у просторі імен;

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

· витрата квоти (ціна відкриття дескриптора об’єкта, дає змогу регулювати кількість об’єктів, які дозволено створювати);

· список процесів, що дістали доступ до дескрипторів об’єкта.

Менеджер об’єктів здійснює керування об’єктами на підставі інформації з їхніх заголовків.

Об’єкти типу

Формат і вміст тіла об’єкта визначається його типом. Новий тип об’єктів може бути визначений будь-яким компонентом ВС. Існує визначений набір типів об’єктів, які створюються під час завантаження системи (такі об’єкти, наприклад, відповідають процесам, відкритим файлам, пристроям введення-виведення).

Частина характеристик об’єктів є загальними для всіх об’єктів цього типу. Для зберігання відомостей про такі характеристики використовують спеціальні об’єкти типу (type objects). У такому об’єкті, зокрема, зберігають:

· ім’я типу об’єкта («процес», «потік», «відкритий файл» тощо);

· режими доступу (залежать від типу об’єкта: наприклад, для файла такими режимами можуть бути «читання» і «запис»).

Об’єкти типу недоступні в режимі користувача.

Методи об’єктів

Коли компонент ВС створює новий тип об’єкта, він може зареєструвати у диспетчері об’єктів один або кілька методів. Після цього диспетчер об’єктів викликає ці методи на певних етапах життєвого циклу об’єкта. Наведемо деякі з методів об’єктів:

· open – викликається при відкритті дескриптора об’єкта;

· close – викликається при закритті дескриптора об’єкта;

· delete - викликається перед вилученням об’єкта з пам’яті.

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

Простір імен об’єктів

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

· Device – імена пристроїв в ведення-виведення;

· Driver – завантажені драйвери пристроїв;

· ObjectTypes – об’єкти типів.

Простір імен об’єктів, як і окремі об’єкти, не зберігається після перезавантаження системи.

Висновки

· Архітектура ОС визначає набір її компонентів, а також порядок їхньої взаємодії один з одним та із зовнішнім середовищем.

· Найважливішим для вивчення архітектури ОС є поняття ядра системи. Основною характеристикою ядра є те, що воно виконується у привілейованому режимі.

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

· Операційна система безпосередньо взаємодіє з апаратним забезпеченням комп’ютера. Сучасні комп’ютерні архітектури пропонують багато засобів підтримки роботи операційних систем. Для зв’язку з апаратним забезпеченням в ОС виділяється рівень абстрагування від устаткування.

· Операційна система взаємодіє із прикладними програмами. Вона надає набір системних викликів для доступу до функцій, реалізованих у ядрі. Для прикладних програм системні виклики разом із засобами системних бібліотек доступні через інтерфейс програмування застосувань (АРІ).

Контрольні запитання та завдання

1. Перелічіть причини, за якими ядро ОС має виконуватися в привілейованому режимі процесора.

2. Чи може процесор переходити у привілейований режим під час виконання програми користувача? Чи може така програма виконуватися виключно в привілейованому режимі?

3. У чому полягає головний недолік традиційної багаторівневої архітектури? Чи має такий недолік архітектура з виділенням рівнів у монолітному ядрі.

4. Чому перехід до використання мікроядрової архітектури може спричинити зниження продуктивності ОС?

5. Автор Linux Лінус Торвальдс стверджує, що мобільність Linux має поширюватися на системи з «прийнятною» (reasonable) архітектурою. Які апаратні засоби повинна підтримувати така архітектура?

6. Наведіть переваги і недоліки реалізації взаємодії прикладної програми з операційною системою в Linux і Windows XP.

7. Чи не суперечить використання модулів ядра принципам монолітної архітектури Linux? Поясніть свою відповідь.

8. Перелічіть переваги і недоліки архітектури ОС, відповідно до якої віконна і графічна підсистеми в Windows XP виконуються в режимі ядра.

9. Чому деякі діагностичні утиліти Windows XP складаються з прикладної програми і драйвера пристрою?

Розділ З

Керування процесами і потоками

· Означення процесу та потоку

· Реалізація та використання моделі процесів і багатопотоковості

· Подання процесів і потоків в операційній системі

· Створення та завершення процесів і потоків

· Керування процесами та потоками в UNIX

· Керування процесами та потоками у Windows ХР

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

У викладі орієнтуватимемося на сучасні ОС, для яких потоки є фундаментальними абстракціями системи нарівні з процесами.

3.1. Базові поняття процесів і потоків 3.1.1. Процеси і потоки в сучасних ОС

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

Дамо попереднє означення процесу.

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

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

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

Для успішного виконання програми потрібні певні ресурси. До них належать:

· ресурси, необхідні для послідовного виконання програмного коду (передусім процесорний час);

· ресурси, що дають можливість зберігати інформацію, яка забезпечує виконан­ня програмного коду (регістри процесора, оперативна пам'ять тощо).

Ці групи ресурсів визначають дві складові частини процесу:

· послідовність виконуваних команд процесора;

· набір адрес пам'яті (адресний простір), у якому розташовані ці команди і дані для них.

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

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

Тепер можна дати ще одне означення процесу.

Процесом називають сукупність одного або декількох потоків і захищеного адресного простору, у якому ці потоки виконуються.

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

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

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

Адресний простір процесу не завжди відповідає адресам оперативної пам'яті. Наприклад, у нього можуть відображатися файли або регістри контролерів введення-виведення, тому запис за певною адресою в цьому просторі призведе до запису у файл або до виконання операції введення-виведення. Таку технологію називають відображенням у пам'ять (memory mapping).

3.2. Багатопотоковість та її реалізація

3.2.1. Поняття паралелізму

Використання декількох потоків у застосуванні означає внесення в нього паралелізму (concurrency). Паралелізм – це одночасне (з погляду прикладного програміста) виконання дій різними фрагментами коду застосування. Така одночасність може бути реалізована на одному процесорі шляхом перемикання задач (випадок псевдопаралелізму), а може ґрунтуватися на паралельному виконанні коду на декількох процесорах (випадок справжнього паралелізму). Потоки абстрагують цю відмінність, даючи можливість розробляти застосування, які в однопроцесорних системах використовують псевдопаралелізм, а при доданні процесорів – справжній паралелізм (такі застосування масштабуються зі збільшенням кількості процесорів).

3.2.2. Види паралелізму

Можна виділити такі основні види паралелізму.

· паралелізм багатопроцесорних систем;

· паралелізм операцій введення-виведення;

· паралелізм взаємодії з користувачем;

· паралелізм розподілених систем.

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

Паралелізм операцій введення-виведення

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

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

Паралелізм взаємодії з користувачем

Під час інтерактивного сеансу роботи користувач може виконувати різні дії із застосуванням (і очікувати негайної реакції на них) до завершення обробки попередніх дій. Наприклад, після запуску команди «друкування документа» він може негайно продовжити введення тексту, не чекаючи завершення друкування.

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

Паралелізм розподілених застосувань

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

3.2.3. Переваги і недоліки багатопотоковості

Назвемо проблеми, які можуть бути вирішені за допомогою потоків.

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

· Для підтримки потоків потрібно менше ресурсів, ніж для підтримки процесів (наприклад, немає необхідності виділяти для потоків адресний простір).

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

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

· Розробляти і налагоджувати багатопотокові програми складніше, ніж звичайні послідовні програми; досить часто впровадження багатопотоковості призводить до зниження надійності застосувань. Організація спільного використан­ня адресного простору декількома потоками вимагає, щоб програміст мав ви­соку кваліфікацію.

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

Переваги і недоліки використання потоків потрібно враховувати під час виконання будь-якого програмного проекту. Насамперед доцільно розглядати можливість розв'язати задачу в рамках моделі процесів. При цьому, однак, варто брати до уваги не лише поточні вимоги замовника, але й необхідність розвитку застосування, його масштабування тощо. Можливо, з урахуванням цих факторів використання потоків буде виправдане.

3.2.4. Способи реалізації моделі потоків

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

Потік користувача – це послідовність виконання команд в адресному просторі процесу. Ядро ОС не має інформації про такі потоки, вся робота з ними виконується в режимі користувача. Засоби підтримки потоків користувача надають спеціальні системні бібліотеки; вони доступні для прикладних програмістів у вигляді бібліотечних функцій. Бібліотеки підтримки потоків у наш час звичайно реалізують набір функцій, визначений стандартом РОSІХ (відповідний розділ стандарту називають РОSІХ.1b); тут прийнято говорити про підтримку потоків РОSІХ.

Потік ядра – це послідовність виконання команд в адресному просторі ядра. Потоками ядра управляє ОС, перемикання ними можливе тільки у привілейова­ному режимі. Є потоки ядра, які відповідають потокам користувача, і потоки, що не мають такої відповідності.

Співвідношення між двома видами потоків визначає реалізацію моделі потоків. Є кілька варіантів такої реалізації (схем багатопотоковості); розглянемо найважливіші з них (рис. 3.1).

Рис. 3.1. Способи реалізації моделі потоків

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

· Схема М:1 не дає змоги скористатися багатопроцесорними архітектурами, оскільки визначити, який саме код виконуватиметься на кожному із процесорів, може тільки ядро ОС. У результаті всі потоки одного процесу завжди виконуватимуться на одному процесорі.

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

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

Схема багатопотоковості М:N. У цій схемі присутні як потоки ядра, так і потоки користувача, які відображаються на потоки ядра так, що один потік ядра може відповідати декільком потокам користувача. Число потоків ядра може бути змінене програмістом для досягнення максимальної продуктивності. Розподіл потоків користувача по потоках ядра виконується в режимі користувача, планування потоків ядра – у режимі ядра. Схема є складною в реалізації і сьогодні здає свої позиції схемі 1:1.

3.3. Стани процесів і потоків

Для потоку дозволені такі стани:

· створення (new) – потік перебуває у процесі створення;

· виконання (running) – інструкції потоку виконує процесор (у конкретний момент часу на одному процесорі тільки один потік може бути в такому стані);

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

· готовність (ready) – потік очікує, що планувальник перемкне процесор на нього, при цьому він має всі необхідні йому ресурси, крім процесорного часу;

· завершення (terminated) – потік завершив виконання (якщо при цьому його ресурси не були вилучені з системи, він переходить у додатковий стан – стан зомбі).

Можливі переходи між станами потоку зображені на рис. 3.2.

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

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

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

У багатопотокових системах також можна виділяти стани процесів. Наприклад, у багатопотоковості, реалізованій за схемою М:1, потоки змінюють свої стани в режимі користувача, а процеси – у режимі ядра.

3.4. Опис процесів і потоків

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

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

· таблиці розподілу ресурсів: таблиці пам'яті, таблиці введення-виведення, таблиці файлів тощо;

· таблиці процесів і таблиці потоків, де міститься інформація про процеси і потоки, присутні у системі в конкретний момент.

3.4.1. Керуючі блоки процесів і потоків

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

Керуючий блок потоку (Thread Control Вlоск, ТСВ) відповідає активному потоку, тобто тому, який перебуває у стані готовності, очікування або виконання. Цей блок може містити таку інформацію:

· ідентифікаційні дані потоку (зазвичай його унікальний ідентифікатор);

· стан процесора потоку: користувацькі регістри процесора, лічильник інструкцій, покажчик на стек;

· інформацію для планування потоків.

Таблиця потоків – це зв'язний список або масив керуючих блоків потоку. Вона розташована в захищеній області пам'яті ОС.

Керуючий блок процесу (Process Control Вlоск, РСВ) відповідає процесу, що присутній у системі. Такий блок може містити:

· ідентифікаційні дані процесу (унікальний ідентифікатор, інформацію про інші процеси, пов'язані з даним);

· інформацію про потоки, які виконуються в адресному просторі процесу (наприклад, покажчики на їхні керуючі блоки);

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

· інформацію з розподілу адресного простору процесу;

· інформацію про ресурси введення-виведення та файли, які використовує процес.

Зазначимо, що для систем, у яких реалізована модель процесів, у керуючому блоці процесу зберігають не посилання на керуючі блоки його потоків, а інформацію, необхідну безпосередньо для його виконання (лічильник інструкцій, дані для планування тощо).

Таблицю процесів організовують аналогічно до таблиці потоків. Як елементи в ній зберігатимуться керуючі блоки процесів.

3.4.2. Образи процесу і потоку

Сукупність інформації, що відображає процес у пам'яті, називають образом процесу (process image), а всю інформацію про потік – образом потоку (thread image). До образу процесу належать:

· керуючий блок процесу;

· програмний код користувача;

· дані користувача (глобальні дані програми, загальні для всіх потоків);

· інформація образів потоків процесу.

Програмний код користувача, дані користувача та інформація про потоки завантажуються в адресний простір процесу. Образ процесу звичайно не є безперервною ділянкою пам'яті, його частини можуть вивантажуватися на диск. Ці питання будуть розглянуті в розділі 9.

До образу потоку належать:

· керуючий блок потоку;

· стек ядра (стек потоку, який використовується під час виконання коду потоку в режимі ядра);

· стек користувача (стек потоку, доступний у користувацькому режимі).

Схема розташування в пам’яті образів процесу і його потоків зображена на рис. 3.3. Усі потоки конкретного процесу можуть користуватися загальною інформацією його образу.

Рис. 3.3. Образи процесу і його потоків

Дата добавления: 2014-01-05