Моделі та механізми синхронізації

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

Мал. 2.3. Приклад необхідності синхронізації

Зневага питаннями синхронізації процесів, що виконуються в режимі мультипрограмування, може привести до їх неправильної роботи або навіть до краху системи. Розглянемо, наприклад (малюнок 2.3), програму друку файлів (принт-сервер). Ця програма друкує по черзі усі файли, імена яких послідовно в порядку вступу записують в спеціальний загальнодоступний файл "замовлень" інші програми. Особлива змінна NEXT, також доступна усім процесам-клієнтам, містить номер першою вільною для запису імені файлу позиції файлу "замовлень". Процеси-клієнти читають цю змінну, записують у відповідну позицію файлу "замовлень" ім'я свого файлу і нарощують значення NEXT на одиницю. Припустимо, що в деякий момент процес R вирішив роздрукувати свій файл, для цього він прочитав значення змінної NEXT, значення якої для визначеності припустимо рівним 4. Процес запам'ятав це значення, але помістити ім'я файлу не встиг, оскільки його виконання було перерване (наприклад, в наслідок вичерпання кванта). Черговий процес S, бажаючий роздрукувати файл, прочитав те ж саме значення змінної NEXT, помістив в четверту позицію ім'я свого файлу і наростив значення змінної на одиницю. Коли у черговий раз управління буде передано процесу R, то він, продовжуючи своє виконання, в повній відповідності зі значенням поточної вільної позиції, отриманим під час попередньої ітерації, запише ім'я файлу також в позицію 4, поверх імені файлу процесу S.

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

Критична секція

Важливим поняттям синхронізації процесів є поняття "Критична секція" програми. Критична секція - це частина програми, в якій здійснюється доступ до даних, що розділяються. Щоб виключити ефект перегонів по відношенню до деякого ресурсу, необхідно забезпечити, щоб в кожен момент в критичній секції, пов'язаній з цим ресурсом, знаходився максимум один процес. Цей прийом називають взаємним виключенням.

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

Іншим способом являється використання блокуючих змінних. З кожним ресурсом, що розділяється, зв'язується двійкова змінна, яка набуває значення 1, якщо ресурс вільний (тобто жоден процес не знаходиться в даний момент в критичній секції, пов'язаній з цим процесом), і значення 0, якщо ресурс зайнятий. На малюнку 2.4 показаний фрагмент алгоритму процесу, що використовує для реалізації взаємного виключення доступу до ресурсу D, що розділяється, блокуючу змінну F(D). Перед входом в критичну секцію процес перевіряє, чи вільний ресурс D. Якщо він зайнятий, то перевірка циклічно повторюється, якщо вільний, то значення змінної F(D) встановлюється в 0, і процес входить в критичну секцію. Після того, як процес виконає усі дії з ресурсом D, що розділяється, значення змінної F(D) знову встановлюється рівним 1.

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

Мал. 2.4. Реалізація критичних секцій з використанням блокуючих змінних

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

Реалізація критичних секцій з використанням блокуючих змінних має істотний недолік: впродовж часу, коли один процес знаходиться в критичній секції, інший процес, якому потрібно той же ресурс, виконуватиме рутинні дії з опитування блокуючої змінної, марно витрачаючи процесорний час. Для усунення таких ситуацій може бути використаний так званий апарат подій. За допомогою цього засобу можуть вирішуватися не лише проблеми взаємного виключення, але і загальніші завдання синхронізації процесів. У різних операційних системах апарат подій реалізується по своєму, але у будь-якому випадку використовуються системні функції аналогічного призначення, які умовно назвемо WAIT(x) і POST(x), де x - ідентифікатор деякої події. На малюнку 2.5 показаний фрагмент алгоритму процесу, що використовує ці функції. Якщо ресурс зайнятий, то процес не виконує циклічне опитування, а викликає системну функцію WAIT(D), тут D означає подію, що полягає в звільненні ресурсу D. Функція WAIT(D) переводить активний процес в стан ОЧІКУВАННЯ і робить відмітку в його дескрипторі про те, що процес чекає події D. Процес, який в цей час використовує ресурс D, після виходу з критичної секції виконує системну функцію POST(D), внаслідок чого операційна система переглядає чергу очікуючих процесів і переводить процес, очікуючий події D, в стан ГОТОВНІСТЬ.

