РЕФЕРАТ На тему: Сучасні Операційні системи
1.ОС Unix 1.1. Історія і загальна характеристика UNIX зародився в лабораторії Bell Labs фірми AT&T більш 20 років тому. У той час Bell Labs займалася розробкою багатокористувальницької системи поділу часу MULTICS (Multiplexed Information and Computing Service) разом з MIT і General Electric. Денис Рітчі і деякі інші розробляли нову ФС, багато рис якої вели своє походження від MULTICS. Для перевірки нової ФС Томпсон написав ядро ОС і деякі програми для комп’ютера GE-645, що працював під керуванням мультипрограмної системи поділу часу GECOS. Виникла перша версія UNIX, хоча вона і не мала в той час ніякого назви. Але вона уже включала характерну для UNIX ФС, засновану на індексних дескрипторах inode, мала підсистему керування процесами і пам’яттю, а також дозволяла двом користувачам працювати в режимі поділу часу. Система була написана на ассемблері. Ім’я UNIX (Uniplex Information and Computing Services) було дано їй ще одним співробітником Bell Labs, Брайаном Керніганом, що спочатку назвав її UNICS, підкреслюючи її відмінність від багатокористувальницької MULTICS. Незабаром UNICS почали називати UNIX. Першими користувачами UNIX’а стали співробітники відділу патентів Bell Labs, що знайшли її зручним середовищем для створення текстів. Великий вплив на долю UNIX зробив перепис її мовою високого рівня З, розробленого Денисом Рітчі спеціально для цих цілей. Це відбулося в 1973 році, UNIX нараховував до цього часу вже 25 інсталяцій, і в Bell Labs була створена спеціальна група підтримки UNIX. Широке поширення UNIX одержав з 1974 року, після опису цієї системи Томпсоном і Рітчі в комп’ютерному журналі CACM. UNIX одержав широке поширення в університетах, тому що для них він поставлявся безкоштовно разом з вихідними кодами на С. Широке поширення ефективних C-компіляторів зробило UNIX унікальної для того часу ОС через можливість переносу на різні комп’ютери. Університети внесли значний вклад у поліпшення UNIX і подальшу його популяризацію. Ще одним кроком на шляху одержання визнання UNIX як стандартизованого середовища стала розробка Денисом Рітчі бібліотеки в/в stdio. Завдяки використанню цієї бібліотеки для компілятора З, програми для UNIX стали легко стерпними. Широке поширення UNIX породило проблему несумісності його численних версій. Очевидно, що для користувача дуже неприємний той факт, що пакет, куплений для однієї версії UNIX, відмовляється працювати на іншій версії UNIX. Періодично робилися і робляться спроби стандартизації UNIX, але вони поки що мали обмежений успіх. Процес зближення різних версій UNIX і їхньої розбіжності носить циклічний характер. Перед обличчям нової погрози з боку якої-небудь іншої ОС різні виробники UNIX-версій зближають свої продукти, але потім конкурентна боротьба змушує їх робити оригінальні поліпшення і версії знову розходяться. У цьому процесі є і позитивна сторона – поява нових ідей і засобів, що поліпшують як UNIX, так і багато інших ОС, що перейняли в нього за довгі роки його існування багато корисного. Незалежно від версії, загальними для UNIX рисами є: багатокористувацький режим із засобами захисту даних від несанкціонованого доступу, реалізація мультипрограмної обробки в режимі поділу часу, заснований на використанні алгоритмів витісняючої багатозадачності (preemptive multitasking), використання механізмів ВП і свопінгу для підвищення рівня мультипрограмування, уніфікація операцій в/в на основі розширеного використання поняття “файл”, ієрархічна ФС, що утворить єдине дерево каталогів незалежно від кількості фізичних пристроїв, використовуваних для розміщення файлів, перенесення на інші типи комп’ютерів системи за рахунок написання її основної частини мовою C, різноманітні засоби взаємодії процесів, у тому числі і через мережу, кешування диску для зменшення середнього часу доступу до файлів. 1.2. Управління процесами. Образ, дескриптор, контекст процесу. В основі UNIX лежить концепція процесу – одиниці керування й одиниці споживання ресурсів. Процес являє собою програму в стані виконання, причому в UNIX у рамках одного процесу не можуть виконуватися ніякі рівнобіжні дії. Кожен процес працює у своєму ВАП. Сукупність ділянок фізичної пам’яті, відображуваних на ВА процесу, називається образом процесу. При керуванні процесами ОС використовує два основних типи інформаційних структур: дескриптор процесу (структура proc) і контекст процесу (структура user). Дескриптор процесу містить таку інформацію про процес, що необхідна ядру протягом усього життєвого циклу процесу, незалежно від того, чи знаходиться він в активному чи пасивному стані, чи знаходиться образ процесу в ОП чи вивантаженій на диск. Дескриптори окремих процесів об’єднані в список, що утворить таблицю процесів. Пам’ять для таблиці процесів визначається динамічно в області ядра. На підставі інформації, що міститься в таблиці процесів, ОС здійснює планування і синхронізацію процесів. У дескрипторі прямо чи побічно (через покажчики на зв’язані з ним структури) міститься інформація про стан процесу, розташуванні образа процесу в ОП і на диску, про значення окремих складових пріоритету, а також його підсумкове значення – глобальний пріоритет, ідентифікатор користувача, що створив процес, інформація про родинні процеси, про події, здійснення яких очікує даний процес і деяка інша інформація. Контекст процесу містить менш оперативну, але більш об’ємну частину інформації про процес, необхідну для поновлення виконання процесу з перерваного місця: уміст регістрів процесора, коди помилок виконуваних процесором системних викликів, інформацію про усі відкриті даним процесом файлів і незавершені операції в/в (покажчики на структури file) і інші дані, що характеризують стан обчислювального середовища в момент переривання. Контекст, так само як і дескриптор процесу, доступний тільки програмам ядра, тобто знаходиться у ВАП ОС, однак він зберігається не в області ядра, а безпосередньо межує з образом процесу і переміщається разом з ним, якщо це необхідно, з ОП на диск. У UNIX для процесів передбачені два режими виконання: привілейований режим – “система” і звичайний режим – “користувач”. У режимі “користувач” заборонено виконання дій, зв’язаних з керуванням ресурсами системи, зокрема, коректування системних таблиць, керування зовнішніми пристроями, маскування переривань, обробка переривань. У режимі “система” виконуються програми ядра, а в режимі “користувач” – оболонка і ПП. При необхідності виконати привілейовані дії користувальницький процес звертається з запитом до ядра у формі так називаного системного виклику. У результаті системного виклику керування передається відповідній програмі ядра. З моменту початку виконання системного виклику процес вважається системним. Таким чином, той самий процес може знаходитися в користувацькій і системній фазах. Ці фази ніколи не виконуються одночасно. У даних версіях UNIX процес, що працює в режимі системи, не міг бути витиснутий іншим процесом. Через це організація ядра, що складає привілейовану загальну частину всіх процесів, спрощувалася, тому що усі функції ядра не були рентабельними. Однак, при цьому реактивність системи страждала – будь-який процес, навіть низькоприорітетний, ввійшовши в системну фазу, міг залишатися в ній як завгодно довго. Через цю властивість UNIX не міг використовуватися в якості ОС реального часу. У більш пізніх версіях, і в SVR4 у тому числі, організація ядра ускладнилася і процес можна витиснути й у системній фазі, але не в довільний момент часу, а тільки у визначені періоди його роботи, коли процес сам дозволяє це зробити установкою спеціального сигналу. 1.3. Зародження процесів Зародження процесів в системі UNIX відбувається таким способом. При створенні процесу будується образ нового процесу, що є точною копією образу вихідного процесу. Сегмент даних і сегмент стeку батька реально копіюються на нове місце, утворюючи сегменти даних і стеку сина. Процедурний сегмент копіюється тільки тоді, коли він нероздільний. В іншому випадку син стає ще одним процесом, що займає даний процедурний сегмент. Після виконання системного виклику fork обидва процеси продовжують виконання з одної і тої ж точки. Щоб процес міг опізнати, чи є він батьком чи сином, системний виклик fork повертає в якості свого значення в початковий процес ідентифікатор нового процесу, а в новий процес NULL. Типове розгалуження на мові C записується так: if( fork() ) { дії батька } else { дії сина } Ідентифікатор сина може бути присвоєний змінній, яка входить в контекст процесу-батька. Так як контекст процесу успадковується його потомками, то діти можуть узнати ідентифікатори своїх старших братів, таким чином сума знань успадковується при породженні і може бути розповсюджена між спорідненими процесами. успадковуються всі характеристики процесу, що містяться в контексті. На незалежності ідентифікатора процесу від виконуваної процесом програми побудований механізм, що дозволяє процесу прийти до виконання іншої програми за допомогою системного виклику exec. Таким чином в UNIX породження нового процесу відбувається в два етапи – спочатку створюється копія процесу-батька, а саме дублюється дескриптор, контекст і образ процесу. Потім у нового процесу проводиться заміна кодового сегмента на заданий. 1.4. Керування пам’яттю. Свопінг. У UNIX System V Release 4 реалізована сегментно-сторінкова модель пам’яті в її традиційному виді. Поряд з механізмом керування сторінками використовується і механізм свопінгу, коли на диск виштовхуються всі сторінки якого-небудь процесу. Свопінг застосовується в “передаварійних” ситуаціях, коли розмір вільної ОП зменшується до деякого заданого порога, так що робота всієї системи дуже ускладнюється. Маються наступні типи віртуальних сегментів: Текст (text) – містить коди команд модуля процесу, що виконується. Він звичайно позначається “тільки для читання”, так щоб ні сам процес, ні інші процеси не могли змінити його кодову частину. Текстовий сегмент може розділятися багатьма процесами, наприклад, усіма користувачами, що працюють з одним редактором. Дані (data) – містить дані, використані і модифіковані процесом під час виконання. До сегмента даних звичайно дозволяється мати доступ для читання і запису. На відміну від текстового сегмента, сегмент даних ніколи не розділяється іншими процесами. Стік (stack) – містить стек процесу. Він позначається доступним для читання і запису і, подібно сегменту даних, не може розділятися іншими процесами. Є ще два типи сегментів: Поділювана пам’ять (shared memory) – область пам’яті, доступна для читання і запису декільком процесам. Відображений файл (mapped file) – сегменти відображеного файлу використовуються для того, щоб відобразити частини файлів в адресний простір процесу, і використовувати стандартні механізми ОС керування ВП для прискорення доступу до файлів. Поле s_data дескриптора сегмента вказує на структуру даних segvn_dat, у якій міститься специфічна для сегмента інформація: type: ознака, чи є сегмент поділюваним чи особистим; vp і offset: покажчик на vnode файлу і зсув у цьому файлі, що задають адреса, починаючи з якої розташовані на диску дані цього сегмента; amp: покажчик на карту анонімних сторінок сегмента. Кожен сегмент має зв’язок з дисковим простором, на якому зберігаються дані, відображувані в даний сегмент ВАП. Це може бути файл чи частина файлу на диску, чи ж це може бути область свопінгу, що не є файлом. Сегмент чи код сегменту інціалізованих даних звичайно зв’язаний з файлом, у якому зберігається програма, що виконується. Під зв’язком з файлом розуміється відображення віртуального сегмента і його сторінок на визначену область диска, з якої завантажуються дані віртуальних сторінок сегмента при їхньому переміщенні в ОП, а також куди містяться дані при витисненні віртуальних сторінок на диск. Віртуальні сторінки, що були споконвічно узяті з визначеного файлу (який описується на рівні ядра структурою vnode), називаються vnode-сторінками, а сторінки, що з’явилися тільки при розгортанні процесу (а це звичайно сторінки чи стеки неініціалізованих сегментів даних) – анонімними сторінками. Однак анонімні сторінки також мають зв’язок з файлом, у який вони виштовхуються при їхньому витисненні з фізичної пам’яті (так названий свопінг-пристрій). На свопінг-пристрій також указує vnode, тому в цій якості може виступати будь-як файл, а переміщення сторінок зі свопінг-пристроїв в пам’ять здійснюється тими ж функціями, що використовуються для vnode-сторінок. Відображення віртуальних сторінок сегмента на фізичні задається за допомогою таблиці HAT (Hardware Address Translation), покажчик на який мається в структурі адресного простору процесу as. Структура таблиці HAT залежить від апаратної платформи, але в будь-якому випадку з її допомогою можна знайти таблицю чи таблиці сторінок, що містять дескриптори сторінок (структури типу pte). Дескриптор сторінки містить ознака наявності даної віртуальної сторінки у фізичній пам’яті, номер відповідної фізичної сторінки, а також ряд ознак типу “модифікація”, “було посилання”, що допомагають ОС планувати процес витиснення віртуальних сторінок на диск. У UNIX System V Release 4 використовується алгоритм переміщення віртуальних сторінок процесу у фізичну пам’ять по запиті. Звичайно при запуску процесу у фізичну пам’ять міститься тільки невелика частина сторінок, необхідна для старту процесу, а інші сторінки завантажуються при сторінкових збоях. Очевидно, що початковий період роботи будь-якого процесу породжує підвищене навантаження на систему. Якщо при пошуку ВА у відповідному дескрипторі виявляється ознака відсутності цієї сторінки у фізичній пам’яті, то відбувається сторінкове переривання, і ядро переміщає цю сторінку з диска у фізичну пам’ять. Для пошуку сторінки на диску використовується інформація зі структури s_data сегмента – або vnode і offset, якщо сторінка типу vnode, або інформація про розташування анонімної сторінки в області свопінгу за допомогою інформації про її розташування там по карті amp. Якщо у фізичній пам’яті недостатньо місця для розміщення викликаної процесом сторінки, то ОС вивантажує деякі сторінки на диск. Цей процес здійснюється спеціальним процесом ядра, “виштовхувачем сторінок”, що має в UNIX System V Release 4 ім’я pageout. Для ухвалення рішення про те, яку віртуальну сторінку потрібно перемістити на диск, процесу pageout потрібно мати інформацію про поточнИЙ стан. 2. Мікроядро Mach 2.1. Історія Mach Система Mach мала як попередницю систему RІ – Rochester Іntellіgent Gateway, початок розробки якої припав на 1975 рік. RІ була написана для 16-бітового міні-комп’ютера компанії DataGeneral за назвою Elіpce. Метою цієї розробки була демонстрація можливостей структурування ОС і представлення її у виді набору процесів, що можуть взаємодіяти між собою шляхом передачі повідомлень, у тому числі і по мережі. Потім ця ОС була поліпшена шляхом додавання засобів захисту і засобів прозорої роботи в мережі й одержала назву Accent (у 1981 році, в університеті Карнегі-Меллона). У 1984 році вона уже використовувалася на 150 комп’ютерах PERQ – ранніх графічних станціях, але програла змагання з UNіX’ом. Ця обставина спонукала створити третє покоління ОС, що використовує механізм обміну повідомленнями. Цей проект і був названий Mach. Крім сумісності з UNІХ, у Mach були введені й інші удосконалення, включаючи нитки, поліпшені механізми міжпроцесної взаємодії, підтримка багатопроцесорних систем, поліпшена ВП і ін. У цей час агентство DARPA шукало ОС для підтримки мультипроцесорів. Вибір був зроблений на користь університету Карнегі-Меллона, і роботи над ОС Mach були продовжені. Перша версія Mach була реалізована в 1986 році для VAX11/784, 4-х процесорної машини. Незабаром ця ОС була перенесена на ІBM PC RT і Sun 3. ДО 1987 року Mach виконувалася також на мультипроцесорах Encore і Sequent. Хоча Mach і мала мережеві засоби, її скоріше можна було віднести до ОС окремої машини чи мультипроцесора, а не до мережевої розподіленої прозорої системи. Незабаром була створена організація виробників комп’ютерів OSF (ІBM, DEC, Hewlett Packard) для того, щоб відібрати контроль над ОС UNІХ у її власника AT&T. Вони вибрали Mach 2.5 як основу для їхньої першої ОС OSF/1. У 1988 році ядро Mach 2.5 було великим і монолітним через те, що містило велику кількість коду Berkeley UNІ. А в 1989 році університет Карнегі-Меллона видалив весь код BSD UNІ з ядра і помістив його в користувацький простір. Те, що залишилося, було мікроядром, що складається з чистого коду Mach. Ця версія 3.0 і використовується як основа наступних версій OSF. 2.2. Мета Mach. ОС Mach значно змінилася з часу її першої реалізації у виді RІ. Мета проекту також змінилися згодом . На сучасний момент основні цілі виглядають так: 1. Забезпечення базових функцій для створення інших ОС (наприклад, UNІХ). 2. Підтримка великих розріджених адресних просторів. 3. Забезпечення прозорого доступу до мережевих ресурсів. 4. Підтримка паралелізму як у системі, так і в додатках. 5. Забезпечення переносності Mach на різні типи комп’ютерів. 2.3. Основні концепції Mach Мікроядро Mach було розроблено як основу, на базі якої можна емулювати UNІХ і інші ОС. Ця емуляція здійснюється програмним рівнем, що працює поза ядром, у користувацькому просторі. Ядро Mach, подібно іншим мікроядрам, забезпечує керування процесами, керування пам’яттю, комунікації і функції в/в. Функції керування файлами, каталогами й інші традиційні для ОС функції виконуються в користувацькому просторі. Ідея побудови ядра Mach складається в забезпеченні механізмів, необхідних для роботи системи, але стратегія використання цих механізмів реалізується на рівні користувацьких процесів. Ядро керує п’ятьма головними абстракціями: 1. Процеси. 2. Нитки . 3. Об’єкти пам’яті. 4. Порти. 5. Повідомлення. Користувацький процес користувацький простір Рівень програмних емуляторів простір ядра Рис. 46. Абстрактна модель емуляції UNІХ на основі Mach 2.4. Керування процесами в Mach Процес у Mach – це, у першу чергу, адресний простір і набір ниток, що виконуються в цьому адресному просторі. Таким чином, виконання зв’язане з нитками, а процеси є пасивними об’єктами і служать для збору всіх ресурсів, що використовуються групою взаємозалежних ниток, у зручні контейнери.
Інші параметри процесу Рис. 46. Процес Mach Малюнок 46 ілюструє процес у Mach. Крім адресного простору і ниток, процес характеризується використовуваними ними портами і деякими параметрами. Усі порти, показані на малюнку, мають спеціальне призначення. Порт процесу використовується для взаємодії з ядром. Багато функцій ядра процес може викликати шляхом відправлення повідомлення на порт процесу, а не за допомогою системного виклику. Цей механізм використовується в Mach усюди для зменшення кількості системних викликів до можливого мінімуму. Взагалі говорячи, програміст може навіть не знати, чи виконується сервіс за допомогою системного виклику чи ні. Усім сервісам, які викликаються як за допомогою системних викликів, так і за допомогою передачі повідомлень, відповідають ерзац-процедури (заглушки) у бібліотеці. Це саме ті процедури, що описані в посібниках і які викликаються ПП. Ці процедури генеруються на підставі опису сервісу за допомогою компілятора MІG (Mach Іnterface Generator). Порт завантаження використовується при ініціалізації, коли система стартує. Найперший процес читає з порту завантаження, щоб довідатися імена портів ядра, що забезпечують найбільш важливі сервіси. Порт особливих ситуацій використовується системою для передачі повідомлень про помилки процесу. Прикладами особливих ситуацій є ділення на нуль, неправильний код команди. Цей порт також використовують відладчики. Зареєстровані порти звичайно використовуються для забезпечення можливостей взаємодії між процесами і стандартними системними серверами. Процеси також володіють і іншими властивостями. Процес може бути виконуваним чи заблокованим, незалежно від стану його ниток. Якщо процес є виконуваним, то ті його нитки, що також готові до виконання, можуть плануватися і виконуватися. Якщо процес заблокований, то всі його нитки не можуть виконуватися незалежно від їхнього стану. Параметри планування, крім ниток, визначаються також для процесів. Ці параметри включають можливість визначення того, на яких процесорах можуть виконуватися нитки даного процесу. Це властивість найбільш корисна для багатопроцесорних систем. Наприклад, процес може використовувати цю властивість для того, щоб змусити виконуватися нитку на різних процесорах, чи змусити всі нитки працювати на одному процесорі, чи реалізувати який-небудь проміжний варіант. Крім того, кожен процес має пріоритет, який можна встановлювати. При створенні нитки їй привласнюється цей пріоритет. Також є можливість змінювати пріоритет всіх існуючих ниток. Нарешті, кожен процес має статистику, наприклад, про кількість використовуваної пам’яті, час виконання ниток і т.д. Будь-який інший процес, що цікавиться цією статистикою, може отримати її, пославши повідомлення на порт даного процесу. Процес Mach не містить: ідентифікатора користувача, груповий ідентифікатор, маску сигналів, кореневий каталог, робочий каталог, масив дескрипторів файлів. Уся ця інформація міститься в параметрах процесу на рівні сервера користувацького режиму. Примітиви керування процесами Mach передбачає невелику кількість примітивів керування процесами. Більшість з них виконується шляхом посилки повідомлення ядру через порт процесу. Найбільш важливі з цих викликів приведені в таблиці 3. Таблия 3. Виклик Опис Create Створює новий процес, що успадковує деякої властивості Termіnate Завершує визначений процес Suspend Нарощує лічильник припинень Resume Зменшує лічильник припинень; якщо він дорівнює 0, то розблокує процес Prіorіty Встановлює пріоритет для існуючих чи майбутніх ниток Assіgn Говорить, на якому процесорі повинні виконуватися нові нитки Іnfo Повертає інформацію про час виконання, використовуваної пам’яті і т.д. Threads Повертає список ниток процесу Процеси можуть бути припинені і відновлені за допомогою програмного керування. Кожен процес має лічильник, нарощуваний викликом Suspend і зменшуваний викликом Resume, що можуть блокувати і розблокувати його. Коли лічильник дорівнює 0, то процес може виконуватися. Наявність лічильника дозволяє уникнути проблем. Виклики Prіorіty і Assіgn дозволяють програмісту керувати тим, як і де нитки виконуються в багатопроцесорній системі. Планування CPU виконується на основі пріоритетів, так що програміст може визначати, які нитки більш важливі, а які – менш важливі. Нитки Активними об’єктами в Mach є нитки. Усі нитки процесу розділяють один адресний простір і мають загальні в межах процесу ресурси (рис. 46). Крім того, кожна нитка має і свої особливі ресурси. Одним з таких ресурсів є порт нитки, що є аналогом порту процесу і який використовується ниткою для того, щоб викликати спеціальні, орієнтовані на нитці, сервіси ядра, наприклад, функцію завершення нитки. Тому що порти є загальними ресурсами для всіх ниток одного процесу, кожна нитка має доступ до портів своїх ниток-братів, у такий спосіб кожна нитка може керувати іншою ниткою, якщо це необхідно. Нитки Mach керуються ядром, тобто вони є тим, що іноді називають “великоваговими” нитками, на відміну від “легковагих” ниток (ниток, що цілком виконуються в користувацькому просторі). Створення і знищення ниток здійснюється ядром і включає відновлення структур дані ядра. Нитки ядра надають базові механізми для керування безліччю “активностей” у загальному адресному просторі. Що робити з цими механізмами – це справа користувача. Рис. 47. Варіанти реалізацій З-ниток (а) – Усі C-нитки використовують одну нитку ядра; (б) – Кожна C-нитка має свою власну нитку ядра; (в) – Кожна C-нитка має свій власний однонитковий процес 2.4.1. Реалізація З-ниток у Mach У Mach існує кілька реалізацій 3-ниток. Оригінальна реалізація виконує всі нитки в користувацькому просторі усередині одного процесу. Цей підхід заснований на поділі в часі всіма 3-нитками однієї нитки ядра, як це показано на малюнку 47,а. Цей підхід може також використовуватися в UNіX’і чи будь-якій іншій системі, у якій немає підтримки ниток ядром. Такі нитки працюють як різні підпрограми однієї програми, що означає, що вони плануються образом, що невитісняє. Наприклад, у випадку типової задачі “виробник-покупець” виробник повинний заповнити буфер, а потім заблокуватися, щоб дати шанс покупцю на виконання. Дана реалізація має недолік, властивий усім нитковим пакетам, що працюють у користувацькому просторі без підтримки ядра. Якщо одна нитка виконує системний виклик, що блокує, наприклад, читання з термінала, то блокується весь процес. Щоб уникнути цієї ситуації, програміст повинен уникати використовувати системні виклики, що блокують. Друга реалізація використовує одну Mach-нитку для однієї 3-нитки, як показано на малюнку 47, б. Ці нитки плануються з витісненням. У багатопроцесорних системах нитки можуть дійсно працювати паралельно на різних процесорах. Фактично можливо мультиплексуваня m користувацьких ниток з n нитками ядра, хоча найбільш загальним випадкам є n=m. У третій реалізації для кожного процесу виділяється одна нитка ядра, як показано на малюнку 47, в. Процеси реалізуються так, що їхні адресні простори відображаються в ту саму фізичну пам’ять, дозволяючи розділяти її тим же способом, що й у попередніх реалізаціях. Даний спосіб підтримки ниток використовується тільки тоді, коли потрібно спеціалізоване використання ВП. Недоліком цього методу є те, що порти, UNіX-файли й інші ресурси процесу не можуть розділятися. Основне практичне значення першого підходу полягає в тому, що в умовах відсутності щирого паралелізму послідовне виконання нитки дозволяє відтворювати проміжні результати, полегшуючи процес налагодження. 2.5. Керування пам’яттю в Mach Ядро Mach має потужну, ретельно розроблену і найвищою мірою гнучку систему керування пам’яттю, засновану на сторінковому механізмі і яка має багато своєрідних властивостей. Зокрема, у ній машинно-залежна частина коду відділена від машинно-незалежної частини надзвичайно ясним і незвичайним способом. Цей поділ робить керування пам’яттю більш мобільним, ніж в інших системах. Крім того, система керування пам’яттю тісно взаємодіє з комунікаційною системою. Однієї з основних особливостей системи керування пам’яттю Mach є те, що її код розбитий на три частини. Перша частина називається pmap, що працює в ядрі і займається роботою з пристроєм відображення ВА у фізичні (Memory Management Unіt, MMU). Ця частина встановлює значення регістрів MMU і апаратних сторінкових таблиць, а також перехоплює всі сторінкові переривання. Ця частина коду залежить від архітектури MMU і повинна бути переписана для кожної нової машини кожний раз, коли Mach на неї переноситься. Друга частина – це машинно-незалежний код ядра, і він зв’язаний з обробкою сторінкових збоїв, керує відображенням областей пам’яті і заміною сторінок. Третя частина коду працює в користувацькому просторі як процес, називаного “менеджер пам’яті” (memory manager) чи іноді “зовнішній менеджер сторінок” (external pager). Ця частина має справу з логічними аспектами (на відміну від фізичних) системи керування пам’яттю, в основному, з керуванням збереження образів пам’яті на диску. Наприклад, менеджер пам’яті відслідковує інформацію про те, які віртуальні сторінки використовуються, які знаходяться в ОП і де вони зберігаються на диску, коли не знаходяться в ОП. Ядро і менеджер пам’яті взаємодіють за допомогою добре визначеного протоколу, що дає можливість для користувачів ядра Mach писати свої власні менеджери пам’яті. Такий поділ обов’язків дозволяє реалізовувати сторінкові системи спеціального призначення. При цьому ядро стає потенційно менше і простіше, тому що значна частина коду працює в користувацькому просторі. З іншого боку, це і джерело ускладнення ядра, тому що при цьому воно повинно захищати себе від помилок некоректної роботи менеджера пам’яті. Крім того, при наявності двох активних частин системи керування пам’яттю можливе виникнення конфліктів між ними. 2.5.1. Віртуальна пам’ять Концептуально модель пам’яті в Mach виглядає для користувацьких процесів у виді великого лінійного ВАП. Для більшості 32-х розрядних процесорів адресний простір займає діапазон від 0 до 232 – 1 (4 Гбайта). Адресний простір підтримується сторінковим механізмом. Mach забезпечує дуже тонке керування механізмом використання віртуальних сторінок (для тих процесів, що цікавляться цим). Для початку скажемо про те, що адресний простір може використовуватися розрідженим способом. Наприклад, процес може мати дюжину секцій ВАП, кожна з який знаходиться на відстані сотень Мбайт від найближчого сусіда, з великими зазорами не використовуваного адресного простору між цими секціями. Теоретично будь-який ВАП може бути розрідженим, так що здатність використовувати велику кількість розкиданих секцій не є в дійсності властивістю архітектури ВП. Іншими словами, будь-яка 32-х бітна машина повинна дозволяти процесу мати 50 000 секцій даних, розділених проміжками по 100 Мбайт, у межах від 0 до 4 Гбайт. Однак, у багатьох реалізаціях лінійна сторінкова таблиця від 0 до самої старшої використовуваної сторінки зберігається в пам’яті ядра. На машині з розміром сторінки в 1 Kб ця конфігурація вимагає 4 мільйони елементів таблиці сторінок, роблячи таку схему дуже дорогою, якщо не неможливою. Навіть при багаторівневій організації сторінкової таблиці така розрідженість у кращому випадку неприйнятна. У ядрі Mach при його розробці споконвічно ставилася задача повної підтримки розріджених адресних просторів. Для того, щоб визначити, які ВА використовуються, а які ні, Mach забезпечує спосіб призначення і скасування секцій ВАП, називаних областями (regіons). У виклику для призначення області можна визначити базові адреса і розмір, і область виділяється там, де це зазначено. В іншому випадку може бути заданий тільки розмір області, а система сама знаходить придатний діапазон адрес і повертає базову адресу. ВА є дійсним тільки в тому випадку, коли він попадає в призначений діапазон. Спроба використовувати адресу з проміжків між призначеними областями викликає переривання, що може бути перехоплено самим процесом, якщо він цього побажає. Ключовим поняттям, зв’язаним з використанням ВАП, є об’єкт пам’яті (memory object). Об’єкт пам’яті може бути чи сторінкою набором сторінок, а також може бути файлом чи іншою, більш спеціальною, структурою даних, наприклад, записом бази даних. Об’єкт пам’яті може бути відображений у не використовувану частину ВАП, формуючи нову область. Коли файл відображений у ВАП, то його можна читати, в нього можна писати за допомогою звичайних машинних команд. Відображені (mapped) файли посторінково витісняються з пам’яті звичайним чином. Коли процес завершується, то його відображені в пам’ять файли автоматично повертаються у ФС разом із усіма змінами, що відбулися з їхнім змістом у той час, коли вони були відображені в пам’ять. Також можливо скасувати відображення файлу чи іншого об’єкта пам’яті, звільняючи його адресний простір і роблячи його доступним для послідовного його розподілу чи відображення. Звичайно, відображення файлів у пам’ять не єдиний спосіб доступу до них. Їхній уміст можна читати і звичайним способом. Однак і в цьому випадку бібліотечні функції можуть відображати файли в пам’ять крім бажання користувача, а не використовувати систему в/в. Такий спосіб дозволяє сторінкам файлів використовувати систему ВП, а не спеціально виділені буфери де-небудь у системі. 2.6. Комунікації в ядрі Mach Основною метою, що ставили перед собою розроблювачі засобів комунікації ядра Mach, була підтримка різних стилів комунікацій у сполученні з надійністю і гнучкістю. Комунікаційні засоби ядра Mach можуть підтримувати асинхронну передачу повідомлень, RPC, потоки байт (streams), а також інші способи. Механізм взаємодії процесів Mach базується на відповідних механізмах своїх попередників – RІ і Accent. Через свій еволюційний розвиток цей механізм пристосований більше для локального використання, а не для розподілених систем. Спочатку розглянемо випадок одного вузла, а потім розширимо його для мережі. Слід зазначити, що мультипроцесор – це теж один вузол, тому взаємодія процесів, що працюють на різних процесорах багатопроцесорної машини, також відноситься до локального випадку. 2.6.1. Порти Основою всіх комунікацій у Mach є структура даних ядра, яку називають портом. У сутності порт являє собою захищену поштову скриньку. Коли нитка одного процесу хоче взаємодіяти з ниткою іншого процесу, то нитка-відправник записує повідомлення в такий порт, а нитка-одержувач витягає його відтіля. Кожен порт має засоби захисту, що гарантують, що тільки процеси, що мають відповідні права, можуть передавати й одержувати через нього повідомлення. Порт підтримує взаємодію подібно конвеєрам (pіpes) у UNІХ. Порт, що може бути використаний для відправлення запиту від клієнта серверу, не може використовуватися для відпра