Призначення ядра Linux і його особливості

Призначення ядра Linux і його особливості

Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра пе­ребувають в одному адресному просторі. У ядрі можна виділити кілька функціо­нальних компонентів [63].

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

§ Менеджер пам'яті - виділяє окремий адресний простір для кожного процесу і реалізує підтримку віртуальної пам'яті.

§ Віртуальна файлова система - надає універсальний інтерфейс взаємодії з різ­ними файловими системами та пристроями введення-виведення.

§ Драйвери пристроїв - забезпечують безпосередню роботу з периферійними пристроями. Доступ до них здійснюється через інтерфейс віртуальної фай­лової системи.

§ Мережний інтерфейс - забезпечує доступ до реалізації мережних протоколів і драйверів мережних пристроїв.

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

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

Модулі ядра

Ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) і виконують у привілейованому режимі. Модулі ядра надають низку переваг.

§ Код модулів може завантажуватися в пам'ять у процесі роботи системи, що спрощує налагодження компонентів ядра, насамперед драйверів.

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

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

§ Підтримка модулів у Linux складається із трьох компонентів.

§ Засоби керування модулями дають можливість завантажувати модулі у па­м'ять і здійснювати обмін даними між модулями та іншою частиною ядра.

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

§ Засоби розв'язання конфліктів дають змогу драйверам пристроїв резервува­ти апаратні ресурси і захищати їх від випадкового використання іншими драйверами.

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

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

Особливості системних бібліотек

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

§ реалізацію пакувальників системних викликів;

§ розширення функціональності системних викликів (до таких бібліотек нале­жить бібліотека введення-виведення мови С, яка реалізує на основі системних викликів такі функції, як prlntf ());

§ реалізацію службових функцій режиму користувача (сортування, функції об­робки рядків тощо).

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

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

 

 

Лекція №4.

 

Тема: особливості архітектури: Windows XP.

 

План:

1.Компоненти режиму ядра Windows XP: (Л1. ст.38-40).

рівень абстрагування від устаткування, ядро, виконавча система, драйвери пристроїв,

віконна і графічна підсистеми

2.Компоненти режиму користувача: (Л1. ст.40-42).

бібліотека системного інтерфейсу, підсистеми середовища,наперед визначені

системні процеси, застосування користувача.