Узагальнювальний засіб синхронізації процесів запропонував Дейкстра, який ввів два нові примітиви. У абстрактній формі ці примітиви, P, що означають, і V, оперують над цілими ненегативними змінними, що називаються семафорами. Нехай S такий семафор. Операції визначаються таким чином:

V(S): змінна S збільшується на 1 однією неділимою дією; вибірка, інкремент і запам'ятовування не можуть бути перервані, і до S немає доступу іншим процесам під час виконання цієї операції.

P(S): зменшення S на 1, якщо це можливо. Якщо S=0, то неможливо зменшити S і залишитися в області цілих ненегативних значень, в цьому випадку процес, зухвалий P -операцию, чекає, поки це зменшення стане можливим. Успішна перевірка і зменшення також є неділимою операцією.

У окремому випадку, коли семафор S може набувати тільки значень 0 і 1, він перетворюється на блокуючу змінну. Операція P містить в собі потенційну можливість переходу процесу, який її виконує, в стан очікування, тоді як V -операция може при деяких обставинах активізувати інший процес, призупинений операцією P (порівняєте ці операції з системними функціями WAIT і POST).

Мал. 2.5. Реалізація критичної секції з використанням системних функцій WAIT(D) і POST(D)

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

1. Що таке синхронізація процесів?
2. Як відбувається синхронізація процесів?
3. Які проблеми виникають при синхронізації?

Література

Електроний ресурс http://khpi-iip.mipk.kharkiv.edu/library/extent/os/sos/sos 02.html

Тема 4. Планування та диспетчеризація

План

4.1. Операції планування та диспетчеризації

4.2. Алгоритми планування

4.3. Процеси

4.4. Потоки

4.5. Завдання

4.1. Операції планування та диспетчеризації

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

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

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

Автоматичне планування і диспетчеризація (англ. Automated planning and scheduling, APS) — область завдань штучного інтелекту, що стосується виконання стратегії або послідовності дій, зазвичай для інтелектуальних агентів, автономних роботів і безпілотних апаратів. На відміну від класичних проблем управління і класифікації, рішення завдань цієї області комплексні, невідомі і повинні розроблятися і оптимізуватися у багатовимірному просторі.

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

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

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

Операційна система не може втрачати контроль над ходом виконання системних процедур, що викликаються по перериваннях. Вона повинна упорядковувати їх в часі так само, як планувальник упорядковує численні призначені для користувача потоки. Крім того, сам планувальник потоків є системною процедурою, що викликається по перериваннях (апаратним — від таймера або контроллера облаштування введення-виводу, або програмним — від додатка або модуля ОС). Тому правильне планування процедур, що викликаються по перериваннях, є необхідною умовою правильного планування призначених для користувача потоків. Інакше в системі можуть виникати, наприклад, такі ситуації, коли операційна система тривалий час займатиметься завданням управління, що не вимагає миттєвої реакції, стримером, що архівує дані, в той час, коли високошвидкісний диск простоюватиме і гальмуватиме роботу численних застосувань, що обмінюються даними з цим диском. Ще один приклад такої ситуації ілюструє мал. 4.12. В даному випадку обробник переривань принтера блокує на тривалий час обробку переривання від таймера, внаслідок чого системний час на деякий час «завмирає» і потік 2, критично важливий для користувача, не отримує управління в запланований час. Гостроту проблеми дещо пом'якшує та обставина, що у багатьох випадках обробка переривання пов'язана з виконанням всього декількох операцій введення-виводу і тому має дуже невелику тривалість. Проте ОС завжди повинна контролювати ситуацію і виконувати критичну роботу вчасно, а не покладатися на волю випадку.

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

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

