• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Обробка переривань з переключенням на нову задачу.

Зовсім інакше здійснюється обробка переривань у випадку, якщо дескриптором переривань є комутатор задачі. Формат комутатора задачі (task gate) відрізняється від комутаторів interrupt gate і trap gate, насамперед, тим, що в ньому замість селектора сегмента коду, на який передається керування, указується селектор сегмента стану задачі (TSS). Це ілюструється за допомогою мал. 3.14. У результаті здійснюється процедура переходу на нову задачу з повною зміною контексту, тому що сегмент стану задачі цілком визначає новий віртуальний простір і адресу початку програми, а поточний стан задачі, що переривається, апаратно (по мікропрограмі мікропроцесора) зберігається в її власному TSS.

Рис. 8.3Схема передачі керування при перериванні з переключенням на нову задачу.

При цьому відбувається повне переключення на нову задачу з вкладенням, тобто виконуються наступні дії:

1. Зберігаються всі робочі регістри процесора в поточному сегменті TSS, базова адреса цього сегмента береться в регістрі TR.

2. Поточна задача відзначається як зайнята.

3. По селекторі з Task Gate вибирається новий TSS (поле селектора міститься в регістр TR) і завантажується стан нової задачі. Нагадаємо, що завантажуються значення регістра LDTR, EFLAGS, вісім регістрів загального призначення, покажчик команди регістр EIP і шість сегментних регістрів.

4. Установлюється біт NT (next task).

5. У поле зворотного зв'язку TSS міститься селектор перерваної задачі.

6. Значення CS:IP, узяті з нового TSS, дозволяють знайти і виконати першу команду оброблювача переривання.

Таким чином, комутатор task gate дає вказівку процесору зробити переключення задачі, і обробка переривання здійснюється під контролем окремої зовнішньої задачі. У кожнім сегменті TSS є селектор локальної дескрипторної таблиці LDT, тому при переключенні задачі процесор завантажує в регістр LDTR нове значення. Це дозволяє звернутися до сегментів коду, що абсолютно не перетинаються із сегментами коду будь-яких інших задач, оскільки саме локальні дескрипторні таблиці забезпечують ефективне ізолювання віртуальних адресних просторів. Нова задача починає своє виконання на рівні привілеїв, обумовленому полем RPL нового вмісту регістра CS, що завантажується із сегмента TSS. Перевагою цього комутатора є те, що він дозволяє зберегти всі регістри процесора за допомогою механізму переключення задач, тоді як комутатори trap gate і interrupt gate зберігають тільки вміст регістрів IFLAGS, CS і IP і збереження інших регістрів покладається на програміста, що розробляє відповідну програму обробки переривання.

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

Тема 9. Керування вводом/виводом даних.

1. Основні поняття і визначення процесу вводу/виводу даних. Основні задачі супервізора вводу/виводу даних.

2. Режими керування вводом/виводом.

3. Закріплення пристроїв, загальні пристрої вводу/виводу.

4. Основні системні таблиці вводу/виводу.

5. Синхронний і асинхронний ввід/вивід.

6. Кешування операцій вводу/виводу при роботі з накопичувачами на магнітних дисках.

1. Основні поняття і визначення процесу вводу/виводу.

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

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

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

· Необхідність вирішувати можливі конфлікти доступу до пристроїв вводу/виводу. Наприклад, дві паралельно виконуємі програми намагаються вивести на друк результати своєї роботи. Якщо не передбачити зовнішнє керування пристроєм друкку, то в результаті ми можемо одержати текст, що абсолютно нечитається, тому що кожна програма буде час від часу виводити свої дані, що будуть перемежовуватися з даними іншої програми. Інший приклад: ситуація, коли одній програмі необхідно прочитати дані з деякого сектора магнітного диска, а іншій — записати результати в інший сектор того ж накопичувача. Якщо операції вводу/виводу не будуть відслідковуватися якимось третім (зовнішнім) процесом-арбітром, то після позиціювання магнітної голівки для першого запиту може відразу з'явитися команда позиціювання голівки для другої задачі, і обидві операції вводу/виводу не зможуть бути виконані коректно.

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

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

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

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