3.Об`єктна архітектура Windows XP: (Л1. ст.42-43).

структура заголовка об`акта, об`єкти типу, методи об`єктів, простір імен об`єктів.

 

1.

Деякі компоненти Windows ХР виконуються у привілейованому режимі, інші компоненти - у режимі користувача.

У традиційному розумінні ядро ОС складають усі компоненти привілейованого режиму, однак у Windows ХР поняття ядра закріплене тільки за одним із цих компонентів.

 

Рівень абстрагування від устаткування

У Windows ХР реалізовано рівень абстрагування від устаткування (у цій системі його називають HAL, hardware abstraction layer). Для різних апаратних конфігурацій фірма Microsoft або сторонні розробники можуть постачати різні реалізації HAL.

Хоча код HAL є дуже ефективним, його використання може знижувати про­дуктивність застосувань мультимедіа. У такому разі використовують спеціаль­ний пакет DirectX, який дає змогу прикладним програмам звертатися безпосе­редньо до апаратного забезпечення, обминаючи HAL та інші рівні системи.

Ядро

Ядро Windows ХР відповідає за базові операції системи. До його основних функ­цій належать:

§ перемикання контексту, збереження і відновлення стану потоків;

§ планування виконання потоків;

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

Ядро Windows ХР відповідає базовим службам ОС і надає набір механізмів для реалізації політики керування ресурсами.

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

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

Виконавча система

Виконавча система (ВС) Windows ХР (Windows ХР Executive) - це набір ком­понентів, відповідальних за найважливіші служби ОС (керування пам'яттю, про­цесами і потоками, введенням-виведенням тощо).

Компонентами ВС є передусім базові засоби підтримки. Ці засоби використо­вують у всій системі.

♦ Менеджер об'єктів — відповідає за розподіл ресурсів у системі, підтримуючи їхнє універсальне подання через об'єкти.

♦ Засіб локального виклику процедур (LPC) — забезпечує механізм зв'язку між процесами і підсистемами на одному комп'ютері.

Інші компоненти ВС реалізують найважливіші служби Windows ХР. Зупини­мося на деяких із них.

♦ Менеджер процесів і потоків — створює та завершує процеси і потоки, а також розподіляє для них ресурси.

♦ Менеджер віртуальної пам'яті — реалізує керування пам'яттю в системі, на­самперед підтримку віртуальної пам'яті.

♦ Менеджер введення-виведення — керує периферійними пристроями, надаючи іншим компонентам апаратно-незалежні засоби введення-виведення. Цей ме­неджер реалізує єдиний інтерфейс для драйверів пристроїв.

♦ Менеджер кеша— керує кешуванням для системи введення-виведення. Часто використовувані блоки диска тимчасово зберігаються в пам'яті, наступні опе­рації введення-виведення звертаються до цієї пам'яті, внаслідок чого підви­щується продуктивність.

♦ Менеджер конфігурації- відповідає за підтримку роботи із системним реєст­ром(registry) - ієрархічно організованим сховищем інформації про налашту­вання системи і прикладних програм.

♦ Довідковий монітор захисту- забезпечує політику безпеки на ізольованому комп'ютері, тобто захищає системні ресурси.

Драйвери пристроїв

У WindowsХР драйвери не обов'язково пов'язані з апаратними пристроями. За­стосування, якому потрібні засоби, доступні в режимі ядра, завжди варто оформ­ляти як драйвер. Це пов'язане з тим, що для зовнішніх розробників режим ядра доступний тільки з коду драйверів.

Віконна і графічна підсистеми

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

§ Менеджер вікон - реалізує високорівневі функції. Він керує віконним виве­денням, обробляє введення з клавіатури або миші й передає застосуванням повідомлення користувача.

§ Інтерфейс графічних пристроїв (Graphical Device Interface, GDI) — склада­ється з набору базових операцій графічного виведення, які не залежать від конкретного пристрою (креслення ліній, відображення тексту тощо).

§ Драйвери графічних пристроїв (відеокарт, принтерів тощо) — відповідають за взаємодію з контролерами цих пристроїв.

Під час створення вікон або елементів керування запит надходить до мене­джера вікон, який для виконання базових графічних операцій звертається до GDI. Потім запит передається драйверу пристрою, затим - апаратному забезпеченню через НАL.

 

2.

 

Компоненти режиму користувача не мають прямого доступу до апаратного забез­печення, їхній код виконується в ізольованому адресному просторі. Більша части­на коду режиму користувача перебуває в динамічних бібліотеках, які у Windows називають DLL (dynamic –link libraies).

Бібліотека системного інтерфейсу

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

 

Підсистеми середовища

Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, реалізуючи відповідний АРІ. Ми зупинимося на двох під­системах середовища: Win32 і POSIX.

 

Підсистема Win32, яка реалізує Win32 АРІ, є обов'язковим компонентом Windows ХР. До неї входять такі компоненти:

♦ процес підсистеми Win32 (csrss.ехе), що відповідає, зокрема, за реалізацію текстового (консольного) введення-виведення, створення і знищення проце­сів та потоків;

♦ бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32 АРІ. Найчастіше використовують бібліотеки gdi32.dll (низькорівневі графічні функції, незалежні від пристрою), user32.dll (функції інтерфейсу ко­ристувача) і kernel32.dll (функції, реалізовані у ВС і ядрі).

Після того як застосування звернеться до функції Win32 АРІ, спочатку буде викликана відповідна функція з бібліотеки підсистеми Win32. Розглянемо ва­ріанти виконання такого виклику.

1. Якщо функції потрібні тільки ресурси її бібліотеки, виклик повністю вико­нується в адресному просторі застосування без переходу в режим ядра.

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

3. Функція бібліотеки підсистеми може звернутися до процесу підсистеми Win32, при цьому:

 

♦ коли потрібна тільки функціональність, реалізована даним процесом, пе­реходу в режим ядра не відбувається;

♦ коли потрібна функціональність режиму ядра, процес підсистеми Win32 виконує системний виклик аналогічно до варіанта 2.

Зазначимо, що до виходу Windows NT 4.0 (1996 рік) віконна і графічна під­системи працювали в режимі користувача як частина процесу підсистеми Win32 (тобто виклики базових графічних функцій Win32 АРІ оброблялися відповідно до варіанта 3). Надалі для підвищення продуктивності реалізацію цих підсистем було перенесено в режим ядра [14].

Підсистема POSIX працює в режимі користувача й реалізує набір функцій, ви­значених стандартом POSIX 1003.1. Оскільки застосування, або прикладні програ­ми (арріісатіопз), написані для однієї підсистеми, не можуть використати функції інших, у РОSІХ-програмах не можна користуватися засобами Win32 АРІ (зокре­ма, графічними та мережними функціями), що знижує важливість цієї підсистем-и. Підсистема РОSІХ не є обов'язковим компонентом Windows ХР.

Наперед визначені системні процеси

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

♦ Менеджер сесій (Sesion Manager, smss.exe) створюється в системі першим. Він запускає інші важливі процеси (процес підсистеми Win32, процес ре­єстрації в системі тощо), а також відповідає за їхнє повторне виконання під час аварійного завершення.

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

♦ Менеджер керування службами (Services Control Manager, services.exe) від­повідає за автоматичне виконання певних застосувань під час завантаження системи. Застосування, які будуть виконані при цьому, називають службами (services). Такі служби, як журнал подій, планувальник задач, менеджер дру­кування, постачають разом із системою. Крім того, є багато служб сторонніх розробників; так зазвичай реалізовують серверні застосування (сервери баз даних, веб-сервери тощо).

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

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

 

 

3.

 

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

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

§ доступ до всіх об'єктів здійснюється однаково. Після створення нового об'єкта або після отримання доступу до наявного менеджер об'єктів повертає у засто­сування дескриптор об'єкта (оЬіесt handle).

§ забезпечено захист ресурсів. Кожну спробу доступу до об'єкта розглядає під­система захисту - без неї доступ до об'єкта, а отже і до ресурсу, отримати не­можливо.

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

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

 

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

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

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

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

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

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

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

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

Об'єкти типу

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

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

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

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

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

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

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

§ орen - викликається при відкритті дескриптора об'єкта;

§ сlose - викликається при закритті дескриптора об'єкта;

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

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

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

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

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

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

♦ ObjectTypes- об'єкти типів.

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

 

 

Висновки до розділу 2.

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

Розділ3. Керування процесами і потоками та їх планування.

(аудиторних-6/5г., самостійних- 8/5г.)

 

Лекція №1.

 

Тема: базові поняття процесів і потоків.

 

План:

1.Процеси і потоки в сучасних ОС (Л1. ст.45-47).

2.Моделі процесів і потоків (Л1. ст.47).

3.Складові елементи процесів і потоків (Л1. ст.47).

4.Поняття паралелізму та його види (Л1. ст.48-49).

5.Переваги і недоліки багатопотоковості (Л1. ст49).

 

 

1.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

2.

 

Максимально можлива кількість процесів (захищених адресних просторів) і по­токів, які в них виконуються, може варіюватися в різних системах.

§ В однозадачних системах є тільки один адресний простір, у якому в кожен мо­мент часу може виконуватися один потік.

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

§ У системах, подібних до традиційних версій UNIX, допускається наявність багатьох процесів, але в рамках адресного простору процесу виконується тіль­ки один потік. Це традиційна однопотокова модель процесів. Поняття потоку в даній моделі не застосовують, а використовують терміни «перемикання між процесами», «планування виконання процесів», «послідовність команд про­цесу» тощо (тут під процесом розуміють його єдиний потік).

§ У більшості сучасних ОС (таких, як лінія Windows ХР, сучасні версії UNIX) може бути багато процесів, а в адресному просторі кожного процесу — багато потоків. Ці системи підтримують багатопотоковість або реалізують модель по­токів. Процес у такій системі називають багатопотоковим процесом.

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

 

3.

До елементів процесу належать:

§ захищений адресний простір;

§ дані, спільні для всього процесу (ці дані можуть спільно використовувати всі його потоки);

§ інформація про використання ресурсів (відкриті файли, мережні з'єднан­ня тощо);

§ інформація про потоки процесу. Потік містить такі елементи:

§ стан процесора (набір поточних даних із його регістрів), зокрема лічильник поточної інструкції процесора;

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

 

4.

 

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

 

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

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

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

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

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

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

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

Канали

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

Розрізняють безіменні та поіменовані канали.

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

До поіменованих каналів (named pipes) є доступ за іменем. Такому каналу мо­же відповідати, наприклад, файл у файловій системі, при цьому будь-який про­цес, який має доступ до цього файла, може обмінюватися даними через відповід­ний канал. Поіменовані канали реалізують непрямий обмін даними.

Обмін даними через канал може бути однобічним і двобічним.

Черги повідомлень

Іншою технологією асинхронного непрямого обміну даними є застосування черг повідомлень (message queues). Для таких черг виділяють спеціальне місце в системній ділянці пам'яті ОС, доступне для застосувань користувача. Процеси можуть створювати нові черги, відсилати повідомлення в конкретну чергу й от­римувати їх звідти. Із чергою одночасно може працювати кілька процесів. Пові­домлення — це структури даних змінної довжини. Для того щоб процеси могли розрізняти адресовані їм повідомлення, кожному з них присвоюють тип. Відісла­не повідомлення залишається в черзі доти, поки не буде зчитане. Синхронізація під час роботи з чергами схожа на синхронізацію для каналів.

 

 

2.

Найрозповсюдженішим методом обміну повідомленнями є використання сокетів (sockets). Ця технологія насамперед призначена для організації мережного обмі­ну даними, але може бути використана й для взаємодії між процесами на одному комп'ютері (власне, мережну взаємодію можна розуміти як узагальнення IPC).

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

Особливості протоколу передавання даних і формування адреси сокету ви­значає комунікаційний домен; його потрібно зазначати під час створення кожного сокету. Прикладами доменів можуть бути домен Інтернету (який задає протокол зв'язку на базі TCP/IP) і локальний домен або домен UNIX, що реалізує зв'язок із використанням імені файла (подібно до поіменованого каналу). Сокет можна ви­користовувати у поєднанні тільки з одним комунікаційним доменом. Адреса со­кету залежить від домену (наприклад, для сокетів домену UNIX такою адресою буде ім'я файла).

Способи передавання даних через сокет визначаються його типом. У конкрет­ному домені можуть підтримуватися або не підтримуватися різні типи сокетів.

Наприклад, і для домену Інтернет, і для домену UNIX підтримуються сокети та­ких типів:

♦ потокові (stream sockets) — задають надійний двобічний обмін даними суціль­ним потоком без виділення меж (операція читання даних повертає стільки да­них, скільки запитано або скільки було на цей момент передано);

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

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

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

Подальші дії відрізняються для сервера і клієнта. Для сервера виконуються такі дії:

1. Сокет пов'язують з адресою за допомогою системного виклику bind(). Для со­кетів домену UNIX як адресу задають ім'я файла, для сокетів домену Інтернету - необхідні характеристики мережного з'єднання. Далі клієнт для встанов­лення з'єднання й обміну повідомленнями має буде вказати цю адресу.

2.Сервер дає змогу клієнтам встановлювати з'єднання, виконавши системний виклик listen() для дескриптора сокету, створеного раніше.

3.Після виходу із системного виклику listen() сервер готовий приймати від клі­єнтів запити на з'єднання. Ці запити вишиковуються в чергу. Для отримання запиту із цієї черги і створення з'єднання використовують системний виклик accept(). Внаслідок його виконання в застосування повертають новий сокет для обміну даними із клієнтом. Старий сокет можна використовувати далі для приймання нових запитів на з'єднання. Якщо під час виклику accept() запити на з'єднання в черзі відсутні, сервер переходить у стан очікування.

Для клієнта послідовність дій після створення сокету зовсім інша. Замість трьох кроків досить виконати один - встановити з'єднання із використанням системного виклику connect(). Параметрами цього виклику задають дескриптор створеного раніше сокету, а також адресу, подібну до вказаної на сервері для ви­клику bind().

Після встановлення з'єднання (і на клієнті, і на сервері) з'явиться можливість передавати і приймати дані з використанням цього з'єднання. Для передавання даних застосовують системний виклик send(), а для приймання - recv().

Зазначену послідовність кроків використовують для встановлення надійного з'єднання. Якщо все, що нам потрібно, - це відіслати і прийняти конкретне пові­домлення фіксованої довжини, то з'єднання можна й не створювати зовсім. Для цього як відправник, так і одержувач повідомлення мають попередньо зв'язати сокети з адресами через виклик bind(). Потім можна скористатися викликами прямого передавання даних: sendto() - для відправника і recvfrom() - для одер­жувача. Параметрами цих викликів задають адреси одержувача і відправника, а також адреси буферів для даних.

 

3.

Технологія віддаленого виклику процедур (Remote Procedure Call, RPC) є прикладом синхронного обміну повідомленнями із підтвердженням отримання. Розглянемо послідовність кроків, необхідних для обміну даними в цьому разі.

1. Операцію send оформляють як виклик процедури із параметрами.

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

3. Одержувач викону