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



Скачати 157.21 Kb.
Дата конвертації21.03.2016
Розмір157.21 Kb.


Міністерство освіти І науки, молоді та спорту України

національний університет “Львівська політехніка”

Кафедра ЕОМ
Реферат

на тему:


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

з дисципліни


«Системне програмне забезпечення»

Зміст



  1. Процес та його сутність…………………………………………………………………..3

  2. Поняття потоку та багатопотоковості. ………………………………………………….3

  3. Опис процесів і потоків. …………………………………………………………………4

  4. Стани процесів і потоків………………………………………………………………….6

  5. Створення і завершення процесів і потоків……………………………………………..7

  6. Керування адресним простором під час створення процесів…………………………..9

Висновок…………………………………………………………………………………...10

Список використаної літератури…………………………………………………………11



  1. Процес та його сутність.

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

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

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

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

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

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

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

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

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

• інформація про потоки процесу.

Виділення цих частин виправдане ще й тим, що в рамках одного адресного

простору може бути кілька паралельно виконуваних послідовностей команд, що

спільно використовують одні й ті ж самі дані.

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


  1. Поняття потоку та багатопотоковості.


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

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



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

  • стан регістрів;

  • системний стек ядра ОС (kernel stack);

  • стек користувача (user stack), розташований в адресному просторі процесу;

  • блок змінних оточення потоку.

Потік містить такі елементи:

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

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

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



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

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


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


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


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


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


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


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

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



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


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

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

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


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

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


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


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


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

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

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

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


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


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


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


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

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

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

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

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

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

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

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


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

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

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

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



Рис. 1 Образ процесу.




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

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

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

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

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

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

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

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




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


Базові принципи створення процесів
Процеси можуть створюватися ядром системи під час її ініціалізації. Наприклад, в Unix-сумісних системах таким процесом може бути процес ініціалізації системи іnit, у Windows ХР — процеси підсистем середовища (Win32 або РОSІХ). Таке створення процесів, однак, є винятком, а не правилом. Найчастіше процеси створюються під час виконання інших процесів. У цьому разі процес, який створює інший процес, називають предком, а створений ним процес — нащадком. Нові процеси можуть бути створені під час роботи застосування відповідно до його логіки (компілятор може створювати процеси для кожного етапу компіляції, веб-сервер — для обробки прибулих запитів) або безпосередньо за запитом користувача (наприклад, з командного інтерпретатора, графічної оболонки або файлового менеджера).

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

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

Фонові процеси із користувачем не взаємодіють безпосередньо. Зазвичай вони запускаються під час старту системи і чекають на запити від інших застосувань. Деякі з них (системні процеси) підтримують функціонування системи (реалізують фонове друкування, мережні засоби тощо), інші виконують спеціалізовані задачі (реалізують веб-сервери, сервери баз даних тощо). Фонові процеси також називають службами (SERVICES, у системах лінії WINDOWS ХР) або демонами (daemons, в Unix).

Після того як процес-предок створив процес-нащадок, потрібно забезпечити їхній взаємозв'язок. Є різні варіанти розв'язання цього завдання. Можна організувати на рівні ОС однозначний зв'язок ≪предок-нащадок≫ так, щоб для кожного процесу завжди можна було визначити його предка. Наприклад, якщо процеси визначені унікальними ідентифікаторами, то для реалізації цього підходу в керуючому блоці процесу-нащадка повинен завжди зберігатися ідентифікатор процесу-предка або посилання на його керуючий блок.

Таким чином формується ієрархія (дерево) процесів, оскільки нащадки можуть у свою чергу створювати нових нащадків і т. ін. У таких системах звичайно існує спеціальний вихідний процес (в UNIX-системах його називають і nit), з якого починається побудова дерева процесів (його запускає ядро системи). Якщо предок завершить виконання процесу перед своїм нащадком, функції предка бере на себе вихідний процес. З іншого боку, зв'язок ≪предок-нащадок≫ можна не реалізовувати на рівні ОС. При цьому всі процеси виявляються рівноправними. Якщо зв'язок ≪предок-нащадок≫ для конкретної пари процесів все ж таки потрібен, за його підтримку від повідають самі процеси (процес-предок, наприклад, може сам зберегти свій ідентифікатор у структурі даних нащадка у разі його створення). Взаємозв'язок між процесами не обмежується лише відношеннями ≪предок-нащадок≫. Наприклад, у деяких ОС є поняття сесії (session). Така сесія поєднує всі процеси, створені користувачем за час інтерактивного сеансу його роботи із системою.


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

