6409

Структура операційної системи

Контрольная

Информатика, кибернетика и программирование

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

Украинкский

2013-01-03

110.5 KB

9 чел.

Структура операційної системи

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

Монолітні системи

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

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

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

Така організація передбачає наступну базову структуру операційної системи:

1. Основна програма, яка викликає необхідну службову процедуру.

2. Набір службових процедур, що виконують системні виклики.

3. Набір допоміжних процедур, що сприяють роботі службових процедур.

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

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

Багаторівневі системи

Узагальненням підходу, показаного на рис.1.21, є організація операційної системи у вигляді ієрархії рівнів, кожен з яких є надбудовою над нижнім рівнем. Першою системою, побудованою таким чином, була система THE, створена в Technische Hogeschool Eindhoven в Голландії Е. Дейкстроєм і його студентами в 1968 році. Система THE була простою пакетної системою для голландського комп'ютера Electrologica Х8, що мав пам'ять 32К 27-розрядних слів. Як показано в табл.1, у системи було шість рівнів.

Таблиця 1. Структура операційної системи THE

Рівень

Функція

5

Оператор

4

Програми користувача

3

Управління введенням-виведенням

2

Зв'язок оператора з процесом

1

Управління основною пам'яттю і магнітним барабаном

0

Розподіл ресурсів процесора і забезпечення багатозадачного режиму

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

Рівень 1 управляв пам'яттю. Він виділяв процесам простір в основній пам'яті і на магнітному барабані ємністю 512К слів, який використовувався для зберігання частин процесу (сторінок), що не вміщалися в оперативній пам'яті. На рівнях вище першого процеси не повинні були турбуватися про те, де саме вони знаходяться, в пам'яті або на барабані; доставкою сторінок в пам'ять в міру потреби займалося програмне забезпечення рівня 1.

Рівень 2 керував зв'язком кожного процесу з консоллю оператора (тобто з користувачем). Над цим рівнем кожен процес фактично мав свою власну консоль оператора.

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

На рівні 4 працювали для користувача програми, яким не треба було дбати про процеси, пам'яті, консолі або управління вводом-виводом.

Процес системного оператора розміщувався на рівні 5.

