Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Мужчины по вызову и еще. | ceny drzwi wewnetrznych z o'scieznica, your

Однорівнева пам'ять

  І кожен вже десять років вивчає ролі
Про які років десять як варто забути
Б.Гребенщиков

Ефективне управління робочими наборами призначених для користувача програм і, з іншого боку, ефективне кешування запитів до дисків дозволяють якщо і не приховати повністю, то значною мірою згладити відмінність в продуктивності оперативної і зовнішньої пам'яті комп'ютера. Тому відразу ж після виникнення перших машин з віртуальною пам'яттю почалися спроби заховати всі останні відмінності між цими двома типами пам'яті від програміста, реалізувавши так звану однорівневу пам'ять.
Інтерес до цієї ідеї зберігається до цих пір. Наприклад, на сайті [dz.yandex.ru] в кінці 2000 року була серія публікацій і досить бурхлива дискусія про достоїнства і недоліки "персистентних об'єктів" — об'єктів в термінах об'єктно-орієнтованого програмування, які переживають перезавантаження і виключення живлення системи. Для зберігання таких об'єктів може використовуватися як флэш-память, так і інші форми незалежної пам'яті, ті ж жорсткі диски. Власник сайту і ініціатор дискусії, Дмитро Завалішин, відстоював тезу про те, що такі об'єкти є сокровенною мрією і свого роду Священним Граалем всього програмування і розвитку обчислювальної техніки.

Однорівнева пам'ять в Multix
Піонером в реалізації однорівневої пам'яті була ОС Multix фірми Honeywell. Ця система була розроблена в кінці 60-х років і зробила величезний вплив на розвиток обчислювальної техніки як прямо, так і за допомогою свого нащадка Unix. Декілька машин з цією ОС експлуатувалися і були доступні через Internet (в усякому разі, відповідали на запит ping) ще в 1997 році.
Multix надавала засоби відображення файлів на адреси оперативної пам'яті нарівні з більш традиційними засобами введення-виводу. Ранні версії Unix призначалися у тому числі і для роботи на машинах без диспетчера пам'яті або з віртуальною пам'яттю на основі базових регістрів, де можливе лише традиційне уведення-виведення. Проте сучасні системи цього сімейства частково повернулися до витоків і також надають цей спосіб доступу до файлів.
Втім, як наголошувалося вище, що надається сучасними Unix-системами mmap швидше є документованим внутрішнім інтерфейсом завантажувача, чим повноцінний засіб організації однорівневого доступу: робота з файлом, що відображує, не повністю прозора для користувача. Наприклад, зміни вмісту ОЗУ, що відображує, і навпаки, зміни, внесені до файлу з моменту відображення, необхідне синхронізовать один з одним уручну, використовуючи системний виклик msynch. Засоби, що надаються для цієї мети Windows Nt/2000/xp, прозоріші і простіші у використанні, але теж застосовуються відносно рідко.

Для того, щоб зрозуміти, чи можлива повністю однорівнева пам'ять, і якщо так, то якою мірою, давайте спочатку встановимо відмінності між ОЗУ і найбільш поширеним типом зовнішньої пам'яті, жорстким магнітним Диском.
По-перше, об'єм оперативної пам'яті в сучасних комп'ютерах вимірюється десятками і сотнями мегабайт, а в систем колективного користування Досягає декілька гігабайт. Характерна ємкість жорсткого диска починається з декількох гігабайт (диски меншого об'єму просто не проводяться) і закінчується сотнями гігабайт. Якщо ми хочемо адресувати все це єдиним чином, ми повинні розширити адресний простір. 32 біт явно недостатньо, 64 біт на найближчі роки вистачить, але зростання ємкості дискових масивів йде по експоненті.
Втім, розширення адресного простору само по собі не представляє великої проблеми — мало 64 біт, зробимо 128, тим більше що йдеться не про адресну шину процесора, використовувану лише для адресації ОЗУ а про віртуальну адресу. Сучасні технології без особливих проблем дозволяють упакувати арифметико-логічний пристрій і регістри такої розрядності в один кристал, зробити корпус з належним числом ніг, друкарську плату, в яку можна упаяти такий корпус і автоматичну лінію, яка распаївать корпуси по платах. Так, це буде не Spectrum, уручну не спаяєш — але і материнську плату сучасного комп'ютера Рс-совместімого уручну неможливо розвести і спаяти. Ну і що?
По-друге, оперативна пам'ять втрачає свій вміст при виключенні живлення, а жорсткий диск — зберігає, тому нерідко використовується ще одна характеристика дискової пам'яті як зіставлення оперативною — постійна пам'ять. Можна пригадати і про проміжні рішення, наприклад про флэш-памяти і її аналоги, які адресуються майже як ОЗУ, а дані зберігають майже як жорсткий диск. Наявність проміжних рішень наводить на думку, що особливих проблем "з цього боку чекати не доводиться. Насправді, проблема тут є, але обговоримо ми її ледве пізніше.
По-третє, і це пов'язано відразу з обома вищеназваними причинами, людина зглянулася до ручного наведення порядку на диску (видалення сміття і ін.) набагато частіше, ніж до виконання тієї ж операції в ОЗУ. Тому жорсткі диски зазвичай забезпечуються ще однією схемою адресації, орієнтованої на використання людиною: коли замість адреси, що представляється цілим числом, використовується символічне ім'я.
Трансляція імені в адресу (сектор, поверхню і доріжку жорсткого диска) здійснює файлова система. Питання організації файлових систем, каталогів і управління структурами вільної і зайнятої дискової пам'яті обговорюються в главі 10.
Єдина з використовуваної в даний час архітектури, надаюча "чесну" однорівневу пам'ять, As/400, має два представлення покажчика, недозволене — з ім'ям як селектор сегменту, і дозволене — з бінарним представленням цього селектора. Можна собі представити і інші механізми трансляції імен в адреси, наприклад здобуття покажчика за допомогою виконання системного виклику