Мал. 4.12. неврегульована обробка переривань

Витісняючі і не витісняючі алгоритми диспетчеризації

Диспетчеризація без перерозподілу процесорного часу, тобто не витісняюча багатозадачність - це такий спосіб диспетчеризації процесів, при якому активний процес виконується до тих пір, поки він сам, за своєю ініціативою, не віддасть управління диспетчерові завдань для вибору з черги іншого, готового до виконання процесу. Дисципліни обслуговування FCFS, SJN, SRT відносяться до тих, що не витісняють.

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

Операційна система виконує наступні функції:

- визначає момент зняття з виконання поточного завдання;

- зберігає контекст поточного завдання в дескрипторі завдання;

- вибирає з черги готових до виконання завдань наступну;

- завантажує контекст вибраного завдання;

- запускає вибране завдання на виконання.

Дисципліна RR і аналогічні їй відносяться до тих, що витісняють.

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

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

1. У чому полягає основна відмінність між плануванням процесів і диспетчеризацією завдань?
2. Які дисципліни диспетчеризації завдань ви знаєте? Поясните їх основні ідеї, перерахуєте достоїнства і недоліки.
3. Розкажіть, які дисципліни диспетчеризації слід віднести до тих, що витісняють, а які — до тих, що не витісняють.

Література

Їв.ресурс: http://ru.wikipedia.org/wiki/Автоматическое планирование _

Алгоритми планування

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

У системі передбачено 32 рівні пріоритетів. Шістнадцять значень пріоритетів (16-31) відповідають групі пріоритетів реального часу, п'ятнадцять значень (1-15) призначено для звичайних потоків, і значення 0 зарезервовано для системного потоку обнулення сторінок (див. мал. 6.2).

Мал. 6.2. Пріоритети потоків

Щоб позбавити користувача від необхідності запам'ятовувати числові значення пріоритетів і мати можливість модифікувати планувальник, розробники ввели в систему шар абстрагування пріоритетів. Наприклад, клас пріоритету для усіх потоків конкретного процесу можна задати за допомогою набору констант-параметрів функції SetPriorityClass, які можуть мати наступні значення:

реального часу (REALTIME_PRIORITY_CLASS),

високий (HIGH_PRIORITY_CLASS),

вище за норму (ABOVE_NORMAL_PRIORITY_CLASS),

нормальний (NORMAL_PRIORITY_CLASS),

нижче норми (BELOW_NORMAL_PRIORITY_CLASS)

і непрацюючий (IDLE_PRIORITY_CLASS).

Відносний пріоритет потоку встановлюється аналогічними параметрами функції SetThreadPriority:

Сукупність з шести класів пріоритетів процесів і семи класів пріоритетів потоків утворює 42 можливих комбінації і дозволяє сформувати так званий базовий пріоритет потоку (см таб. 6.1).

Базовий пріоритет процесу і первинного потоку за умовчанням дорівнює значенню з середини діапазонів пріоритетів процесів (24, 13, 10, 8, 6 або 4). Зміна пріоритету процесу спричиняє за собою зміну пріоритетів усіх його потоків, при цьому їх відносні пріоритети залишаються без змін.

Пріоритети з 16 по 31 насправді пріоритетами реального часу не є, оскільки у рамках підтримки м'якого реального часу, яка реалізована в ОС Windows, ніяких гарантій відносно термінів виконання потоків не даються. Це просто вищі пріоритети, які зарезервовані для системних потоків і тих потоків, яким такий пріоритет дає користувач з адміністративними правами. Проте, наявність пріоритетів реального часу, а також вытесняемость кода ядра, локалізація сторінок пам'яті (див. лекцію 10) і ряд додаткових можливостей - усе це дозволяє виконувати в середовищі ОС Windows додатки м'якого реального часу, наприклад, мультимедійні. Системний потік з нульовим пріоритетом займається обнуленням сторінок пам'яті. Звичайні призначені для користувача потоки можуть мати пріоритети від 1 до 15.