· супервізор вводу/виводу викликає відповідні розподільники каналів і контролерів, планує ввід/вивід (визначає чергу надання пристроїв вводу/виводу задачам, що потребують їх). Запит на введення/виведення або відразу виконується, або ставиться в чергу на виконання;

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

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

· супервізор вводу/виводу здійснює передачу повідомлень про помилки, якщо такі виникають в процесі керування операціями вводу/виводу;

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

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

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

Згаданий вище запит на ввід/вивід повинний задовольняти вимогам API тієї операційної системи, у середовищі якої виконується додаток. Параметри, що вказуються в запитах на ввід/вивід, передаються не тільки в викликаючих послідовностях, створюваних по специфікаціях API, але і як дані, які зберігаються у відповідних системних таблицях. Усі параметри, які будуть стояти в викликаючій послідовності, поставляються компілятором і відбивають вимоги програміста і постійну інформацію про операційну систему й архітектуру комп'ютера в цілому. Змінна інформація про обчислювальну систему (її конфігурація, склад устаткування, склад і особливості системного програмного забезпечення) містяться в спеціальних системних таблицях. Процесору, каналам прямого доступу в пам'ять, контролерам необхідно передавати конкретну двійкову інформацію, за допомогою якої і здійснюється керування устаткуванням. Ця конкретна двійкова інформація у виді кодів і даних часто готується за допомогою препроцесорів, але частина її зберігається в системних таблицях.

2. Режими керування вводом/виводом.

Рис.9.1 Керування вводом/виводом.

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

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

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

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

Секція завершеннязвичайно виключає пристрій вводу/виводу або просто завершує операцію.

Керування операціями вводу/виводу в режимі переривань вимагає великих зусиль з боку системних програмістів — такі програми створювати складніше, ніж ті, що працюють у режимі опитування готовності. Прикладом тому може служити ситуація з драйверами, що забезпечують друк. Так, в ОС Windows (і Windows 9x, і Windows NT) драйвер друку через паралельний порт працює не в режимі з перериваннями, як це зроблено в інших ОС, а в режимі опитування готовності, що приводить до 100%-го завантаження центрального процесора на весь час друку. При цьому, природньо, виконуються й інші задачі, запущені на виконання, але винятково за рахунок того, що ОС Windows реалізує витісняючу мультизадачність і час від часу перериває процес керування друком і передає центральний процесор іншим задачам.

3. Закріплення пристроїв, загальні пристрої вводу/виводу.

Як відомо, багато пристроїв не допускають спільного використання. Насамперед, це пристрої з послідовним доступом. Такі пристрої можуть стати закріпленими, тобто бути наданими деякому обчислювальному процесу на весь час життя цього процесу. Однак це приводить до того, що обчислювальні процеси часто не можуть виконуватися паралельно — вони очікують звільнення пристроїв вводу/виводу. Для організації використання багатьма паралельно виконуючими задачами пристроїв вводу/виводу, що не можуть бути поділюваними, вводиться поняття віртуальних пристроїв. Використання принципу віртуалізації дозволяє підвищити ефективність обчислювальної системи.

Узагалі говорячи, поняття віртуального пристрою ширше, ніж використання цього терміну для позначення спулінгу (SPOOLing — simultaneous peripheral operation on-line, тобто імітація роботи з пристроєм у режимі «он-лайн»). Головна задача спулінгу — створити видимість паралельного поділу пристрою вводу/виводу з послідовним доступом, що фактично повинно використовуватися тільки монопольно і бути закріпленим. Наприклад, ми вже говорили, що у випадку, коли кілька програм повинні виводити на друк результати своєї роботи, якщо дозволити кожній такій програмі друкувати рядок на першу вимогу, то це приведе до потоку рядків, що не представляють ніякої цінності. Однак можна кожному обчислювальному процесу надавати не реальний, а віртуальний принтер і потік виведених символів (чи керуючих кодів для їхнього друку) спочатку направляти в спеціальний файл на магнітному диску. Потім, по закінченні віртуального друку, відповідно до прийнятої дисципліни обслуговування і пріоритетами додатків виводити вміст спул-файла на принтер. Системний процес, що керує спул-файлом називається спулером (spool-reader чи spool-writer).

4. Основні системні таблиці вводу/виводу.

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

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