Подальше узагальнення багаторівневої концепції було зроблено в системі MULTICS. Замість рівнів для опису MULTICS використовувалися серії концентричних кілець, де внутрішні кільця мали більш високі привілеї по відношенню до зовнішніх (що, власне, не змінювало суті багаторівневої системи). Коли процедурі з зовнішнього кільця потрібно викликати процедуру внутрішнього кільця, їй потрібно було створити еквівалент системного виклику, тобто виконати інструкцію TRAP, параметри якої ретельно перевірялися на допустимість перед тим, як вирішити продовження виклику. Хоча вся операційна система в MULTICS була частиною адресного простору кожного користувача процесу, апаратура дозволяла визначати окремі процедури (а фактично сегменти пам'яті) як захищені від читання, запису або виконання. Слід зазначити, що система рівнів в конструкції THE грала лише допоміжну роль, оскільки всі частини системи в кінцевому рахунку компонували разом в єдину виконувану програму, а в MULTICS кільцеподібний механізм головним чином існував в процесі виконання і реалізовувався за рахунок апаратного забезпечення. Переваги кільцеподібного механізму виявлялися в тому, що він міг бути легко розширений і на структуру користувальницьких підсистем. Наприклад, професор може написати програму для тестування та оцінки студентських програм і запустити цю програму в кільці n, а студентські програми будуть виконуватися в кільці n+ так що студенти не зможуть змінити свої оцінки.

Мікроядра

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

Різні дослідники визначали кількість помилок на 1000 рядків коду (наприклад, Basilli and Perricone, 1984; Ostrand and Weyuker, 2002). Щільність помилок залежить від розміру модуля, віку модуля та інших факторів, але приблизна цифра для солідних промислових систем - 10 помилок на 1000 рядків коду. Отже, монолітна операційна система, що складається з 5 000 000 рядків коду, швидше за все, містить близько 50 000 помилок ядра. Зрозуміло, не всі з них мають фатальний характер, деякі помилки можуть являти собою просто видачу неправильного повідомлення про помилку в тій ситуації, яка складається вкрай рідко. Проте операційні системи містять стільки помилок, що виробники комп'ютерів забезпечили свою продукцію кнопкою перезапуску (яка часто знаходиться на передній панелі), чого не роблять виробники телевізорів, стереосистем і автомобілів, незважаючи на великий обсяг програмного забезпечення, який є в цих пристроях.

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

Було розроблено і набуло поширення безліч різних мікроядер. Особливо часто вони використовуються в додатках, що працюють в реальному масштабі часу в промислових пристроях, авіоніці та військової техніки, які виконують особливо важливі завдання і повинні відповідати дуже високим вимогам надійності. Частина загальновідомих мікроядер представляють Integrity, К42, L4, PikeOS, QNX, Symbian і MINIX3.

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

Мікроядро MINIX 3 займає всього лише близько 3200 рядків коду на мові С і 800 рядків коду на асемблері, який використано для самих низькорівневих функцій, зокрема для перехоплення переривань і для перемикання процесів. Код на мові С займається управлінням і розподілом процесів, управляє взаємодією між процесами (шляхом обміну повідомленнями між процесами) і пропонує набір приблизно з 35 викликів ядра, дозволяючи працювати іншій частині операційної системи. Ці виклики виконують функції підключення обробників до переривань, переміщення даних між адресними просторами і встановлення нових схем розподілу пам'яті для щойно створених процесів. Структура процесу MINIX 3 показана на рис. 1.22, де обробники викликів ядра позначені як Sys. В ядрі також розміщений драйвер годин, тому що планувальник працює з ними в тісній взаємодії. Всі інші драйвери пристроїв працюють як окремі процеси користувача.

Рис. 1.22. Структура системи MINIX 3

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

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

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

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

Ідея, що має певне відношення до використання мінімального ядра, полягає в тому, щоб поміщати в ядро ​​виконавчий механізм, а не політику. Щоб пояснити цю думку, розглянемо планування виконання процесів. Відносно простий алгоритм планування полягає у призначенні кожному процесу пріоритету з наступним запуском ядром готового до виконання процесу з найвищим пріоритетом. Механізм, який знаходиться в ядрі, призначений для пошуку і запуску процесу з найбільшим пріоритетом. Політика, яка полягає у призначенні процесам пріоритетів, повинна бути реалізована процесами, що працюють в режимі користувача. Таким чином, політика і механізм можуть бути роз'єднані, а ядро ​​може бути зменшено в розмірах.

Клієнт-серверна модель

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

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

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

Рис. 1.23. Клієнт-серверна модель, реалізована за допомогою мережі

Стає все більше і більше систем, в яких користувачі сидять за домашніми комп'ютерами, в якості клієнтів, а великі машини, що працюють десь в іншому місці, – в якості серверів. Фактично за цією схемою працює велика частина Інтернету. Персональні комп'ютери відправляють запити на отримання веб-сторінки на сервер, і їм повертається ця веб-сторінка. Це типова картина використання клієнт-серверної моделі при роботі в мережі.

Віртуальні машини

Перші випуски OS/360 були системами виключно пакетної обробки. Але багато користувачів машин IBM/360 хотіли отримати можливість інтерактивної роботи з використанням терміналу, тому різні групи розробників як у самій корпорації IBM, так і за її межами вирішили написати для цієї машини системи з поділом часу. Пізніше була випущена офіційна система поділу часу - TSS/360, і коли вона нарешті дійшла до споживачів, то була настільки громіздкою і повільною, що під неї було переобладнано всього лише кілька обчислювальних центрів. В кінцевому підсумку від цього проекту відмовилися, після того як на нього вже було витрачено 50 млн доларів (Graham, 1970).

Група з наукового центру IBM Scientific Center в Кембриджі, Массачусетс, розробила абсолютно іншу систему, яку IBM в кінцевому підсумку прийняла як закінчений продукт. Ця система, спочатку називалася CP / CMS, а пізніше перейменована в VM/370 (Seawright and MacKinnon, 1979), була заснована на наступному проникливому спостереженні: система з поділом часу забезпечує 1) багатозадачність і 2) розширену машину з більш зручним інтерфейсом, ніж у простого устаткування. Сутність VM/370 полягає в повному розділенні цих двох функцій.

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

Рис. 1.24. Структура VM/370 з трьома запущеними системами CMS

Оскільки кожна віртуальна машина ідентична справжньому обладнанню, на кожній з них може працювати будь-яка операційна система, яка може бути запущена безпосередньо на самому обладнанні. На різних віртуальних машинах можуть бути запущені різні операційні системи, як це часто і відбувається насправді. Спочатку на системах VM/370 одні користувачі запускали в своїх віртуальних машинах OS/360 або одну з інших великих операційних систем пакетної обробки або обробки транзакцій, у той час як інші запускали однокористувацьку інтерактивну систему CMS (Conversational Monitor System - система діалогової обробки) для користувачів системи поділу часу.

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

