Управління пам'яттю в Mach
Ядро Mach має потужну, ретельно розроблену і найвищою мірою гнучку систему управління пам'яттю, засновану на сторінковому механізмі і володіє багатьма рідкісними властивостями. Зокрема, в ньому машинно-залежна частина коду відділена від машинно-незалежної частини надзвичайно ясним і незвичайним способом. Це поділ робить управління пам'яттю більш мобільним, ніж в інших системах. Крім того, система управління пам'яттю тісно взаємодіє з комунікаційною системою.
Однією з основних особливостей системи управління пам'яттю Mach є те, що її код розбитий на три частини. Перша частина називається pmap, який працює в ядрі і займається роботою з пристроєм відображення віртуальних адрес в фізичні (Memory Management Unit, MMU). Ця частина встановлює значення регістрів MMU і апаратних сторінкових таблиць, а також перехоплює все сторінкові переривання. Ця частина коду залежить від архітектури MMU і повинна бути переписана для кожної нової машини щоразу, коли Mach на неї переноситься. Друга частина - це машинно-незалежний код ядра, і він пов'язаний з обробкою сторінкових збоїв, управляє відображенням областей пам'яті і заміною сторінок.
Третя частина коду працює в просторі користувача в якості процесу, званого "менеджер пам'яті" (memory manager) або іноді "зовнішній менеджер сторінок" (external pager). Ця частина має справу з логічними аспектами (на відміну від фізичних) системи управління пам'яттю, в основному, з управлінням збереження образів пам'яті на диску. Наприклад, менеджер пам'яті відстежує інформацію про те, які віртуальні сторінки використовуються, які знаходяться в оперативній пам'яті і де вони зберігаються на диску, коли не знаходяться в оперативній пам'яті. Ядро і менеджер пам'яті взаємодіють за допомогою добре певного протоколу, що дає можливість для користувачів ядра Mach писати свої власні менеджери пам'яті. Такий поділ обов'язків дозволяє реалізовувати сторінкові системи спецмулистих призначення. При цьому ядро стає потенційно менше і простіше, так як значна частина коду працює в просторі користувача. З іншого боку, це і джерело ускладнення ядра, так як при цьому воно повинно захищати себе від помилок або некоректної роботи менеджера пам'яті. Крім того, при наявності двох активних частин системи управління пам'яттю можливе виникнення гонок між ними.
Віртуальна пам'ять
Концептуально модель пам'яті в Mach виглядає для користувача процесів у вигляді великого лінійного віртуального адресного простору. Для більшості 32-х розрядних процесорів адресний простір займає діапазон від 0 до 232 - 1 (4 Гбайта). Адресний простір підтримується сторінковим механізмом.
Mach забезпечує дуже тонке управління механізмом використання віртуальних сторінок (для тих процесів, які цікавляться цим). Для початку скажемо про те, що адресний простір може використовуватися розрідженим способом. Наприклад, процес може мати дюжину секцій ВАП, кожна з яких знаходиться на відстані сотень мегабайт від найближчого сусіда, з великими проміжками невикористаного адресного простору між цими секціями.
Теоретично будь-який ВАП може бути розрідженим, так що здатність використовувати велику кількість розкиданих секцій не є в дійсності властивістю архітектури віртуальної пам'яті. Іншими словами, будь-яка 32-х бітна машина повинна дозволяти процесу мати 50 000 секцій даних, розділених проміжками по 100 Мбайт, в межах від 0 до 4 Гбайт. Однак, у багатьох реалізаціях лінійна сторінкова таблиця від 0 до самої старшої використовуваної сторінки зберігається в пам'яті ядра. На машині з розміром сторінки в 1 Kб ця конфігурація вимагає 4 мільйони елементів таблиці сторінок, роблячи таку схему дуже дорогою, якщо не неможливою. Навіть при багаторівневої організації сторінкової таблиці така розрідженість в кращому випадку неприйнятна. В ядрі Mach при його розробці спочатку ставилося завдання повної підтримки розріджених адресних просторів.
Для того, щоб визначити, які віртуальні адреси використовуються, а які ні, Mach забезпечує спосіб призначення і скасування секцій ВАП, званих областями (regions). У виклику для призначення області можна визначити базовий адреса і розмір, і область виділяється там, де це зазначено. В іншому випадку може бути заданий тільки розмір області, а система сама знаходить відповідний діапазон адрес і повертає базовий адреса. Віртуальний адреса є дійсним тільки в тому випадку, коли він потрапляє в призначений діапазон. Спроба використовувати адресу з проміжків між призначеними областями викликає переривання, яке може бути перехоплено самим процесом, якщо він цього побажає.
Мал. 6.5. Адресний простір з призначеними областями,
відображеними об'єктами і невикористовуваними адресами
Ключовим поняттям, пов'язаним з використанням віртуального адресного простору, є об'єкт пам'яті (memory object). Об'єкт пам'яті може бути сторінкою або набором сторінок, а також може бути файлом або інший, більш спеціальної, структурою даних, наприклад, записом бази даних. Об'єкт пам'яті може бути відображений в невикористану частину віртуального адресного простору, формуючи нову область, як це показано на малюнку 6.5. Коли файл відображений у ВАП, то його можна читати або в нього можна писати за допомогою звичайних машинних команд. Відображені (mapped) файли посторінково витісняються з пам'яті звичайним чином. Коли процес завершується, то його відображені в пам'ять файли автоматично повертаються в файлову систему разом з усіма змінами, що відбулися з їх утриманням у той час, коли вони були відображені в пам'ять. Також можливо скасувати відображення файлу або іншого об'єкта пам'яті, звільняючи його адресний простір і роблячи його доступним для послідовного його розподілу або відображення.
Звичайно, відображення файлів в пам'ять не єдиний спосіб доступу до них. Їх вміст можна читати і звичайним способом. Однак і в цьому випадку бібліотечні функції можуть відображати файли в пам'ять крім бажання користувача, а не використовувати систему введення-виведення. Такий спосіб дозволяє сторінкам файлів використовувати систему віртуальної пам'яті, а не спеціально виділені буфера де-небудь в системі.
Mach підтримує деяку кількість викликів для роботи з віртуальним адресним простором. Основні наведені в таблиці 6.3. Вони не є істинними системними викликами. Замість цього всі вони використовують запис повідомлення в порт процесу для виклику відповідних функцій ядра.
Таблиця 6.3.
Примітиви для управління віртуальним адресним простором
Allocate Робить область віртуального адресного простору використовуваної Deallocate Звільняє область віртуального адресного простору Map Показує об'єкт пам'яті у віртуальний простір Copy Копіює область в інший діапазон віртуальних адрес Inherit Встановлює атрибут успадкування для області Read Читає дані з адресного простору іншого процесу Write Записує дані в адресний простір іншого процесу
Перший виклик, Allocate, робить область віртуальних адрес використовуваної. Процес може успадковувати призначений адресний простір, а може і призначити додаткове, але будь-яка спроба звернутися до непризначення адресою викликатиме помилку. Другий виклик, D eallocate, звільняє область (тобто видаляє її з карти пам'яті), що дає можливість призначити її заново або відобразити що-небудь в неї, використовуючи виклик M ap.
Виклик C opy копіює об'єкт пам'яті в нову область. Оригінальна область залишається незмінною. Операція C opy виконується оптимізованим способом з використанням поділюваних сторінок, щоб уникнути фізичного копіювання.
Виклик Inherit впливає на спосіб успадкування областю властивостей при створенні нового процесу. Адресний простір може бути налаштоване так, що деякі області будуть успадковувати властивості, а деякі ні. Це буде обговорюватися нижче.
Виклики Read і Write дозволяють нитки отримати доступ до віртуальної пам'яті, що відноситься до іншого процесу. Ці виклики вимагають, щоб викликає нитка мала права доступу до порту іншого процесу, які процес може надати, якщо захоче цього.
На додаток до викликів, перерахованим в таблиці 6.3, існує кілька інших. Ці виклики пов'язані, в основному, з установкою і читанням атрибутів, режимами захисту і різними видами статистичної інформації.
поділ пам'яті
Поділ грає важливу роль в Mach. Для поділу об'єктів нитками одного процесу ніяких спеціальних механізмів не потрібно: всі вони автоматично бачать одне й те саме адресний простір. Якщо одна з них має доступ до частини даних, то і все його мають. Більш цікавою є можливість розділяти двома або більше процесами одні і ті ж об'єкти пам'яті, або ж просто розділяти сторінки пам'яті для цієї мети. Іноді поділ корисно в системах з одним процесором. Наприклад, у класичній задачі виробник-споживач може бути бажаним реалізувати виробника і споживача різними процесами, але мати загальний буфер, в який виробник міг би писати, а споживач - брати з нього дані.
У багатопроцесорних системах поділ об'єктів між процесами часто більш важливо, ніж в однопроцесорних. У багатьох випадках завдання вирішується за рахунок роботи взаємодіючих процесів, які працюють паралельно на різних процесорах (на відміну від поділу в часі одного процесора). Цим процесам може знадобитися безперервний доступ до буферам, таблицями або іншим структурам даних, для того, щоб виконати свою роботу. Істотно, щоб ОС дозволяла такий вид поділу. Ранні версії UNIX'а не надавали такої можливості, хоча потім вона була додана.
Розглянемо, наприклад, систему, яка аналізує оцифровані супутникові зображення Землі в реальному масштабі часу, в тому темпі, в якому вони передаються з супутника. Такий аналіз вимагає великих витрат часу, і одне і те ж зображення може перевірятися на можливість його використання в прогнозі погоди, врожаю або відстеження забруднення середовища. Кожне отримане зображення зберігається як файл.
Для проведення такого аналізу можна використовувати мультипроцессор. Так як метеорологічні, сільськогосподарські та екологічні програми дуже відрізняються один від одного і розробляються різними фахівцями, то немає причин робити їх нитками одного процесу. Замість цього кожна програма є окремим процесом, який відображає поточний знімок в свій адресний простір, як показано на малюнку 6.6. Зауважимо, що файл, який містить знімок, може бути відображений в різні віртуальні адреси в кожному процесі. Хоча кожна сторінка тільки один раз присутній в пам'яті, вона може виявитися в картах сторінок різних процесів в різних місцях. За допомогою такого способу все три процеси можуть працювати над одним і тим же файлом в один і той же час.
Іншою важливою областю разделяемості є створення процесів. Як і в Unix'е, в Mach основним способом створення нового процесу є копіювання існуючого процесу. У Unix'е копія завжди є двійником процесу, який виконав системний виклик FORK в той час як в Mach нащадок може бути двійником іншого процесу (прототипу).
Одним із способів створення процесу-нащадка складається в копіюванні всіх необхідних сторінок і відображення копій в адресний простір нащадка. Хоча цей спосіб і працює, але він необгрунтовано доріг. Коди програми зазвичай використовуються в режимі тільки-для-читання, так що їх не можна змінювати, частина даних також може використовуватися в цьому режимі. Сторінки з режимом тільки-для-читання немає необхідності копіювати, так як відображення їх в адресні простори обох процесів виконає необхідну роботу. Сторінки, в які можна писати, не завжди можуть розділятися, так як семантика створення процесу (принаймні в UNIX) говорить, що хоча в момент створення батьківський процес і процес-нащадок ідентичні, послідовні зміни в будь-якому з них невидимі в іншому адресному просторі .
Крім цього, деякі області (наприклад, певні відображені файли) можуть не знадобитися процесу-нащадка. Навіщо зв'язуватися з масою турбот, пов'язаних з відображенням, якщо ці області просто не потрібні?
Мал. 6.6. Три процесу, що розділяють відображений файл
Для забезпечення гнучкості Mach дозволяє процесу призначити атрибут успадкування кожної області в адресному просторі. Різні області можуть мати різні значення атрибута. Передбачено три значення атрибута:
- Область не використовується в процесі-нащадку.
- Область поділяється між процесом-прототипом і нащадком.
- Область в процесі-нащадку є копією прототипу.
Якщо область має перше значення, то в процесі-нащадку вона відсутня. Посилання на неї розглядаються як і будь-які інші посилання на непризначення процесу пам'ять - вони викликають переривання. Нащадок може призначити цю область для своїх власних цілей, або відобразити в неї об'єкт пам'яті.
Другий варіант являє собою справжнє поділ пам'яті. Сторінки області присутні як в адресному просторі прототипу, так і нащадка. Зміни, зроблені в одному просторі, видно в іншому. Цей варіант не використовується при реалізації системного виклику FORK, але часто буває корисний для інших цілей.
Третя можливість - копіювання всіх сторінок області та відображення копій в адресний простір нащадка. FORK використовує цей варіант. Насправді Mach не виконує реального копіювання сторінок, а використовує замість цього стратегію, яка називається копіювання-прі-записи (copy-on-write). Вона полягає в тому, що всі необхідні сторінки поміщаються в карту віртуальної пам'яті нащадка, але позначаються при цьому як призначені тільки для читання, як це показано на малюнку 6.7. Поки нащадок тільки читає з цих сторінок, все працює чудово.
Однак, якщо нащадок намагається писати в одну з цих сторінок, відбувається переривання по захисту пам'яті. Потім операційна система робить копію цієї сторінки і відображає копію в адресний простір нащадка, замінюючи їй захищену від запису сторінку. Нова сторінка позначається як доступна для читання і запису. На малюнку 6.7, б нащадок намагається зробити запис в сторінку 7. Ця дія призводить до того, що сторінка 7 копіюється в сторінку 8, а сторінка 8 відбивається в адресний простір замість сторінки 7. Сторінка 8 позначається для читання і запису, так що запис в неї не викличе переривання.
Мал. 6.7. Операція "копіювання-прі-записи"
а - після виклику FORK всі сторінки нащадка позначаються "тільки-для-читання"
б - при запису нащадка в сторінку 7 робиться її копія
Механізм копіювання-прі-записи має кілька переваг у порівнянні зі способом прямого копіювання всіх сторінок в момент створення нового процесу. По-перше, деякі сторінки мають режим тільки-для-читання, тому в їх копіюванні немає необхідності. По-друге, до інших сторінок звернень може ніколи і не бути, тому, хоча потенційно в них може проводитися запис, копіювати їх також не потрібно. По-третє, хоча деякі сторінки і доступні для запису, але процес-нащадок може видалити їх зі свого адресного простору, не використавши. Тому при використанні описаного механізму копіюються тільки ті сторінки, копіювання яких необхідно.
Механізм копіювання-прі-записи володіє і недоліками. З одного боку, він вимагає більш складного адміністрування, так як система повинна зберігати інформацію про те, які сторінки дійсно захищені від запису (так що звернення до них є помилкою), а які потрібно копіювати під час запису. З іншого боку, копіювання-прі-записи призводить до великої кількості переривань ядра, по одному на кожну сторінку, в яку відбувається запис. Залежно від апаратури, одне переривання ядра, що супроводжується копіюванням великої кількості сторінок, може виявитися ефективніше, ніж численні переривання ядра, властиві механізму копіювання-прі-записи. Нарешті, механізм копіювання-прі-записи погано працює через мережу, тому що в цьому випадку завжди (тобто при доступі до поділюваних сторінок) потрібен фізичний транспорт, так що перевага цього механізму, пов'язане з невиконанням копіювання тільки читаються даних, втрачається.
Зовнішні менеджери пам'яті
На качана нашого Обговорення ЗАСОБІВ управління пам'яттю в Mach ми коротко Згадаю про менеджерах пам'яті корістувальніцького режиму. Тепер розглянемо їх більш детально. Кожен об'єкт пам'яті, який відображається в адресний простір процесу, повинен мати зовнішній менеджер пам'яті, який ним керує. Об'єкти пам'яті різних класів управляються різними менеджерами пам'яті. Кожен з них може реалізовувати свою власну семантику, може вирішувати, де зберігати дані сторінок, які не перебувають у фізичній пам'яті, і слідувати своїм власним правилам при вирішенні питання про те, що робити з об'єктами після того, як їх відображення в пам'ять скасовується.
Для того, щоб відображати деякий об'єкт в адресний простір процесу, цей процес посилає повідомлення менеджеру пам'яті, запитуючи операцію відображення. Для того, щоб виконати цю роботу, потрібні три порту. Перший, порт об'єкта (object port), створюється менеджером пам'яті і використовується в подальшому ядром для інформування менеджера пам'яті про сторінкових відмовах та інші події, пов'язаних з об'єктом. Другий порт, порт управління, створюється самим ядром, так що менеджер пам'яті може реагувати на ці події (багато з них вимагають проведення деяких дій менеджером пам'яті). Використання різних портів пов'язано з тим, що порти є односпрямованим. У порт об'єкта пише ядро, а читає менеджер пам'яті, а порт управління працює в зворотному напрямку.
Третім є порт імені (name port), який використовується як різновид імені, за допомогою якого ідентифікується об'єкт. Наприклад, нитка може передати ядру віртуальний адреса і запитати, до якої області він відноситься. Відповіддю буде покажчик на порт імені. Якщо адреси належать до однієї і тієї ж області, то вони будуть ідентифікуватися одним і тим же портом імені.
Коли менеджер пам'яті відображає об'єкт, він забезпечує створення порту об'єкта як одного з параметрів. Потім ядро створює два інших порту і посилає инициализирующее повідомлення на порт об'єкта, що несе інформацію про портах управління і імені. Потім менеджер пам'яті посилає відповідь, повідомляючи ядру про те, якими є атрибути об'єкта, а також про те, чи потрібно чи ні зберігати об'єкт в кеші після того, як відображення буде скасовано. Спочатку всі сторінки об'єкта позначаються як заборонені за читання і запису, щоб викликати переривання при першому використанні.
У цьому місці менеджер пам'яті виконує читання порту об'єкта і блокує себе. Нитка, яка відобразила об'єкт, з цього моменту розблокується і може виконуватися. Менеджер пам'яті простоює до тих пір, поки ядро не попросить його що-небудь зробити, записавши повідомлення в порт об'єкта.
Рано чи пізно, нитка безсумнівно спробує прочитати сторінку або записати в сторінку, яка відноситься до об'єкту пам'яті. Ядро при цьому пошле повідомлення менеджеру пам'яті через порт об'єкта, інформуючи його про те, до якої сторінки відбулося звернення, і попросить менеджер забезпечити цю сторінку. Це повідомлення є асинхронним, так як ядро не наважується заблокувати будь-яку зі своїх ниток в очікуванні відповіді від призначеного для користувача процесу, якого може і не бути. Під час очікування відповіді ядро призупиняє викликала звернення до сторінці нитку і шукає інші нитки для виконання.
Коли менеджер пам'яті дізнається про сторінковому відмову, він перевіряє, чи є звернення дозволеним. Якщо немає, то він посилає ядру повідомлення про помилку. Якщо ж відображення дозволено, менеджер пам'яті отримує сторінку у той спосіб, який підходить для цього об'єкта. Якщо об'єкт є файлом, то менеджер пам'яті шукає коректну адресу і читає сторінку в власний адресний простір. Потім він посилає відповідь ядру, забезпечуючи його покажчиком на цю сторінку.
Ядро відображає сторінку в адресний простір викликав звернення процесу. Тепер нитка може бути розблокована. Цей процес повторюється до тих пір, поки всі потрібні сторінки не завантажаться.
Щоб бути впевненим у тому, що існує необхідний запас вільних сторінкових кадрів, нитка сторінкового демона час від часу прокидається і перевіряє стан пам'яті. Якщо вільних сторінкових кадрів фізичної пам'яті недостатньо, то вона збирає інформацію про старих "брудних" сторінках і відсилає її менеджеру пам'яті, відповідального за об'єкт, якому належать сторінки. Очікується, що менеджер пам'яті запише ці сторінки на диск і повідомить, коли ця операція буде завершена. Якщо сторінка належить до файлу, то менеджер спочатку знайде зміщення сторінки в файлі, а потім запише її туди. Використовуваний при цьому алгоритм заміни - це друге питання.
Варто зауважити, що сторінковий демон є частиною ядра. Хоча алгоритм заміни сторінок повністю машинно-незалежний, в ситуації, коли вільного місця не залишилося сторінками, які управляються різними менеджерами, немає прийнятного способу дозволити одному з них приймати рішення про те, яку сторінку потрібно витіснити з пам'яті. Єдиним прийнятним способом є статичний розподіл сторінкових кадрів між різними менеджерами і дозвіл кожному з них замінювати сторінки в межах цього набору. Однак через те, що глобальний алгоритм, взагалі кажучи, більш ефективний, ніж локальний, такий підхід не використовується.
На додаток до особливих менеджерам пам'яті, які відображають файли і інші спеціальні об'єкти, є менеджер пам'яті "за замовчуванням" (default) для "звичайного" відображення сторінок. Коли процес просить виділити йому область віртуального адресного простору за допомогою виклику Allocate, то фактично відбувається відображення об'єкта, керованого менеджером пам'яті "за замовчуванням". Цей менеджер поставляє заповнені нулями сторінки, якщо це необхідно. Він використовує тимчасовий файл для освіти простору на диску для свопінгу сторінок, а не спеціальну область на диску, як це робиться в Unix'е.
Щоб концепція зовнішнього менеджера пам'яті заробила, повинен існувати і використовуватися строго певний протокол взаємодії між ядром і менеджером пам'яті. Цей протокол складається з невеликої кількості типів повідомлень, якими обмінюються ядро і менеджер. Будь-яка взаємодія між ними ініціюється ядром в формі асинхронних повідомлень, що посилаються в порт об'єкта деякого об'єкту пам'яті. У відповідь на нього менеджер посилає асинхронний відповідь на порт управління.
У таблиці 6.4 наведено список типів повідомлень, які ядро посилає менеджеру пам'яті.
Таблиця 6.4.
Деякі типи повідомлень, що посилаються ядром менеджеру повідомлень
Init Ініціалізувати новий відображений в пам'ять об'єкт Data_request Передати ядру певну сторінку для обробки сторінкового відмови Data_write Взяти сторінку з пам'яті і переписати її Data_unlock розблокує сторінку, так що ядро може її використовувати Lock_completed Завершено виконання попередній запит Lock_request Terminate Інформування про те, що даний об'єкт більше не використовується
Коли об'єкт відображається в пам'ять з використанням виклику Map, то ядро посилає повідомлення Init відповідному менеджеру пам'яті, щоб дозволити йому форматувати себе. Це повідомлення визначає порти, які повинні будуть використовуватися пізніше в діалозі з об'єктом. Запити від ядра на отримання сторінки і поставку сторінки здійснюються за допомогою викликів Data_request і Data_write відповідно. Ці повідомлення керують трафіком сторінок в обох напрямках, і тому є найбільш важливими викликами.
Повідомлення Data_unlock є запит від ядра менеджеру пам'яті на розблокування заблокованої сторінки, так що ядро може використовувати її для іншого процесу. Повідомлення Lock_completed сповіщає про завершення послідовності Lock_request, і буде розглянуто нижче. Нарешті, повідомлення Terminate повідомляє менеджеру пам'яті, що об'єкт, ім'я якого зазначено у виклику, більше не використовується і може бути видалений з пам'яті. Існують виклики, певні для менеджера пам'яті "за замовчуванням".
Повідомлення, перераховані в таблиці 6.5, передаються від зовнішнього менеджера пам'яті ядра.
Таблиця 6.5.
Повідомлення, що посилаються менеджером пам'яті ядру
ВикликОпис
Set_attributes Відповідь на виклик Init Data_provided Відповідь на виклик Data_request - тут: запитана сторінка доставлена Data_unavailable Відповідь на виклик - Сторінка наразі не має в наявності Lock_request Запитує ядро для виконання очищення, витіснення або блокування сторінок Destroy Зруйнувати об'єкт, який більше не потрібен
Перше повідомлення, Set_attributes, є відповіддю на повідомлення Init. Воно повідомляє ядру, що менеджер готовий обробляти знову відображений об'єкт. Відповідь також містить біти режиму для об'єкта і каже ядру, слід чи ні кешувати об'єкт, навіть якщо жоден процес в будь-який момент часу не відображує його. Наступні два повідомлення є відповідями на повідомлення Data_request. Це повідомлення запитує сторінку у менеджера пам'яті. Відповідь менеджера залежить від того, може він надати сторінку чи ні. Перше повідомлення говорить про те, що може, друге - про те, що немає.
Повідомлення Lock_request дозволяє менеджеру пам'яті попросити ядро очистити деякі сторінки, тобто послати йому ці сторінки, щоб вони могли бути записані на диск. Це повідомлення може бути використано також і для того, щоб змінити режим захисту сторінок (читання, запис, виконання). Нарешті, повідомлення Destroy служить для повідомлення ядра про те, що деякий об'єкт більше не потрібен.
Необхідно звернути увагу на те, що коли ядро посилає повідомлення менеджеру пам'яті, воно в дійсності виконує виклик. Хоча при цьому способі гнучкість підвищується, деякі розробники систем вважають, що це неелегантно - ядру викликати призначений для користувача процес для виконання для ядра деякого сервісу. Ці люди зазвичай вірять в ієрархічні системи, коли нижні рівні забезпечують сервіс для верхніх, а не навпаки.
Розподілена колективна пам'ять в Mach
Концепція зовнішніх менеджерів пам'яті в Mach добре підходить для реалізації розподіленої сторінкової розділяється пам'яті. У цьому розділі будуть коротко описані деякі з робіт, виконані в цій області. Основна ідея полягає в тому, щоб отримати єдине, лінійне віртуальний адресний простір, який розділяється між процесами, що працюють на комп'ютерах, які не мають будь-якої фізичної розділяється пам'яті. Коли нитка посилається на сторінку, якої у неї немає, то відбувається сторінкове переривання. Необхідна сторінка відшукується на одному з дисків мережі, доставляється на ту машину, де стався сторінковий збій, і поміщається в фізичну пам'ять, так що нитка може продовжувати працювати.
Так як Mach вже має менеджери пам'яті для різних класів об'єктів, то природно ввести новий об'єкт пам'яті - розділяється сторінку. Спільні сторінки управляються одним або більше спеціальними менеджерами пам'яті. Однією з можливостей є існування єдиного менеджера пам'яті, який управляє всіма розділяються сторінками. Інший варіант полягає в тому, що для кожної розділяється сторінки чи кількох поділюваних сторінок використовується свій менеджер пам'яті, щоб розподілити навантаження.
Ще одна можливість полягає у використанні різних менеджерів пам'яті для сторінок з різною семантикою. Наприклад, один менеджер пам'яті міг би гарантувати повну узгодженість пам'яті, яка б означала, що будь-який читання, наступне за записом, завжди буде бачити найсвіжіші дані. Інший менеджер пам'яті міг би надавати більш слабку семантику, наприклад, що читання ніколи не повертає дані, які застаріли більш, ніж на 30 секунд.
Розглянемо найбільш загальний випадок: одна колективна сторінка, централізоване управління і повна узгодженість пам'яті. Всі інші сторінки локальні для кожної окремої машини. Для реалізації цієї моделі нам знадобиться один менеджер пам'яті, який обслуговує всі машини системи. Назвемо його сервером розподіленої пам'яті, що (Distributed Shared Memory, DSM). DSM-сервер обробляє посилання на розділяється сторінку. Звичайні менеджери пам'яті керують іншими сторінками. До сих пір ми мовчазно припускали, що менеджер або менеджери пам'яті, які обслуговують дану машину, повинні бути локальними для цієї машини. Фактично, через те, що комунікації прозорі в Mach, менеджер пам'яті не обов'язково розташовується на тій машині, чиєю пам'яттю він керує.
Розбита сторінка завжди доступна для читання або запису. Якщо вона доступна для читання, то вона може копіюватися (реплицироваться) на різні машини. Якщо ж вона доступна для запису, то повинна бути тільки одна її копія. DSM-сервер завжди знає стан розділяється сторінки, а також на якій машині або машинах вона зараз знаходиться. Якщо сторінка доступна для читання, то DSM-сервер сам має її дійсну копію.
Припустимо, що сторінка є доступною для читання, і нитка, яка працює на якійсь машині, намагається її прочитати. DSM-сервер просто посилає цій машині копію сторінки, оновлює свої таблиці, щоб зафіксувати ще одного читача, і завершує на цьому дану роботу. Функція не буде працювати в новій машині і позначена "для читання".
Тепер припустимо, що один з читачів намагається здійснити запис в цю сторінку. DSM-сервер посилає повідомлення ядру або ядер, які мають цю сторінку, з проханням повернути її. Сама сторінка не повинна передаватися, так як DSM-сервер має її дійсну копію. Все, що потрібно, це підтвердження, що сторінка більше не використовується. Після того, як всі ядра звільнять сторінку, письменник отримує її копію разом з дозволом використовувати її для запису.
Якщо тепер хто-небудь ще хоче використовувати цю сторінку (яка тепер доступна для запису), DSM-сервер говорить поточного її власнику, що її потрібно припинити використовувати і повернути. Коли сторінка повертається, вона може бути передана одному або декільком читачам або одному письменнику. Можливі багато варіації цього централізованого алгоритму, наприклад, не запитувати повернення сторінки до тих пір, поки машина, що володіє нею, що не поживе протягом деякого мінімального часу. Можливо також і розподілене рішення.
Чи знаєте Ви,
що релятивістське пояснення феномену CMB (космічному мікрохвильового випромінювання) придумав чоловік видатної фантазії Йосип Шкловський (пам'ятаєте книжку мільйонного тиражу "Всесвіт, життя, розум"?). Він висунув абсолютно абсурдну ідею, яка полягала в тому, що це є "реліктове" випромінювання, що залишилося після "Великого Вибуху", тобто від моменту "народження" Всесвіту. Хоча з простої логіки випливає, що Всесвіт є все, а значить, у неї немає ні початку, ні кінця ... Детальніше читайте в FAQ по ефірної фізіці . НОВИНИ ФОРУМУ 
Лицарі Теорії ефіру 13.06.2019 - 5:11: ЕКОЛОГІЯ - Ecology -> ПРОБЛЕМА ГЛОБАЛЬНОЇ ЗАГІБЕЛІ бджіл ТА других запилювачів РОСЛИН - Карім_Хайдаров.
12.06.2019 - 9:05: ВІЙНА, ПОЛІТИКА І НАУКА - War, Politics and Science -> Проблема державного тероризму - Карім_Хайдаров.
11.06.2019 - 18:05: ЕКСПЕРИМЕНТАЛЬНА ФІЗИКА - Experimental Physics -> Експеримент Серлі и его послідовніків з магнітамі - Карім_Хайдаров.
11.06.2019 - 18:03: ВИХОВАННЯ, ОСВІТА, ОСВІТА - Upbringing, Inlightening, Education -> Просвітніцтво від Андрія Маклакова - Карім_Хайдаров.
11.06.2019 - 13:23: ВИХОВАННЯ, ОСВІТА, ОСВІТА - Upbringing, Inlightening, Education -> Просвітніцтво від В'ячеслава Осієвського - Карім_Хайдаров.
11.06.2019 - 13:18: ВИХОВАННЯ, ОСВІТА, ОСВІТА - Upbringing, Inlightening, Education -> Просвітніцтво від Світлани Віслобоковой - Карім_Хайдаров.
11.06.2019 - 6:28: Астрофізікі - Astrophysics -> До 110 річчя Тунгуска катастрофи - Карім_Хайдаров.
10.06.2019 - 21:23: ВИХОВАННЯ, ОСВІТА, ОСВІТА - Upbringing, Inlightening, Education -> Просвітніцтво від Володимира Васильовича Квачкова - Карім_Хайдаров.
10.06.2019 - 19:27: СОВІСТЬ - Conscience -> Вищий розум - Карім_Хайдаров.
10.06.2019 - 19:24: ВІЙНА, ПОЛІТИКА І НАУКА - War, Politics and Science -> ЗА НАМИ страви - Карім_Хайдаров.
10.06.2019 - 19:14: СОВІСТЬ - Conscience -> російський СВІТ - Карім_Хайдаров.
10.06.2019 - 8:40: ЕКОНОМІКА І ФІНАНСИ - Economy and Finances -> КОЛЛАПС Світової Фінансової СИСТЕМИ - Карім_Хайдаров. 
Пам'ятаєте книжку мільйонного тиражу "Всесвіт, життя, розум"?