Перша таблиця (чи список) містить інформацію про всі пристрої вводу/виводу, підключених до обчислювальної системи. Назвемо її умовно таблицею устаткування(equipment table), а кожен елемент цієї таблиці нехай називається UCB (unit control block, блок керування пристроєм вводу/виводу). Кожен елемент UCB таблиці устаткування, як правило, містить наступну інформацію про пристрій:

· тип пристрою, його конкретна модель, символічне ім'я і характеристики пристрою;

· як цей пристрій підключений (через який інтерфейс, до якого роз‘єму, які порти і лінія запиту переривання використовуються і т.д.);

· номер і адресу каналу (і підканалу), якщо такі використовуються для керування пристроєм;

· вказівка на драйвер, що повинний керувати цим пристроєм, адреса секції запуску і секції продовження драйвера;

· інформація про те, використовується чи ні буферизація при обміні даними з цим пристроєм, «ім'я» (чи просто адреса) буфера, якщо такий виділяється із системної області пам'яті;

· уставка тайм-ауту і комірки для лічильника тайм-ауту;

· стан пристрою;

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

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

Друга таблиця призначена для реалізації ще одного принципу віртуалізації пристроїв вводу/виводу — незалежності від пристрою. Бажано, щоб програміст не був заклопотаний обліком конкретних параметрів (і/чи можливостей) того чи іншого пристрою вводу/виводу, що встановлене (чи не встановлене) у комп'ютер. Для нього повинні бути важливі тільки самі загальні можливості, характерні для даного класу пристроїв вводу/виводу, якими він бажає скористатися. Наприклад, принтер повинний уміти виводити (друкувати) символи чи графічне зображення. А накопичувач на магнітних дисках —зчитувати чи записувати по зазначеній адресі (у координатах C-H-S) порцію даних. Хоча найчастіше програміст і не використовує пряму адресацію при роботі з магнітними дисками, а працює на рівні файлової системи. Однак у такому випадку вже розроблювачі файлової системи не повинні залежати від того, накопичувач якого конкретного типу і моделі, а також якого виробника використовується в даному конкретному комп'ютері (наприклад, HDD IBM DTLA 307030, WDAC 450AA чи який-небудь ще). Важливим повинний бути тільки сам факт існування накопичувача, що має деяку кількість циліндрів, голівок читання/запису і секторів на доріжці магнітного диска. Згадані значення кількості циліндрів, голівок і секторів повинні бути взяті з елемента таблиці устаткування. При цьому для програміста також не повинне мати значення, яким чином той чи інший пристрій підключений до обчислювальної системи, а не тільки яка конкретна модель пристрою використовується. Тому в запиті на ввід/вивід програміст вказує саме логічне ім'я пристрою. Дійсний пристрій, що зіставляється віртуальному (логічному), вибирається супервізором за допомогою таблиці, про яку ми зараз говоримо. Отже, спосіб підключення пристрою, його конкретна модель і відповідний їй драйвер містяться у вже розглянутій таблиці устаткування. Але для того, щоб зв'язати деякий віртуальний пристрій, використаний програмістом при створенні додатку із системною таблицею, що відображає інформацію про те, який конкретний пристрій і яким чином підключений до комп'ютера, використовується друга системна таблиця. Назвемо її умовно таблицею опису віртуальних логічних пристроїв (DRT, device reference table). Призначення цієї другої таблиці — встановлення зв'язку між віртуальними (логічними) пристроями і реальними пристроями, описаними за допомогою першої таблиці устаткування. Іншими словами, друга таблиця дозволяє супервізору перенаправляти запит на ввід/вивід з додатку на ті програмні модулі і структури даних, які (або адреси яких) зберігаються у відповідному елементі першої таблиці. У багатьох багатокористувацьких системах така таблиця не одна, а декілька: одна загальна і по одній — на кожного користувача, що дозволяє будувати необхідні зв'язки між логічними (символьними) іменами пристроїв і реальних фізичних пристроїв, що є в системі.

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

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

Взаємозв'язок між описаними таблицями зображені на рис.9.2.

Рис.9.2 Взаємозв‘язок системних таблиць вводу/виводу.

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

Рис.9.3 Процес управління вводом/виводом.

