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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

купить складной нож в москве, jdbug

Сегменти, сторінки і системні виклики (продовження)

Апаратні схеми тонкого розділення доступу до адресного простору не мали великого успіху не лише із-за високих накладних витрат, але і через те, що вирішували не зовсім ту проблему, яка реально важлива. Для підвищення надійності системи в цілому важливе не виявлення помилок і навіть не їх локалізація з точністю до модуля сама по собі, а можливість відновлення після їх виникнення. Найпоширеніші фатальні помилки в програмах — це помилки роботи з покажчиками і вихід індексу за кордони масиву (у наше мережеве століття помилки другого типа відоміші як "зрив буфера"). Ці помилки не лише часто зустрічаються, але і дуже небезпечні, бо відновлення після них практично неможливе. Помилки роботи з покажчиками ще можна спробувати усунути, викоренивши само поняття покажчика. Приблизно цією логікою продиктована заборона на формування покажчиків в машинах Burroughs, саме з цих міркувань в Java і деяких інших мовах покажчиків, що інтерпретуються, взагалі немає. Проте викоренити поняття індексованого масиву вже не так легко. д помилки індексації присуши всім компільованим мовам, починаючи з Fortran і Algol 60. Вставка перевірок на кордони індексу перед кожною вибіркою елементу масиву створює накладні витрати, але теж не вирішує проблеми: помилка все одно виявляється не у момент здійснення (в той момент, коли ми обчислили невірний індекс), а пізніше, коли ми спробували його використовувати. У момент індексації зазвичай вже неможливо зрозуміти, який же елемент масиву мався на увазі. Програмі залишається лише намалювати на екрані яке-небудь прощальне повідомлення начеб "Unhandled Java Exception", і мирно завершити свою земну дорогу. Зрозуміло, що реакція користувача на подібне повідомлення буде анітрохи не адекватнішою, ніж на хрестоматійне "Ваша програма виконала неприпустиму операцію — General Protection Fault" (втім, хто знає, можливо, така реакція і є найадекватнішою?). Прогрес у вирішенні цієї проблеми лежить вже у сфері вдосконалення технологій програмування, і навряд чи може бути забезпечений ускладненням диспетчерів пам'яті. Рівень же надійності, що забезпечується сучасними ОС спільного призначення з розділенням пам'яті, мабуть, оптимальний в тому сенсі, що поліпшення у сфері захисту пам'яті можуть бути досягнуті лише ціною значних накладних витрат без принципового підвищення напрацювання на відмову.

 

:: Реклама ::

Двойной стеклопакет замена своими руками, инструкция. Изысканный подарок - картина с фотографии в Москве.

 

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


 

 

 


Copyright © Kivik, 2017