Для того щоб операційна система могла керувати процесами, вона повинна мати всю необхідну для цього інформацією. З цією метою на кожен процес зводиться спеціальна інформаційна структура, яка називається дескріп-тором процесу (описателем завдання, блоком управління завданням). У загальному випадку дескриптор процесу, як правило, містить наступну інформацію:
- ідентифікатор процесу (Process Identifier, PID);
- тип (або клас) процесу, який визначає для супервізора деякі пра-вила надання ресурсів;
- пріоритет процесу, відповідно до якого супервізор надає ре-сурси (в рамках одного класу процесів в першу чергу обслуговуються бо-леї пріоритетні процеси);
- змінну стану, яка визначає, в якому стані знаходиться про-процес (готовий до роботи, виконується, очікує пристрої введення-виведення і т. д.);
- інформацію про ресурсах, якими процес володіє і / або має право користу-тися (покажчики на відкриті файли, інформація про незавершені опера-ціях введення-виведення та ін.);
Поняття обчислювального процесу і ресурсу _______________________________ 35
- параметри часу запуску (момент часу, коли процес повинен актівізі-рова, і періодичність цієї процедури);
Описувачі завдань, як правило, постійно розташовуються в оперативній пам'яті з метою прискорити роботу супервізора, який організовує їх в списки (черги) і відображає зміну стану процесу переміщенням відповідного опи-сателіт з одного списку в інший. Для кожного стану (за винятком стану виконання для однопроцессорной системи) операційна система веде відповідний список завдань, які перебувають в цьому стані. Однак для со-стояння очікування зазвичай є не один список, а стільки, скільки різних видів ресурсів можуть викликати стан очікування. Наприклад, станів очіку-дання завершення операції введення-виведення може бути стільки, скільки пристроїв введення-виведення є в системі.
У деяких операційних системах кількість описателей визначається жест-ко і заздалегідь (на етапі генерації варіанту операційної системи або в конфігу-раційному файлі, який використовується при завантаженні ОС), в інших в міру необхідності система може виділяти ділянки пам'яті під нові описатели. На-приклад, в уже мало кому відомої системі OS / 2, яка кілька років тому багатьма фахівцями вважалася однією з кращих ОС для персональних комп'ютерів, максимально можливу кількість описателей завдань вказується в конфігураційному файлі CONFIG.SYS. Наприклад, рядок THREADS = 1024 в файлі CONFIG.SYS означає, що всього в системі може паралельно існувати і ви-виконуватися до 1024 завдань, включаючи обчислювальні процеси і їх потоки.
В операційних системах реального часу найчастіше кількість процесів фіксується, і, отже, доцільно заздалегідь визначати (на етапі гені-рації або конфігурації ОС) кількість дескрипторів. Для використання таких операційних систем як систем загального призначення (що нині вже нехарактерно) 'зазвичай кількість дескрипторів бралося з деяким запасом,
1 В недалекому минулому досить часто і як обчислювальних систем загального призначення при-знаходилися міні-ЕОМ і встановлювали на них ОС реального часу.
36_____________________________________________ Глава 1. Основні поняття
і поява нового завдання пов'язувалося із заповненням цієї інформаційної струк-тури. Оскільки дескриптори процесів постійно розташовуються в оперативній пам'яті (з метою прискорити роботу диспетчера), то їх кількість не повинна бути дуже великою.
Для більш ефективної обробки даних в системах реального часу целесо-образно мати постійні завдання, повністю або частково завжди існуючі в системі незалежно від того, надійшло на них вимога чи ні. Кожна по-стояло завдання володіє деякою власною областю оперативної пам'яті (ОЗУ-резидентная завдання, або просто резидентная завдання) незалежно від того, виконується завдання в даний момент чи ні. Ця область, зокрема, може використовуватися для зберігання даних, отриманих завданням раніше. Дані можуть зберігатися в ній і тоді, коли завдання знаходиться в стані очікування або навіть в стані бездіяльності.
Для апаратної підтримки роботи операційних систем з цими информацион-ними структурами (дескрипторами завдань) в процесорах можуть бути реалізовані відповідні механізми. Так, наприклад, в мікропроцесорах Intel 80x86 (див. Розділ 4) є спеціальний регістр TR (Task Register), який вказує міс-тонахожденіе спеціальної інформаційної структури - сегмента стану завдання (Task State Segment, TSS), в якому при перемиканні з задачі на задачу автоматично зберігається вміст регістрів процесора [1,8, 48].
Оскільки між термінами «процес» і «завдання» з часом з'явилося суще-ного відмінність, ми зараз детально розглянемо це питання.
Хоча поняття мультипрограмного і мультизадачного режимів роботи достатній-але близькі, це все-таки не одне і те ж. На жаль, тут до сих пір є деяка плутанина. Основні причини цього - не тільки те, що термінологія ще не усталилася і що багато фірм-розробники по-різному воліли називати одні і ті ж сутності, а й складність, неоднозначність ситуації.
Мультипрограмний режим передбачає, що операційна система організовує паралельне виконання декількох обчислювальних процесів на одному когось пьютере. І кожен обчислювальний процес може, в принципі, неможливо зави-мережу від іншого обчислювального процесу. Хіба що вони можуть затримати виконання один одного через необхідність черзі розділяти ресурси або сильно затримувати виконання один одного при володінні неподільні ресурсом. У них може не бути ні загальних файлів, ні загальних змінних. Вони взагалі можуть при-належних різним користувачам. Просто ці процеси, з позицій зовнішнього на-спостерігача, виконуються на одному і тому ж комп'ютері в один і той же час. Хоча можуть виконуватися і в різний час, і на різних комп'ютерах. Головне - це те, що мультипрограмний режим забезпечує для цих процесів їх неза-лежність. Кожному процесу операційна система виділяє витребувані ре-сурси, він виконується як би на окремій віртуальній машині. Засоби захисту системи повинні забезпечити невтручання одного обчислювального процесу в інший обчислювальний процес. І якщо такий захист забезпечити неможливо,
Поняття обчислювального процесу і ресурсу _______________________________ 37
то система не може вважатися надійним. Чимало методів і конкретних способів було придумано розробниками для забезпечення надійних обчислень і пре-дотвращенія можливості навмисно або помилково вплинути на результати обчислень в іншому процесі.
Однак існує й інша потреба: чи не розділити обчислювальні процес-си один від одного, а навпаки поєднати їх, забезпечити можливість тісного взаи-модействие між здійснюваними обчисленнями. Наприклад, результати ви-чисельний одного обчислювального процесу можуть вимагатися для початку або продовження роботи іншого. Існує величезна кількість ситуацій, коли необхідно забезпечити активну взаємодію між виконуються обчислюва-лительного процесами. Якщо немає можливості отримати доступ до змінних іншого процесу, бо операційна система побудована надійно і захищає ад-вій простору одного обчислювального процесу від втручання іншого обчислювального процесу, то виникають дуже серйозні перешкоди на шляху передачі яких би то ні було даних між процесами.
Термін мультизадачність режим роботи стали застосовувати як раз для тих випадків, коли необхідно забезпечити взаємодію між обчисленнями. Мультіза-дачний режим означає, що операційна система дозволяє організувати парал-лельно виконання обчислень, і є спеціальні механізми для передачі даних, синхросигналов, будь-яких повідомлень між цими взаємодію-ські обчисленнями. Це можна зробити за рахунок того, що такі обчислення не повинні системою ізолюватися один від одного. Операційна система не повинна для них в обов'язковому порядку задіяти всі механізми захисту обчислити-ний від невтручання один в одного. При мультизадачності режимі розробник програми повинен подбати про поділ ресурсів між його завданнями. Опера-Ціон система буде всього лише розділяти процесорний час між завданнями.
Поняття процесу було введено для реалізації ідей мультипрограммирования. Термін завдання теж, на жаль, в більшості випадків застосовувався для того ж. Свого часу розрізняли терміни «мультизадачність» і «мультіпрограммі-вання», але потім вони стали замінювати один одного, і це вносило неабияку плутані-цу. Таким чином, для реалізації мультизадачности в її вихідному тлумаченні необхідно було ввести відповідну сутність. Такий сутністю стали ліг-ковесние (thin) процеси, або, як їх тепер переважно називають, потоки виконання, нитки, або треди (threads).
'Потік виконання (thread) не слід плутати з потоком даних (stream).
38_____________________________________________ Глава 1. Основні поняття
Іншими словами, в разі процесів операційна система вважає їх абсолютно непов'язаними і незалежними. При цьому саме операційна система бере на себе роль арбітра в суперечках конкуруючих процесів за ресурси. Вона ж і забезпе-печує захист виконуються обчислень.
Поняття обчислювального процесу і ресурсу _______________________________ 39
Особливо ефективно можна використовувати багатопоточність для виконання рас-пределеніе додатків. Наприклад, багато-сервер може паралельно виконувати запити відразу декількох клієнтів. Як відомо, операційна сис-тема OS / 2 була однією з перших систем, використовуваних в персональних комп'ютерах терах, яка підтримувала многопоточность. В середині 90-х років для цієї опе-раціонної системи було створено велику кількість додатків, в яких наявність механізмів багатопотокової обробки реально призводило до суттєво-ному підвищенню швидкості обчислень. Для систем Windows, з якими ми всі маємо справу, яскраво вираженою багатопоточність мають такі продукти, як SQL Server, Oracle. І хоча ті ж Word, Excel, Internet Explorer також при своїй роботі утворюють потоки, явного паралелізму в цих програмах майже не під-тримувати. Тому при збільшенні числа процесорів в комп'ютері такі програми не починають виконуватися швидше.
Отже, сутність «потік виконання» була введена для того, щоб саме за допомогою на-гою цих одиниць розподіляти процесорний час між можливими робота-ми. Сутність «процес» передбачає, що при диспетчеризації потрібно враховувати-вать всі ресурси, закріплені за ним. При маніпулюванні завданнями-потоками можна змінювати тільки контекст завдання, якщо ми перемикається з одного завдання на інше в рамках одного процесу. Всі інші обчислювальні ресурси при цьому не зачіпаються. Кожен процес завжди складається, принаймні, з одно-го потоку виконання, і тільки якщо є внутрішній паралелізм, програм-мист може «розщепити» один потік на декілька паралельних. Потреба в потоках виникла ще в однопроцесорних обчислювальних системах, оскільки вони дозволяли організувати обчислення більш ефективно. Для використання переваг багатопроцесорних систем зі спільною пам'яттю потоки вже просто необ-ходимо, так як дозволяють не тільки реально прискорити виконання тих завдань, ко-торие допускають їх природне розпаралелювання, але і завантажити процесор-ні елементи роботою, з тим щоб вони не простоювали. Зауважимо, однак, що бажано, щоб можна було звести до мінімуму взаємодію потоків між-ду собою, бо прискорення від одночасного виконання паралельних потоків може бути зведене до мінімуму через затримки синхронізації і обміну даними.
Кожен потік виконується строго послідовно і має свій власний програмний лічильник і стек. Потоки, як і процеси, можуть породжувати потоки-нащадки, оскільки будь-який процес складається принаймні з одного потоку. Подібно традиційним процесам (тобто процесів, що складається з одного по-струму), кожен потік може перебувати в одному з активних станів. Поки один потік заблокований (або просто знаходиться в черзі готових до виконання за-дач), інший потік того ж процесу може виконуватися. Потоки поділяють про-цессорное час так само, як це роблять звичайні процеси, відповідно до раз-особистими варіантами диспетчеризації.
40_____________________________________________ Глава 1. Основні поняття
Поняття обчислювального процесу і ресурсу _______________________________ 41
Тепер, якщо повернутися до вже згаданого файлу CONFIG.SYS, в якому для опера-ційної системи OS / 2 вказуються найбільш важливі параметри, що визначають її роботу, варто зауважити, що в цьому файлі рядок THREADS = 1024 вказує на ко-личество не процес, а саме завдань. І під завданням в даному випадку розуміється як процес, так і потік цього процесу.
На завершення можна навести кілька порад з використання потоків ви-конання при створенні додатків, запозичених з [28].
- У разі однопроцессорной системи безліч паралельних потоків часто не прискорює роботу програми, оскільки в кожен окремо взятий проме-жуток часу можливе виконання тільки одного потоку. Крім того, чим більше у вас потоків, тим більше навантаження на систему, що відносяться до пере-дання між ними. Мультизадачність з більш двох постійно працюю-чих потоків в вашому проекті не зробить програму швидше, якщо кожен з потоків не буде вимагати частого введення-виведення.
- Спочатку потрібно зрозуміти, для чого необхідний потік. Потік, який здійснює обробку, може перешкодити системі швидко реагувати на запити вводу-ви-вода. Потоки дозволяють програмі відгукуватися на прохання користувача і уст-ройств, але при цьому (в тому числі) сильно завантажують процесор. Потоки позволя-ють комп'ютера одночасно обслуговувати безліч пристроїв, і створений вами потік, який відповідає за обробку специфічного пристрою, як міні-мум може зажадати стільки часу, скільки системі необхідно для про-ництва запитів від всіх пристроїв.
- Потокам можна призначати різні пріоритети для того, щоб найменш значи-мі процеси виконувалися у фоновому режимі. Це шлях чесного поділу ресурсів процесора. Однак необхідно усвідомити той факт, що процесор один на всіх, а потоків багато. Якщо у вашій програмі головна процедура передає щось для обробки в фоновий потік, то сама програма становит-ся просто некерованою.
- Потоки добре працюють, коли вони незалежні. Але вони починають працювати непродуктивно, коли змушені часто синхронізуватися для доступу до об-щим ресурсів. Взаємні блокування і критичні секції аж ніяк не добав-ляють швидкості роботи системи, хоча без використання цих механізмів взаємо-модействие обчислення організовувати не можна.
42_____________________________________________ Глава 1. Основні поняття
- Всякий раз, коли будь-який з ваших потоків намагається скористатися загальним ресурсом обчислювального процесу, якому він належить, ви зобов'язані якимось чином легалізувати і захистити вашу діяльність. Хорошим середовищ-ством для цього є критичні секції, семафори і черги сообще-ний (див. Розділ 7). Якщо ви протестували ваше додаток і не виявили помилок синхронізації, то це ще не означає, що їх там немає. Користувач мо-же створювати самі непередбачувані ситуації. Це дуже відповідальний мо-мент в розробці багатопоточних додатків.
- Чи не покладайте на потік кілька функцій. Складні функціональні відно-шення ускладнюють розуміння загальної структури програми, його алгоритм. Чим простіше і однозначно кожна з розглянутих ситуацій, тим більше веро-ятность, що помилок вдасться уникнути.