Запит на операцію вводу/виводу від програми, що виконується, надходить на супервізор (дія 1). Той перевіряє системний виклик на відповідність прийнятим специфікаціям і у випадку помилки повертає задачі відповідне повідомлення (дія 1-1). Якщо ж запит коректний, то він перенаправляється в супервізор вводу/виводу (дія 2). Останній по логічному (віртуальному) імені за допомогою таблиці DRT знаходить відповіднийелемент UCB у таблиці устаткування. Якщо пристрій уже зайнятий, то описувач задачі, запит якої зараз обробляєтьсясупервізором вводу/виводу, поміщаєте в список задач, що очікують дійсний пристрій.Якщо ж пристрій вільний, то супервізор вводу/виводу визначає з UCB тип пристрою і при необхідності запускає препроцесор, що дозволяє одержати послідовність керуючихкодів і даних, що зможе правильно зрозуміти і відробити пристрій (дія 3). Коли «програма» керування операцією вводу/виводу, будеготова, супервізор вводу/виводупередасть керування відповідному драйверу на секцію запуску (дія 4). Драйвер ініціалізує операцію керування, обнуляє лічильник тайм-ауту і повертає керуваннясупервізору (диспетчерузадач) для того, щоб він поставив на процесор готову до виконання задачу (дія 5). Система працює своєю чергою, але коли пристрій вводу/виводувідробить послану йому команду, він виставляє сигнал запиту на переривання, по якому через таблицюпереривань керування передається на секцію продовження (дія 6). Одержавши нову команду, пристрій знову починає її обробляти,а керування процесором знову передається диспетчеру задач, і процесор продовжує корисну роботу. Таким чином, виходить паралельна обробка задач, на тлі якої процесор здійснює керування операціями вводу/виводу.

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

При описі цієї схеми ми не стали торкатись питань розподілу каналів, контролерів і власне самих пристроїв. Також були опущені деталі одержання канальних програм. Будемо вважати, що вони виходять за коло питань, розглянутих у підручнику по дисципліні «Системне програмне забезпечення».

4.Синхронний і асинхронний ввід/вивід.

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

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

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

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

Апаратуру вводу/виводу можна розглядати як сукупність апаратури процесорів, що здатні працювати паралельно відносно один одного також щодо центрального процесора (процесорів).На таких «процесорах» виконуються так звані зовнішні процеси. Наприклад, для зовнішнього пристрою (пристрою вводу/виводу) зовнішній процес може являти собоюсукупність операцій, що забезпечують переклад друкуючої голівки, просуванняпаперу на одну позицію, зміну кольору чорнила чи друк якихось символів. Зовнішні процеси, використовуючи апаратуру вводу/виводу,взаємодіють як між собою, так і зі звичайними«програмними» процесами, що виконуютьсяна центральному процесорі. Важливим при цьому є та обставина, що швидкості виконанні зовнішніх процесів будуть істотно (часом, па чи порядок більше) відрізнятися від швидкості виконання звичайних («внутрішніх») процесів. Для своєї нормальної роботи зовнішні і внутрішні процеси обов'язково повинні синхронізуватися. Для згладжування цього дефекту сильної невідповідності швидкостей між внутрішніми і зовнішніми процесами використовують згадане вище буферизація. Таким чином, можна говорити про систему рівнобіжних взаємодіючих процесів. Буфери є критичним ресурсом у відношенні внутрішніх (програмних) і зовнішніх процесів, що при рівнобіжному своєму розвитку информационно взаємодіють. Через буфер (буфери) дані або посилаються від деякого процесу до адресуемому зовнішнього (операція виведення даних на зовнішній пристрій), або від зовнішнього процесу передаються деякому програмному процесу (операція зчитування даних). Введення буферування як засобу інформаційної взаємодії висуває проблему в керування цими системними буферами, що зважується засобами супервізорної частини ОС. При цьому на супервізор покладаються задачі не тільки по виділенню і звільненню буферів у системній області пам'яті, але і синхронізації процесів відповідно до стану операцій по заповненню чи звільненню буферів, а також їхнього чекання, якщо вільних буферів у наявності немає, а запит на ввід/вивід вимагає буферування. Звичайно супервізор вводу/виводу для рішення перерахованих задач використовує стандартні засоби синхронізації, прийняті в даній ОС. Тому якщо ОС має розвинуті засоби для рішення проблем паралельного виконання взаємодіючих додатків і задач, то, як правило, вона реалізує й асинхронний ввід/вивід.