Динамічне підвищення пріоритету

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

Наприклад, після завершення операції введення-виводу збільшують пріоритет потоку, щоб дати йому можливість швидше почати виконання і, можливо, знову ініціювати операцію введення-виводу. У такий спосіб система заохочує інтерактивні потоки і підтримує зайнятість облаштувань введення-виводу. Величина, на яку підвищується пріоритет, не документована і залежить від пристрою (рекомендовані значення для диска і CD - це 1, для мережі - 2, клавіатури і миші - 6 і звукової карти - 8). Надалі впродовж декількох квантів часу пріоритет плавно знижується до базового.

Іншими прикладами подібних ситуацій можуть служити: пробудження потоку після стану очікування семафора або іншої події; отримання потоком доступу до віконного введення.

Динамічне підвищення пріоритету вирішує також проблему голодування потоків, що довго не дістають доступ до процесора. Виявивши такі потоки, що простоюють в течію приблизно 4 сек., система тимчасово підвищує їх пріоритет до 15 і дає їм два кванти часу. Побічним наслідком застосування цієї технології може бути вирішення відомої проблеми інверсії пріоритетів [9]. Ця проблема виникає, коли низькопріоритетний потік утримує ресурс, блокуючи високопріоритетні потоки, що претендують на цей ресурс. Рішення полягає в штучному підвищенні його пріоритету на деякий час.

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

Планування в умовах многопроцессорности

Реєнтерабельність коду ядра дозволяє ОС Windows підтримувати симетричні мультипроцесорні системи (процесори ідентичні). Необхідність завантаження декількох процесорів ускладнює завдання планування. Кількість процесорів система визначає при завантаженні, і ця інформація стає доступною додаткам через функцію GetSystemInfo. Число процесорів, використовуваних системою, може бути обмежене за допомогою параметра NumPcs з файлу Boot.ini.

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

Прив'язка до процесорів

У кожного потоку є маска прив'язки до процесорів (affinity mask), що вказує, на яких процесорах можна виконувати цей потік. За умовчанням Windows використовує нежорстку прив'язку (soft affmity) потоків до процесорів. Це означає, що деяка перевага має останній процесор, на якому виконувався потік, щоб повторно використовувати дані з кеша цього процесора (споріднене планування). Потоки наслідують маску прив'язки процесу. Зміна прив'язки процесу і потоку може бути здійснена за допомогою Win32 -функций SetProcessAffinityMask і SetThreadAfftnityMask або за допомогою інструментальних засобів Windows (наприклад, це може зробити диспетчер завдань). Є також можливість сформувати апріорну маску прив'язки у файлі образі процесу, що запускається.

Окрім номера останнього процесора у блоці ядра потоку KTHREAD зберігається номер ідеального процесора (ideal processor) - переважного для виконання цього потоку. Ідеальний процесор вибирається випадковим чином при створенні потоку. Це значення збільшується на 1 всякий раз, коли створюється новий потік, тому створювані потоки рівномірно розподіляються по набору доступних процесорів. Потік може поміняти це значення за допомогою функції SetThreadIdealProcessor.

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

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

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

Жорстка прив'язка (hard affinity), що виконується за допомогою функцій SetProcessAffinityMask і SetThreadAfftnityMask, доцільна в архітектурі з доступом, що не уніфікується (NUMA), де швидкість доступу до пам'яті залежить від взаємного розташування процесорів і банків пам'яті на системних платах.

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

1. У чому полягає планування?
2. Як відбувається прив'язка до процесів?
3. Як відбувається планування в умовах многопроцесорності?

Література

Їв. ресурс: http://its.lnpu.edu.ua/edocs 1/INTUIT.ru/html/department/os/osmswin/6/

osmswin_6.html _