Чи призупиняє спільний графік призупинення процесів, коли вони виконують операцію вводу / виводу?

19

Багато посилань на операційні системи говорять, що при спільній (на відміну від попереджувальної) багатозадачності процес зберігає процесор, поки він явно не призупинить себе. Якщо запущений процес виконує запит вводу / виводу, який не вдається негайно задовольнити (наприклад, запитує ключовий обведення, який ще не доступний), чи планувач призупиняє його чи дійсно зберігає ЦП, поки запит не може бути обслужений?

[Відредаговано для заміни "блоків на вводу / виводу" на "виконує запит вводу / виводу, який неможливо негайно задовольнити."]

operating-systems process-scheduling

— Еллен Спертус
джерело

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

— Рафаель

3

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

— Еллен Спертус

15

У дійсно "спільній" обстановці, і якщо не було захищеного обладнання, процес, безумовно, може блокувати введення-виведення і не відмовлятися від управління, поки введення-виведення не виконано (або ніколи не відмовляться від контролю взагалі). Наприклад, Windows 3.1 був таким чином: якщо один користувальницький процес хотів захопити весь комп'ютер і не допустити запуску будь-чого іншого, він міг би.

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

— Карл Маммерт
джерело

11

Якщо запущений процес блокується на i / o

Блокування IO - це майже рівнозначно призупиненню процесу. У контексті ядра Linux виконання деяких системних викликів вводу-виводу, таких як read(), викликає sysenterобробник або переривання, щоб викликати догляд за цим IO, викликаючи в do_sys_read()кінцевому рахунку. Тут, якщо поточний запит не може бути задоволений негайно, функція викликає, sched()яка потім може виконати інший процес.

У контексті кооперативної системи я б очікував, що коли ви робите системний виклик з якоїсь причини IO, якщо запит не може бути задоволений, ядро вибирає інше завдання і виконує це. Цей документ містить деяку інформацію - в основному, якщо ви чекали на IO, ви могли б повічно вішати, чекаючи цього IO. Ідея планування кооперативного планування полягає в тому, що ви часто дзвоните sched()або еквівалентним методом відмовитися від процесора, якщо ви виконуєте завдання, що вимагають процесора.

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

4

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

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

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

EDIT: Моя відповідь була заснована на плануванні, як описано в його первісному вигляді (років тому: P). Як коментує Жилл, деякі системи все ще використовують спільне планування. І є планувальник. Я не впевнений, що ці системи використовують COS у чистому та оригінальному вигляді.

— Анкіт
джерело

2

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

— Жил "ТАК - перестань бути злим"

@Gilles Хороший коментар (введення в редагування). Я погоджуюсь з вами, що його не повністю використовувати. Моя відповідь якраз ґрунтувалася на алгоритмі, визначеному спочатку. AFIK, він використовується з деякими модифікаціями (з деяким планувальником). Я не впевнений, чи використовувався він у чистому вигляді в якійсь ОС.

— Анкіт

4

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

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

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

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

— Пекка
джерело