У своєму сучасному переродженні z / VM зазвичай використовується для запуску кількох повноцінних операційних систем, а не спрощених, однокористувальницьких систем начебто CMS. Наприклад, на машинах zSeries можна запустити одну або кілька віртуальних машин Linux, а поряд з ними запустити звичайні операційні системи IBM.

Хоча в IBM віртуальні машини використовуються вже чотири десятиліття і ряд інших компаній, включаючи Sun Microsystems і Hewlett-Packard, нещодавно додали підтримку віртуальних машин до своїх високопродуктивним промисловим серверів, проте, за великим рахунком, ідея віртуалізації в світі персональних комп'ютерів до останнього часу практично ігнорувалася. Але останнім часом поєднання нових потреб, нового програмного забезпечення та нових технологій додало цій темі особливу актуальність.

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

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

Інший варіант використання віртуалізації призначений для кінцевих користувачів, яким необхідна можливість одночасного запуску двох або більше операційних систем, наприклад Windows і Linux, оскільки деякі з улюблених ними додатків працюють під управлінням тільки однієї, а деякі під керуванням тільки іншої операційної системи. Така ситуація показана на рис. 1.25, я, при цьому термін «монітор віртуальної машини» замінено на «гіпервізор першого типу» (type 1 hypervisor) відповідно до термінології останніх років.

Рис. 1.25. Гіпервізор, тип 1 (а). Гіпервізор, тип 2 (б)

Щоб запустити на комп'ютері програмне забезпечення віртуальних машин, його центральний процесор повинен бути готовий до роботи в цьому режимі (Popek and Goldberg, 1974). Проблема полягає в наступному. Коли операційна система, запущена на віртуальній машині (в режимі користувача) виконує привілейовані інструкції, наприклад зміна слова стану програми - PSW або здійснення операції введення-виведення, необхідно, щоб устаткування здійснило її перехоплення і виклик монітора віртуальних машин, який виконає програмну емуляцію даної інструкції . На деяких центральних процесорах, особливо на Pentium, його попередників і їх клонах, спроби виконання привілейованих інструкцій в режимі користувача просто ігноруються. Ця особливість виключає створення віртуальних машин на такому обладнанні, чим пояснюється недостатній інтерес до них у світі персональних комп'ютерів. Звичайно, існували інтерпретатори для Pentium, які запускалися на цьому процесорі, але при втраті продуктивності зазвичай в 5-10 раз вони не підходили для серйозної роботи.

У 90-х роках, завдяки ряду науково-дослідних проектів, особливо Disco в Стенфорді (Bugnion et al., 1997), ситуація змінилася, з'явилися комерційні продукти (наприклад, VMware Workstation) і інтерес до віртуальних машин знову пожвавився. VMware Workstation - це гіпервізор другого типу, показаний на рис. 1.25, б. На відміну від гіпервізора першого типу, який працює безпосередньо на реальному обладнанні, гіпервізор другого типу працюють як прикладні програми як надбудова над Windows, Linux або над якою-небудь іншою операційною системою, відомою як основна операційна система (host operating system). Після запуску гіпервізор другого типу зчитує інсталяційний компакт-диск для вибору і установки гостьової операційної системи на віртуальний диск, який є просто великим файлом у файловій системі основної операційної системи.

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

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

Віртуальна машина Java