виконати системний виклик завершення процесу. Такий виклик у POSIX-системах називають exitO. Він може повернути процесу, що його викликав, або ОС код повернення, який дає змогу оцінити результат виконання процесу. Процес аварійно завершується через помилку. Такий вихід може бути передбачений програмістом (під час обробки помилки приймається рішення про те, що

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

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


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

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

Під час створення потоку система повинна виконати такі дії.

1. Створити структури даних, які відображають потік в ОС.

2. Виділити пам'ять під стек потоку.

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

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

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

Як і процеси, потоки можуть виконуватися синхронно й асинхронно. Потік, створивши інший потік, може призупинити своє виконання до його завершення. Таке очікування називають приєднанням потоків (thread joining, очікує той, хто приєднує). Після завершення приєднаного потоку потік, який очікував його завершення, може дістати статус виконання. Під час створення потоку можна визначити, чи підлягає він приєднанню (якщо потік не можна приєднати, його на

зивають від'єднаним — detached). Якщо потік не є від'єднаним (nondetached або joinable, такий потік називатимемо приєднуваним), після завершення його обов'язко во потрібно приєднувати, щоб уникнути витікання пам'яті.

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

деякі з них можуть не встигнути завершити своє виконання до моменту виходу з f О. Можливо навіть, що частина потоків не завершиться й до моменту наступного виклику функції, якщо програміст виконає його достатньо швидко. Для потоків не підтримується така ієрархія, як для процесів. Потік, що створив інший потік, має рівні з ним права. Розраховувати на те, що такий потік сам буде продовжувати своє виконання після завершення потоків-нащадків, немає сенсу. Стек потоку очищається після виходу із функції потоку. Щоб цьому запобігти, не слід, наприклад, передавати нікуди покажчики на локальні змінні такої функції. Якщо необхідні змінні, значення яких мають зберігатися між викликами функції потоку, але при цьому вони не будуть доступні іншим потокам, треба скористатися локальною пам'яттю потоку (Thread Local Storage, TLS) — певним чином організованими даними, доступ до яких здійснюється за допомогою спеціальних функцій.


  1. Керування адресним простором під час створення процесів

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


Системні виклики fork() і ехес()
У першому підході адресний простір нащадка створюють як точну копію адресного простору предка. Така операція реалізована системним викликом, який у POSIX-системах називають fork().

У цьому разі копіюється не тільки адресний простір, а й лічильник команд головного потоку процесу, тому після виклику fork () предок і нащадок виконуватимуть ту саму інструкцію. Розробник має визначити, у якому з двох процесів перебуває керування. Це можна зробити на підставі відмінностей між кодами повернення fork() для предка і нащадка. Коли створення нового процесу відбувається шляхом дублювання адресного простору предка, виникає потреба у спеціальних засобах для завантаження програмного коду в адресний простір процесу. Такі засоби реалізує системний виклик, який у POSIX-системах називають ехес(). Як параметр для виклику exec ( ) треба вказувати весь шлях до виконуваного файла програми, який буде завантажено у пам'ять. У системах із підтримкою fork для того щоб запускати на виконання програми, після виклику fork потрібно негайно викликати exec О (це називають технологією fork+exec).


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

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

• виділення пам'яті під адресний простір нового процесу (жодна інформація при цьому з адресного простору предка не копіюється);

• завантаження виконуваного коду із зазначеного файла у виділений адресний простір.


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

Список використаної літератури


  1. Шеховцов В.А. «Операційні системи»




  1.  Гилев Ю.М., Дерюгін А.А. Особливості роботи многопроцессорной обчислювальної системи з загальної многомодульной пам'яттю./Міжнародний форум інформатизації – 2002: Доповіді міжнародної конференції «Інформаційні засоби і технології». 14-16 жовтня 2003 р., у 3-х Т.Т.Т3. – М.: До, 2003. – 221 с.



База даних захищена авторським правом ©refs.in.ua 2016
звернутися до адміністрації

    Головна сторінка