void *resolve(char * object_name, int flags)

або чого-небудь в цьому роді. Особливих технічних проблем це не представляє, питання в тому, чи треба це.
Виклад один з аргументів на користь того, що це треба далеко не завжди, ми пропонуємо почати здалека, а саме з вельми банальної тези, що писати програми без помилок людство до цих пір не навчилося і навряд чи навчиться в осяжному майбутньому. Виконання програми, що містить помилки, може породжувати не лише звернення по невірних покажчиках і вихід за кордони масивів (найбільш руйнівні типи помилок, від яких сегментні і сторінкові диспетчери пам'яті надають певний захист), але і тонші проблеми — фрагментацію і витік вільної пам'яті і різні розузгодження (у СУБД застосовують точніший термін — порушення цілісності даних).
Накопичення цих помилок рано чи пізно приводить до того, що програма втрачає здатність функціонувати. Втрата цієї здатності може бути виявлена і користувачем ("щось прога глючит", "зависла"), і системою (вичерпання квоти пам'яті або інших ресурсів, перевищення лімітів зростання своп-пространства або доступ за неприпустимою адресою), і навіть самою програмою — якщо існують формальні критерії цілісності даних, в різних місцях коди можуть зустрічатися перевірки цих критеріїв.
Підручники по програмуванню, наприклад [Дейкстра 1978], настійно рекомендують виробляти такі критерії і вставляти відповідні перевірки скрізь, де це доцільно. Зрозуміло, що забувати про здоровий глузд і вставляти їх після кожного оператора, або навіть лише перед кожною операцією, для виконання якої потрібна цілісність, далеко не завжди виправдано з точки зору продуктивності, так що при реальному програмуванні треба шукати баланс.
Інколи в ході таких перевірок навіть удається відновити цілісність (приклади алгоритмів перевірки і відновлення структур файлової системи наводяться в главі 12), але очевидно, що далеко не завжди це можливо. В цьому випадку залишається лише проінформувати користувача, що у нас "Assertion failed" (припущення порушене) і по можливості мирно завершитися.
Зберігати при цьому дані в постійну пам'ять небезпечно: якщо ми не можемо відновитися, ми часто не можемо і знати, наскільки далеко зайшло порушення цілісності, тому збереження чого б то не було в такому достатку чревато повною або частковою (що теж неприємно) втратою інформації. Зокрема, саме з цих міркувань ОС спільного призначення, виявивши помилку в ядрі, відразу малюють регістри на консолі (ризикуючи при цьому цілісністю файлових систем і призначених для користувача даних), а не пропонують користувачеві зробити які-небудь заходи пс збереженню даних.
Сенс останову завдання або всієї системи з подальшим її перезапуском полягає в тому, щоб заново проїніциалізіровать структури даних, використовувані при роботі програмного забезпечення. Цю дію можна описати но!
"контрольоване забуває" всього поганого, що накопичилося в пам'яті за час роботи програми, і почало з більш менш чистого аркуша.
Сервіс автоматичного перезапуску в різних формах надається багатьма застосуваннями, ОС і навіть апаратною архітектурою.
Наприклад, практично обов'язковим елементом сучасних мікроконтроллерів є watchdog timer (сторожовий таймердослівно — "сторожовий собака"), що часто працює від власного осцилятора, а не від спільного тактового генератора машини. Програма мікроконтроллера повинна періодично скидати сторожовий таймер, інакше, долічивши до кінця, він робить вивід, що програма "зависла" і ініціює системне скидання.
Саме сторожовий таймер кілька разів перезавантажував бортовий комп'ютер посадочного модуля "АПОЛЛОНА-І" і, мабуть, врятував цим життя астронавтів і місячну програму США [NASA 182505].
Аналогічні схеми часто застосовуються у вбудовуваних застосуваннях, особливо орієнтованих на тривалу автономну роботу. Дійсно, вбудовуване застосування може опинитися у вельми неприємному для людини місці, наприклад, поблизу від активної зони реактора або прискорювача (зрозуміло, що для таких вживань необхідне спеціального виконання мікросхем, наприклад на сапфіровій підкладці). У цих випадках інколи виводять кнопку системного скидання в "чисті" області багатометровим кабелем. Але, скажімо, для комп'ютера космічного апарату, що управляє, таке рішення просто не реалізовується. Бувають і ситуації, коли виводити кнопку системного скидання назовні небажано по банальнішим, ергономічним і т. д., міркуванням, наприклад із-за небезпеки випадкового натиснення.
Про щось аналогічне такому сервісу часто мріють адміністратори серверів. У Новосибірськом FIDO одного дня цілком серйозно обговорювалася така схема автоматизованого перезапуску: сервер кожні п'ять хвилин перепрограмує джерело безперебійного живлення на те, щоб він через десять хвилин від теперішнього моменту вимкнувся і знову включився. У FIDO зустрічаються опису і екстравагантніших рішень, наприклад "деглюкатор" (пристрій, що включається в шину ISA і по запиту програми що виконує скидання зовнішнього модему) або механізм важеля, за допомогою якого комп'ютер, висунувши піднос CD-ROM, може сам собі натискувати на кнопку скидання (корисний в ситуаціях, коли система ще умовно працездатна, але з високою вірогідністю може "зависнути" при спробі нормального перезавантаження).
Зрозуміло, що всі вищеперелічені рішення не можуть замінити собою відладку і виправлення помилок в прикладних і системних програмах І є швидше останньою лінією оборони (якщо навіть не діями, що робляться від відчаю) в боротьбі з системними збоями. Але доки людство не навчиться писати програми без помилок, можливість "привести у відчуття" збожеволілу програму шляхом її перезапуску залишається життєво необхідною.
Зрозуміло також, що якщо програма повністю зберігає своє полягання в постійній пам'яті, її перезапуск нам нічим не допоможе: програма чесно відновить все те сміття, яке накопичилося в її сегментах і файлах даних за час попередньої сесії, і чесно відтворить знову той збій, із-за якого і було потрібно рестарт.
У цьому сенсі украй бажано тримати під контролем перенесення даних з постійної пам'яті в оперативну, а особливо у зворотному напрямі уникаючи його повній "прозорості". Кожна додаткова точка збереження достатку системи підвищує ризик відтворення збоївши або навіть виникнення нових проблем, породжених у файлах збереження достатку під час надмірний "жорсткого" перезапуску.

Реєстр Win32
В світлі цього, наприклад, системний реєстр Win32, що не має адекватних засобів відновлення і самоконтролю, є якщо і не свідомою диверсією, то, в усякому разі, недостатньо продумане технічне рішення — із-за нього багато проблем, для виправлення яких в більш продуманих з цієї точки зору системах досить перезавантаження або очищення конфігураційного файлу, в Win32 доводиться вирішувати переустановленням ОС.
Так, Windows NT надає деякі засоби резервного копіювання реєстру — "відновну" дискету і "останню хорошу (last known good) конфігурацію", але ці засоби незручні для повсякденного використання, а "остання хороша конфігурація" і просто неадекватна: той факт, що з даним вмістом реєстру ми дійшли до віконця з ім'ям і паролем, це, звичайно, певне досягнення і привід цей реєстр зберегти — але у жодному випадку не привід затирати попередню (тепер уже передостанню) "хорошу" конфігурацію!
Якщо говорити саме про налаштування ОС, найрадикальніше ця проблема вирішена в сучасних версіях FREEBSD (вільно поширюваній системі сімейства Unix), в якій всі файли налаштування ОС і системних сервісів включені в систему контролю версій, що забезпечує повний або частковий відкіт на необмежене число модифікацій назад. Власне, це може бути реалізовано в будь-якій ОС, яка зберігає свою конфігурацію в текстовому форматі, стандартними засобами контролю версій, використовуваними для розробки програмного забезпечення, — CVS і ін.

В світлі наведених вище міркувань, корисно розділяти оперативні об'єкти, що зберігаються, не лише за способом адресації, але і за уявленням даних. Ці вистави повинні задовольняти різним і не завжди сумісним вимогам: при виборі внутрішнього оперативного представлення даних основні критерії — це швидкість, зручність доступу і умопостіжпмость коди, яка з цими даними працюватиме, а для „нешнего, вистави, що зберігається, — перш за все легкість перевірки і, якщо це можливо, відновлення цілісності даних. При розробці зовнішнього формату даних бажано також взяти до уваги міркування міжмашинної сумісності — можливі відмінності в порядку байтів і навіть бітів в цілочисельних значеннях, особливості представлення чисел з плаваючою крапкою, відмінності кодування тексту і так далі.
Якщо представлення об'єктів, що зберігаються і оперативне, різні, однорівнева пам'ять для нас швидше шкідлива, чим даремна: перш ніж програма зможе працювати з об'єктом, вона повинна перетворити його у внутрішню виставу (у об'єктно-орієнтованих мовах це може робити один з конструкторів об'єкту). Цю процедуру зазвичай виявляється доцільно поєднати з прочитуванням зовнішнього представлення об'єкту з файлу. "Прозорий" же для призначеної для користувача програми запис даних в зовнішній формат буває і просто небезпечна — нерідко для забезпечення цілісності даних виявляється необхідний контроль над порядком запису тих або інших полів і структур.
Об'єднання оперативної і довготривалої пам'яті, таким чином, опиняється застосовно лише в тих ситуаціях, коли нам, по-перше, удалося розробити модель даних, що одночасно задовольняє вимогам, що пред'являються і до оперативної, і такої, що до зберігається вистав, і по-друге, коли нас не турбує небезпека порушення нашої моделі даних із-за неповного їх збереження у момент системного збою (або коли ми маємо якісь засоби запобігання цій небезпеці).
Безумовно, засоби для відображення файлів в пам'ять краще мати, чим не мати. До того ж їх можна використовувати і для інших цілей, окрім власне організації однорівневого доступу до даних — для завантаження програм, виділення пам'яті або емуляції сегментів даних, що розділяються між завданнями і навіть між машинами (при доступі до файлу по мережі).
Поважно ще підкреслити, що розділення представлень даних на зовнішніх і внутрішніх не зобов'язане повністю відповідати способу їх зберігання — в ОЗУ або на диску. Окрім зберігання оперативних даних в своп-пространстве і різному роді "віртуальних дисків" можна навести і радикальніший приклад: таблиці, індекси і інші файли даних сервера реляційної СУБД є, швидше, оперативним представленням даних, РОЛЬ же вистави, що зберігається, в даному випадку грають формати, Використовувані для експорту і резервного копіювання вмісту таблиць.
Завдяки цьому прикладу стає зрозумілішим, чому єдина з комерційно вживаних в даний час систем з однорівневою адресацією — As/400 — орієнтована на використання як сервер СУБД. У літературі, особливо в рекламній, навіть зустрічається її опис "апаратного сервера баз даних".

Примітка
Взагалі, опис спеціалізованих комп'ютерів як "апаратне щось там"— що нерідко зустрічається, дотепний і досить ефективний маркетинговий прийом. Зрозуміло, що ніж коротшу і однозначнішу відповідь дає технічний фахівець на питання тих, що "приймають рішення", тим легше йому буде обгрунтувати конкретний вибір. Тому нарівні з грамотним і вичерпним описом технічних достоїнств, хороший рекламний опис повинен в явному або неявному вигляді містити і варіанти відповідей на багато поширених питань з боку нетехнічного персоналу.
Так, якщо начальник запитує адміністратора: "Ось, купимо ми цей комп'ютер — моя секретарка зможе на нім в Lines грати?", той може йому відповісти: "А це не комп'ютер, це апаратний... " маршрутизатор (Cisco), сервер СУБД (As/400), веб-сервер-сервер (спроби продавати такі сервери на основі Linux робилися, але великого успіху не мали), потрібне підставити.

 

:: Реклама ::

Доставка ростов на дону розы источник. | Cjnbvjcnm ghjldb tybz cfqnf источник.

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017