Віртуальні машини використовуються – правда, дещо в інший спосіб - і в іншій області: для запуску програм мовою Java. Коли компанія Sun Microsystems винайшла мову програмування Java, вона також винайшла і віртуальну машину (тобто архітектуру комп'ютера), названу JVM (Java Virtual Machine - віртуальна машина Java). Компілятор Java створює код для JVM, який потім зазвичай виконується програмним інтерпретатором JVM. Перевага такого підходу полягає в тому, що код для JVM може доставлятися через Інтернет на будь-який комп'ютер, що має JVM-інтерпретатор, і запускатися на цьому комп'ютері. Іншою перевагою використання JVM є те, що при правильній реалізації інтерпретатора, що не є таким вже простим завданням, отримані JVM-програми можуть бути перевірені з точки зору безпеки, а потім виконані в захищеному середовищі, не маючи можливості викрасти дані або нанести будь-яку іншу шкоду.

Екзоядра

Замість клонування справжньої машини, як це робиться у віртуальних машинах, існує інша стратегія, яка полягає в їх поділі, іншими словами, в наданні кожному користувачеві підмножини ресурсів. При цьому одна віртуальна машина може отримати дискові блоки від 0 до 1023, друга може отримати блоки від 1024 до 2047, і т. д.

Самий нижній рівень, що працює в режимі ядра, - це програма під назвою екзоядро (Engler et al., 1995). Його завдання полягає у розподілі ресурсів між віртуальними машинами і потім у відстеженні спроб їх використання, щоб жодна з машин не намагалася використовувати чужі ресурси. Кожна віртуальна машина може запускати свою власну операційну систему, як на VM/370 і на Pentium в режимі віртуальних машин 8086, з тією відмінністю, що кожна машина обмежена використанням тих ресурсів, які вона запросила і які були їй надані.

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


 

А также другие работы, которые могут Вас заинтересовать

55071. Позакласне заняття. Весняні квіти з гофрованого паперу 34.5 KB
  Діти а для того щоб ви дізналися що ми будемо виготовляти сьогодні на занятті я вам пропоную відгадати загадки. Люблять її діти і дорослі за веселу пісеньку струмочків за дзвінкий спів птахів за ніжні проліски за м’який килим з шовкової травиці за ласкаве сонячне проміння за повітря напоєне запахом молодого листя. Діти тому сьогодні на занятті ми будемо виготовляти з паперу крокуси. Діти давайте повторимо послідовність нашої роботи.
55072. Письменники-лауреати Нобелівської премії 601 KB
  Мета: розповісти про засновника премії Альфреда Нобеля; ознайомити учнів з письменниками-лауреатами Нобелівської премії; сприяти перетворенню загальнолюдських цінностей в індивідуальний духовний досвід учнів; виховувати повагу до людської особистості, до скарбів культури; формувати гуманістичні ідеали добра.
55073. Інтелектуальне шоу «Брейн-ринг» 50 KB
  Мета: відновити в пам’яті учнів уявлення про фізичні та хвмвчні властивості хімічних речовин. Розвинути уміння працювати разом, розвинути логічне, творче мислення, увагу, пам’ять. Сформувати науковий світогляд. Виховати працелюбність, наполегливість, колективність в роботі, волю до подолання труднощів, повагу до думки іншого, інтерес до предмета.
55074. АНТРОПОНОМИНАНТЫ В РУССКОМ И ЧЕШСКОМ ЯЗЫКАХ: СЛОВООБРАЗОВАТЕЛЬНЫЙ АСПЕКТ 517 KB
  Определить критерии отбора антропономинантов; выделить из всех наименований лица антропономинанты со значением профессии, рода занятий, внешних и внутренних качеств человека; изучить словообразовательные способы и средства, по которым образуются наименования лица по профессии, роду занятий, по внешним и внутренним качествам человека;
55075. Исследование прав авторов и их гражданско-правовой защиты 439 KB
  Исследовать понятие авторского права и его компоненты, понятие исключительного права в контексте авторских прав, изучить проблему определения субъектов авторских прав в современной России, проанализировать вопрос определения объектов авторских прав как основополагающей правовой дефиниции при осуществлении авторских прав, дать анализ проблематике защиты имущественных прав авторов
55076. Т.Г.Шевченко – думи мої… думи… 68 KB
  Тарас Шевченко великий легендарний поет казкового краю художник-мислитель палкий захисник соціальних та національних інтересів українського народу великий борець за волю свого народу свого краю обстоював права українського народу на його вільний суверенний розвиток.
55077. Пізнай себе і ти пізнаєш світ 104.5 KB
  У кожної дитини є таланти і здібності тому задача педагога допомогти їй знайти їх у собі а знайшовши розвивати викликати бажання займатися самовихованням спонукати до саморозвитку допомагати учням у самовизначенні формувати його духовне обличчя утверджувати повагу до гідності й розуму людини...
55078. Создание презентации средствами Power Point. Презентация “Моя учебная неделя” 94 KB
  Создание презентации средствами Power Point. Актуализация опорных знаний построение алгоритма создания презентации. Игра правда неправда обсуждение возможностей редактирования разных объектов в презентации.
55079. Створення в автоматичному режимі макросів та їх використання 494 KB
  Мета: навчитися керувати інтерфейсом текстового процесора WORD, налаштовувати панелі інструментів, записувати макроси. Розвивати вміння та навички роботи з джерелом інформації, логічне мислення. Виховувати інформаційну культуру