Б №14 односегментна модель
Невідомі Ос, що підтримують одно сегментну модель*в чистому вигляді*, але її розгляд полегшить розум1ння складніших моделей.
У обчислювальній системі, що підтримує односегментную модель, повинен існувати регістр дескриптора сегменту, вміст якого складається з двох полів: початкової (базового) адреси сегменту в реальній пам'яті і довжини сегменту. Коли процес розміщується в пам'яті, для виділеного йому сегменту формується дескриптор, який записується у вектор полягання в контексті процесу. При перемиканні контексту дескриптор сегменту завантажується в апаратний регістр дескриптора сегменту і служить тією "таблицею трансляції", по якій апаратура переводить віртуальні адреси в реальні. Сама трансляція адрес відбувається по простому алгоритму. Оскільки віртуальний адресний простір процесу є лінійною послідовністю адрес, що починається з 0, віртуальна адреса є простим зсувом відносно початку сегменту. Реальна адреса виходить складанням віртуальної адреси з базовою адресою, вибраною з дескриптора сегменту. Єдиний шлях для виходу процесу за межі свого віртуального адресного простору - завдання віртуальної адреси, більшої, ніж розмір сегменту. Цей шлях легко може бути перекритий, якщо апаратура при трансляції адрес порівнюватиме віртуальну адресу з довжиною сегменту і виконуватиме переривання-пастку, якщо віртуальна адреса більша. Та обставина, що процес працює у віртуальних адресах, робить можливим переміщення сегментів в реальній пам'яті. Перемістивши процес в іншу область реальної пам'яті, ОС просто змінює поле базової адреси в дескрипторі його сегменту. Оскільки, як і в моделі з фіксованими розділами, реальна пам'ять розподіляється безперервними блоками змінної довжини, тут застосовуються ті ж стратегії розміщення. Але можливе тут переміщення сегментів є ефективним способом боротьби із зовнішніми дірками. Сегменти переписуються в реальній пам'яті так, щоб вільних місць між ними не залишалося, весь вільний простір зливається в один великий вільний блок і, таким чином, виявляється доступним для подальшого розподілу.
Загальні області пам'яті
Два і більше процесів можуть використовувати одну і ту ж фізичну область пам'яті. Найпростіше це досягається в тих моделях пам'яті, які забезпечують динамічну трансляцію адрес. Кожен процес має власну таблицю сегментів або сторінок, в якій міститься, крім іншого, базова адреса сегмента / сторінки у фізичній пам'яті. Оскільки для кожного процесу розділяється сегмент описується своїм дескриптором, права доступу до сегменту можуть бути встановлені різними для різних процесів. У разі іменованих областей пам'яті один процес створює загальну область пам'яті, а другий її "відкриває":У складі API маються системні виклики "закриття" / знищення загальної області пам'яті. Поділювані області пам'яті, однак, породжують ряд проблем як для програмістів, так і для ОС. Проблеми програмістів - взаємне виключення процесів при доступі до загальної пам'яті. Проблеми ОС - організація свопінгу. ОС повинна обробляти, наприклад, такий випадок: два процеси - A і B - розділяють сегмент; процес A справив запис в сегмент і в його дескрипторі сегмент позначений, як "брудний". У той час, коли активний процес B, приймається рішення про витіснення цього сегменту з пам'яті. Але в дескрипторі процесу B цей сегмент має ознаки "чистий", тому сегмент може бути звільнений у фізичній пам'яті без збереження на зовнішній пам'яті і зміни в сегменті, зроблені процесом A, будуть втрачені. ОС доводиться вести окрему таблицю поділюваних сегментів, в якій відображати справжнє їх стан. З точки зору ідентифікації розділяються області пам'яті можуть розглядатися як віртуальні комунікаційні порти. Для неіменованого областей пам'яті можлива передача селектора (номери у таблиці дескрипторів) від одного процесу до іншого. Розміщення в загальних віртуальних адресах зручно для системних програм і динамічних бібліотек, до яких відбуваються часті звернення з додатків: якщо ці компоненти ОС знаходяться в адресному просторі процесу, то звернення до них не вимагають перемикання контексту. Але з іншого боку, це знижує надійність: якщо системні компоненти доступні для програми, то вони можуть бути їм зіпсовані. Тому така "розкіш" може бути допущена тільки в однокористувацьких системах.