6. Кешування операцій вводу/виводу при роботі з накопичувачами на магнітних дисках.

Як відомо, накопичувачі на магнітних дисках мають вкрай низьку швидкість в порівнянні з швидкодією центральної частини комп'ютера. Різниця у швидкодії відрізняється на кілька порядків. Наприклад, сучасні процесори за один такт роботи, а вони працюють уже з частотами і 1 ГГц і більше, можуть виконувати по дві операції. Таким чином, час виконання операції (з позиції зовнішнього спостерігача, що не бачить конвеєризації при виконанні машинних команд, завдяки якій продуктивність зростає в кілька разів) може складати 0,5 нс (!). У той же час перехід магнітної голівки з доріжки на доріжку складає декілька мілісекунд. Такі ж тимчасові інтервали мають місце і при чеканні, поки під голівкою читання/запису не виявиться потрібний сектор даних. Як відомо, у сучасних приводах середня тривалість на читання випадковим чином обраного сектора даних складає близько 20 мс, що істотно повільніше, ніж вибірка команди чи операнда з оперативної пам'яті і тимбільше з кешу. Правда, після цьогодані читаються великим пакетом (сектор, як ми вже говорили, має розмір у 512 байтів, а при операціях з диском часто читається чи записується відразу кілька секторів). Таким чином, середня швидкість роботи процесора з оперативною пам'яттю на 2-3 порядки вище, ніж середня швидкість передачі даних із зовнішньої пам'яті на магнітних дисках в оперативну пам'ять.

Для того щоб згладити таку сильну невідповідність у продуктивності основних підсистем, використовується буферизація і/чи кешування даних. Найпростішим варіантом прискорення дискових операцій читання даних можна вважати використання подвійного буферування. Його суть полягає в тім що поки в один буфер заносяться дані з магнітного диска, із другого буфера раніше зчитані дані можуть бути прочитані і передані їх задачі, що подавала запит на них. Аналогічний процес відбувається і при записі даних. Буферизація використовується у всіх операційних системах, але крім буферування застосовується і кешування. Кешування винятково корисно в тому випадку, коли програма неодноразово читає з диска ті самі дані. Після того як вони один раз будуть поміщені в кеш, звертань до диска більше не потрібно і швидкість роботи програми значно зросте.

Якщо не вдаватися в подробиці, то під кешім можна розуміти деякий пул буферів, якими ми керуємо за допомогою відповідного системного процесу. Якщо ми зчитуємо якусь безліч секторів, що містять записи того чи іншого файлу, то ці дані, пройшовши через кеш, там залишаються (до тих пір поки інші сектори не замінять ці буфери). Якщо в наслідку буде потрібне повторне читання, то дані можуть бути витягнуті безпосередньо з оперативної пам'яті без фактичного звертання до диска. Прискорити можна й операції запису: дані поміщаються в кеш, і для задачі, що запросила цю операцію, можна вважати, що вони уже фактично і записані. Задача може продовжити своє виконання, а системні зовнішні процеси через якийсь час запишуть дані на диск. Це називається операцією відкладеного запису (lazy write «ледачий запис»). Якщо відкладений запис відключений, тільки одна задача може записувати на диск свої дані. Інші додатки повинні чекати своєї черги. Це чекання піддає інформацію ризику не меншому (якщо не більшому), чим відкладений запис, що до того ж і більш ефективний по швидкості роботи з диском.

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

Кешування дискових операцій може бути істотно покращене за рахунок введення технікипопереднього читання (read ahead). Вона заснована на читанні з диска набагато більшої кількості даних, чим насправді запросила операційна система чи додаток. Коли деякій програмі потрібно зчитати з диска тільки один сектор, програма кешування читає ще і кілька додаткових блоків даних. А операції послідовного читання декількох секторів фактично несуттєво сповільнюють операцію читання викликаного сектора з даними. Тому, якщо програма знову звернеться до диска, імовірність того, що потрібні їй дані вже знаходяться в кеші, досить висока. Оскільки передача даних з однієї області пам'яті в другу відбувається в багато разів швидше, ніж читання їх з диска, кешування істотно скорочує час виконання операцій з файлами.

