вводу-виводу). Ідея Полягає в тому, щоб підтрімуваті завантаження прістроїв ВСТУП-Виведення. Величина Підвищення пріорітету поклади від пристрою ВСТУП-Виведення - зазвічай для диска це 1, для послідовної Лінії - 2, для клавіатурі - 6, а для звукової карти - 8.
По-друге, ЯКЩО Потік чека на семафорі, м'ютекс або іншу подію, то при его звільненні ВІН отрімує Підвищення пріорітету на 2 уровня, ЯКЩО ВІН знаходится у фоновому процесі (Наприклад, процес, Який управляє вікном, у Яке надсілається Введення з клавіатурі), и на 1 рівень у всех других випадка. Таке Підвищення піднімає інтерактівні Процеси над великою кількістю процесів, что знаходяться на Рівні 8. І Нарешті, ЯКЩО Потік графічного інтерфейсу користувача прокідається з причини наявності введенню від користувача, то ВІН такоже отрімує Підвищення (з тієї ж самої причини).
Такі Підвищення робляться НЕ назавжди. Смороду вступають в дію негайно и могут віклікаті Зміни в плануванні процесора. Однак ЯКЩО Потік вікорістовує весь свой Наступний квант, то ВІН втрачає один рівень пріорітету и переміщується вниз на одну черго в масіві пріорітетів. Если ж ВІН вікорістовує другий повний квант, то ВІН переміщається вниз ще на один рівень - и так до тих ПІР, поки ВІН НЕ дійде до свого базового уровня (де и залиша до Наступний Підвищення).
Є ще один випадок коригування пріорітетів. Уявімо, что два потоки Працюють разом над Завдання «виробник-споживач». Робота виробника важче, так что ВІН отрімує більш високий Пріоритет (Наприклад, 12), чем споживач (Пріоритет 4). У Певний момент виробник Заповнює спільно вікорістовуваній буфер и блокується на семафорі (рис. 1.3.3.2. А.).
Рис. 1.3.3.2. Приклад інверсії пріорітетів
До того як споживач отрімує можлівість запустітіся, Якийсь Інший Потік з пріорітетом 8 отрімує Готовність и почінає Виконання (ріс.1.3.3.2. б). цею Потік зможите Виконувати стількі, Скільки ВІН захочу, - оскількі ВІН має більш високий Пріоритет планування, чем споживач (а виробник, Пріоритет Якого ще Вище, блокованій). У таких обставинні виробник Ніколи Не зможу запустітіся (поки Потік з пріорітетом 8 НЕ піде). Вірішує Цю проблему Наступний способом. Система відстежує, Скільки годині пройшло з того моменту, коли в Останній раз віконувався готов Потік. Если цею годину перевіщує ПЄВНЄВ межу, то его Пріоритет підвіщується до 15 на годину двох квантів. Це может дати їй можлівість розблокуваті виробника. После Закінчення двох квантів годині це Підвищення різко знімається (а не зменшується поступово). Ймовірно, більш вдалину рішенням Було б штрафуваті потоки, Які Використовують свой квант Знов і вновь (зніжуваті їх Пріоритет). Зрештою, проблема булу віклікана не голодні потоком, а ненажерлівім. Ця проблема добро відома як інверсія пріорітетів (priority inversion).
Аналогічна проблема відбувається тоді, коли Потік з пріорітетом 16 захоплює м'ютекс и ПРОТЯГ трівалого години не отрімує возможности Виконання (прідушіті таким чином більш Важливі Сістемні потоки, Які чекають цею м'ютекс). Цю проблему можна Було б Запобігти всередіні операційної системи, ЯКЩО б потребує м'ютекс Потік на Деяк короткий годину відключав планування. (У багатопроцесорної Системі слід використовуват спін-Блокування.)
На клієнтськіх системах Windows Значення кванта за замовчуванням дорівнює 20 мс. На серверних ...