Отже, шлях інформаціївід диска до прикладної програми пролягає як через буфер, так і через файловий кеш. Коли додаток запитує з диска дані, програма кешування перехоплює цей запит і читає разом з необхідними секторами і ще декілька додаткових. Потім вона поміщає в буфер інформацію, яка потрібна задачі, і повідомляє про це операційну систему. Операційна система повідомляє задачі, що її запит виконаний і дані з диска знаходяться в буфері. При наступному звертанні додатка до диска програма кешування насамперед перевіряє, чи не знаходяться вже в пам'яті викликані дані. Якщо це так, то вона копіює їх у буфер; якщо ж їх у кеші немає, то запит на читання диска передається операційній системі. Коли задача змінює дані в буфері, вони копіюються в кеш. У ряді ОС є можливість вказати в явному виді параметри кешування, у той час як в інших за ці параметри відповідає сама ОС. Так, наприклад, у системі Windows NT немає можливості в явному виді керувати ні обсягом файлового кешу, ні параметрами кешування. У системах Windows 95/98 така можливість вже є, але вона представляє не дуже великий вибір. Фактично ми можемо вказати тільки обсяг пам'яті, що відводиться для кешування, і обсяг порції даних ( чи буфер chunk - шматочок), з яких набирається кеш. У файлі System.ini є можливість у секції [VCACHE] прописати, наприклад, наступні значення:

[vcache]

MinFileCache = 4096

MaxFileCache = 32768

ChunkSize = 512

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

В інших ОС можна вквзувати більшепараметрів, що визначають роботу підсистеми кешування. Приклад, що демонструєці можливості, можна подивитися в розділі «Файловасистема HPFS».

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

· SSTF (shortest seek time — first) — з найменшим часом пошуку — першим. Відповідно до цієї дисципліни при позиціюванні магнітних голівок наступним вибирається запит, для якого необхідно мінімальне переміщення з циліндра на циліндр, навіть якщо цей запит не був першим у черзі на ввід/вивід. Однак для цієї дисципліни характерна різка дискримінація визначених запитів, але ж вони можуть йти від високопріоритетних задач. Звертання до диска виявляють тенденцію концентруватися, у результаті чого запити на звертання до самих зовнішніх і самих внутрішніх доріжок можуть обслуговуватися істотно довше і немає ніякої гарантії обслуговування. Достоїнством такої дисципліни є максимально можлива пропускна здатність дискової підсистеми.

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

· Next-Step Scan — відрізняється від попередньої дисципліни тим, що на кожнім проході обслуговуються тільки запити, що вже існували на момент початку проходу. Нові запити, що з'являються в процесі переміщення голівок читання/запису, формуютьнову чергу запитів, причому таким чином,щоб їх можна було оптимально обслужитина зворотному ходу.

· C-Scan (циклічне сканування). По цій дисципліні голівки переміщаються циклічно із самої зовнішньої доріжки до внутрішніх, але по шляху обслуговуючи наявні запити, після чого знову переносяться до зовнішніх циліндрів. Цю дисципліну іноді реалізують таким чином,щоб запити, що надходять під час поточного прямого ходу голівок, обслуговувалисяне попутно, а при наступному ході, що дозволяє виключити дискримінацію запитів до самих крайніх циліндрів; вона характеризується дуже малою дисперсією часу чекання обслуговування. Цю дисципліну обслуговуваннячасто називають «елеваторною».

Тема 10.Організація файлових систем.

1. Функції файлової системи ОС і ієрархія даних.

Читайте також:

1. Аналітична обробка інформації вузлами інформаційно-аналітичної функціональної підсистеми МОЗ України і питань НС.
2. Бухгалтерська обробка документів.
3. Введення інформації в ЕОМ та її обробка
4. Графоаналітична обробка даних при двох змінних факторах і лінійної залежності
5. Електроконтактна обробка
6. ІІ етап: Збір та обробка інформації.
7. Класифікація й обробка корпусних деталей.
8. Лекція 4. Товарна обробка плодів і овочів
9. Обробка (Finishing) 1
10. Обробка валів на токарних верстатах.
11. Обробка втулок.
12. Обробка даних багаторівневими драйверами

Переглядів: 1430