• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

КОНСПЕКТ ЛЕКЦІЙ 4 страница

Але при середніх і більших навантаженнях планування може забезпечити значно кращі швидкісні характеристики, ніж простий метод FCFS.

Цільові характеристики принципів планування

Для розділення принципів планування на категорії існують і деякі інші критерії:

1) Пропускна здатність.

2) Середній час відповіді.

3) Розкид, або дисперсія відповіді в часі (тобто передбачуваність).

Ці критерії направлені на покращення загальних швидкісних характеристик, можливо і за рахунок деяких індивідуальних запитів. Плануванння часто поліпшує загальну картину, хоча і дещо знижує швидкість обслуговування певних запитів.

Одним з важливих кількісних показників для оцінки цього явища може служити розкид, або дисперсія відповідей в часі.

Дисперсія – це міра того, наскільки далеко значення індивідуальних елементів може відхилятись від середнього значення цих елементів.

В зв’язку з чим ми використовуємо дисперсію, як показник передбачуваності – чим менша дисперсія, тим більша передбачуваність.

Нам необхідна така стратегія планування, яка б мінімізувала дисперсію. Інакше може статися таке, що час обслуговування певних запитів просто не можна буде передбачити. (Неприпустимо, наприклад, в системі резервування авіаквитків). Якби стратегія планування була направлена тільки на досягнення максимальної пропускної здатності без одночасної мінімізації дисперсії, система обробляла би тільки зручні для обслуговування запити, а деякі ігнорувала би повністю.

Оптимізація пошуку циліндру

Найбільш поширені стратегії оптимізації.

1. FCFS – запити обслуговуються в порядку надходження.

2. SSTF – (Shortest Seek Time First) („з найменшим часом пошуку - першим”).

При позиціонуванні каретки з магнітними головками наступним вибирається запит, для якого необхідне мінімальне переміщення каретки. Першим обслуговується запит з найменшим часом пошуку циліндра, якщо навіть цей запит не є першим в черзі.

Має місце різка дискримінація певних запитів. Звернення до диску виявляють тенденцію концентруватись, в результаті запити до самих внутрішніх, або самих зовнішніх доріжок можуть обслуговуватись значно гірше, ніж до середніх доріжок.

Рис. __

Краща пропускна здатність, ніж FCFS, і найкращий середній час відповіді при помірних навантаженнях.

Велика дисперсія, тобто погана передбачуваність, не підходить для інтегрованих систем, але добра в пакетних системах, де основне – пропускна здатність.

3. SCAN (сканування). Каретка з головками рухається туди і назад над поверхнею, обслуговуючи всі запити, що зустрічаються на шляху. Каретка змінює напрям руху, якщо в біжучому напрямку більше немає запитів для обслуговування.

Рис. __

Стратегія розроблена для зменшення дискримінації крайніх доріжок.

Аналогічна SSTF за винятком того, що вона вибирає для обслуговування той запит, для якого є характерною мінімальна відстань пошуку в привілейованому напрямку.

Цей принцип (SCAN) є основою більшості практично реалізованих стратегій планування роботи з дисковою пам’яттю.

На крайніх доріжках головки бувають не так часто, як на середніх, але це краще, ніж дискримінація в SSTF.

4. N-Step SCAN (N - крокове сканування). Модифікація SCAN.

Каретка з головками рухається туди і назад, але всі запити, що поступають під час ходу в одному напрямку, групуються та перешиковуються таким чином, щоб їх можна було найбільш ефективно обслуговувати під час зворотнього ходу.

Рис. __

Найважливіша риса - невелика дисперсія часу відповіді в порівнянні з принципом SSTF або звичайним варіантом SCAN.

Ця стратегія виключає можливість безмежного відкладання, яке звичайно виникає у випадку надходження великої кількості запитів на звертання до біжучого циліндра. Вона передбачає запам’ятовування тих запитів, що надійшли при зворотному ході каретки.

5. С-SCAN (циклічне сканування).

Каретка рухається в напрямку до внутрішньої доріжки. Якщо попереду більше нема запитів для обслуговування, каретка стрибком повертає до початку, обслуговує запит, найближчий до зовнішньої доріжки, а потім обслуговує рух до середини.

Рис. __

Ця стратегія виключає дискримінацію у відношенні до внутрішніх або зовнішніх циліндрів. При просуванні від зовнішнього циліндру до внутрішнього, обслуговування запитів виконується за найкоротшим часу пошуку.

Запити, що надходять під час біжучого прямого ходу, обслуговується при наступному проході. Маємо дуже малу дисперсію відповідей в часі.

Найбільш ефективна стратегія планування роботи дискової пам’яті мала б мати два режими:

- при малих навантаженнях – SCAN;

- при середніх і великих і навантаженнях - С-SCAN.

С-SCAN з оптимізацією за часом очікування записів найбільш ефективна при дуже великих навантаженнях.

6. Схема Еменбака.

Каретка рухається циклічно, як в способі С-SCAN. Але при обслуговуванні кожного циліндру виконується доступ тільки до одної повної доріжки інформації незалежно від наявності іще запитів для цього циліндра.

Передбачається перешиковування запитів для обслування в рамках одного циліндру з врахуванням кутового положення записів, але якщо два запити відносяться до секторів одного циліндру, що перекриваються, то тільки один з них обслуговується при біжучому ході каретки.

Схема С-SCAN з оптимізацією за часом очікування запитів більш ефективна в умовах дуже великих навантажень.

Оптимізація за часом очікування запитів

В умовах великих навантажень ймовірність декількох одночасних звертань до певного циліндру зростає, що робить доцільним виконувати оптимізацію не тільки за пошуком циліндрів, але і за часом очікування записів.

Рис. __

Аналогом SSTF але в застосуванні до оптимізації за часом очікування записів, є стратегія SLTF (Shortest Latency Time - First) (з найменшим часом очікування – першим).

Коли каретка підводиться на певний циліндр може виявитись, що багато запитів очікують звертання до різних доріжок чи секторів цього циліндру. SLTF- аналізує всі ці запити і першим обслуговує запит з мінімальним очікуванням запису. Ця стратегія досить близька до теоретично оптимальної, причому її відносно легко реалізувати.

Запити будуть обслуговуватись у вказаній на рис. __ послідовності незалежно від порядку їх надходження.

Архітектура сучасних файлових систем

Рис. __

Розробники нових операційних систем прагнуть забезпечити користувача можливістю працювати одразу з декількома файловими системами. В такому випадку узагальнена файлова система має багаторівневу структуру, на верхньому рівні якої розташований перемикач файлової системи (в Win 9х це „встановлюваний” диспетчер файлової системи - Installable File System manager - IFS). Він забезпечує інтерфейс між запитами прикладної системи та конкретною файловою системою, до якої виконується звертання. Перемикач перетворює запити у формат, який сприймається наступним рівнем - рівнем файлових систем.

Кожний компонент рівня файлових систем виконаний у вигляді драйвера відповідної файлової системи і підтримує певну організацію файлової системи. Перемикач – це єдиний модуль, який може звертатись до драйвера файлової системи. Прикладна система не може звертатись до нього напряму. Кожний драйвер файлової системи в процесі власної ініціалізації реєструється у перемикача, передаючи йому таблицю точок входу, які будуть використовуватись при наступних звертаннях до файлової системи.

Для виконання своїх функцій драйвери файлових систем звертаються до підсистеми вводу-виводу. Ця підсистема – це складова частина файлової системи, яка відповідає за завантаження, ініціалізацію, та керування усіма модулями нижчих рівнів файлової системи. Звичайно ці модулі представляють собою драйвери портів, які безпосередньо працюють з апаратними засобами. Підсистема вводу-виводу повинна постійно знаходитись в основній пам’яті та організовувати сумісну роботу ієрархії драйверів пристроїв.

Велика кількість рівнів архітектури файлової системи забезпечує більшу гнучкість: драйвер може отримати керування на довільному етапі виконання запиту – від виклику прикладною програмою функції, яка працює з файлами, до того моменту, коли працюючий на самому низькому рівні драйвер пристрою починає проглядати регістри відповідного контролера.

Інтерфейс прикладного програмування API
(application program interface)

АРІ – призначений для використання прикладними програмами системних ресурсів ОС і функцій, які ОС реалізуються.

АРІ – описує сукупність функцій і процедур, які належать ядру або надбудовам ОС. Тобто АРІ – це набір функцій, які надаються системою програмування розробнику прикладної програми і які орієнтовані на організацію взаємодії результуючої прикладної програми із сукупністю програмних та апаратних засобів, в оточенні яких виконується результуюча програма. Сама результуюча програма породжується системою програмування, ґрунтуючись на коді вихідної програми, створеної програмістом, а також об’єктних модулів і бібліотек, які входять до складу системи програмування.

АРІ використовується не тільки прикладними, а також і системними програмами як в складі ОС, так і в складі системи програмування.

Функції АРІ дозволяють розробнику будувати результуючу прикладну програму таким чином, щоби використати засоби обчислювальної системи для виконання типових операцій. При цьому розробник програми не повинен створювати вихідний код для виконання цих операцій.

Програмний інтерфейс АРІ включає в себе не тільки самі функції, але і домовленості про їх використання, які регламентуються ОС, архітектурою обчислювальної системи і системою.

Існує декілька варіантів реалізації АРІ:

1. Реалізація на рівні ОС.

2. Реалізація на рівні системи програмування.

3. Реалізація на рівні зовнішньої бібліотеки процедур і функцій.

В кожному з цих варіантів розробнику надаються засоби для підключення функцій АРІ до вихідного коду програми і організації їх викликів. Об’єктний код функцій АРІ підключається до результуючої програми компонувальником при необхідності.

Перший варіант реалізації

За виконання функцій АРІ відповідальність несе ОС. Об’єктний код, який виконує функції, або безпосередньо входить до складу ОС (або навіть ядра ОС), або входить до складу бібліотек, які динамічно завантажуються, і які розроблені для даної ОС. Система програмування відповідає тільки за організацію інтерфейсу для виклику цього коду.

В цьому варіанті результуюча програма звертається безпосередньо до ОС. Тому досягається найбільша ефективність виконання функцій АРІ у порівнянні з усіма іншими варіантами реалізації АРІ.

Недолік: відсутність можливості переносу не тільки коду результуючої програми, але і коду вихідної програми. Програма, створена для одної архітектури обчислювальної системи, не зможе виконуватись на обчислювальній системі іншої архітектури навіть після того, якщо її об’єктний код буде повністю перебудовано.

Частіше за все система програмування не зможе виконати перебудову вихідного коду для нової архітектури обчислювальної системи.

Можна уніфікувати функції АРІ в різних ОС. Але є корпоративні інтереси.

Приклад: Для ОС Microsoft Windows – WinAPI.

Але навіть всередині цього корпоративного АРІ існує певна невідповідність, яка дещо обмежує переносимість програм між різними ОС типу Windows.

Приклад: АРІ – набір сервісних функцій ОС для MS-DOS, який реалізовано у вигляді набору підпрограм обслуговування програмних переривань.

Другий варіант реалізації

В цьому випадку функції АРІ надаються користувачу у вигляді бібліотеки функцій відповідної мови програмування. Система програмування надає користувачу бібліотеку відповідної мови програмування і забезпечує підключення до відповідної програми об’єктного коду, що відповідає за виконання цих функцій.

Ефективність АРІ буде нижче, ніж у попередньому варіанті. Це тому, що для виконання багатьох функцій АРІ бібліотека мови програмування повинна все одно виконати звертання до функцій ОС.

Але переносимість буде самою високою, оскільки синтаксис і семантика всіх функцій будуть строго регламентовані в стандарті мови. Вони залежать від мови і не залежать від архітектури обчислювальної системи. Тому для виконання прикладної програми на новій архітектурі обчислювальної системи досить заново побудувати код результуючої програми за допомогою відповідної системи програмування.

Але є нестандартні бібліотеки.

Третій варіант реалізації

В цьому випадку функції АРІ надаються користувачу у вигляді бібліотеки процедур і функцій, яка може бути створена стороннім розробником.

Система програмування відповідала тільки за те, щоби підключити об’єктний код бібліотеки до результуючої програми, причому зовнішня бібліотека може бути і такою, що динамічно завантажується (тобто завантажується під час виконання програми).

З точки зору ефективності цей метод найгірший, оскільки зовнішня бібліотека звертається як до функцій ОС, так і до функцій мови програмування.

З точки зору переносимості, то тут тільки одна вимога – зовнішня бібліотека, яка використовується, повинна бути допустимою в довільній з архітектур обчислювальних систем, на які орієнтована прикладна програма. Це можливо, якщо бібліотека відповідає деякому прийнятому стандарту, а система програмування підтримує цей стандарт.

Бібліотека графічного інтерфейсу XLib підтримує стандарт графічного середовища XWindow:

MFC (Microsoft foundation classes) (OC Windows);

VCL (Visual controls library), „Borland”;

CLX, „Borland” (OC Linux, OC Windows).

Як правило АРІ не стандартизовані. В кожному конкретному випадку набір викликів АРІ визначається, перш за все, архітектурою ОС та її призначенням.

Робляться спроби стандартизувати деякий базовий набір функцій, оскільки це суттєво полегшує перенос програм з одної ОС на іншу.

Приклад: стандарт POSIX. В ньому перераховано великий набір функцій, їх параметрів та значень, що повертаються. Стандартизуються не тільки звертання до АРІ, але і файлова система, організація доступу до зовнішніх пристроїв, набір системних команд.

Приклад: Внутрішній корпоративний стандарт Microsoft, WinAPI.

Win16, Win32_S, Win32, WinCE. З точки зору WinAPI, базова задача – вікно. Тобто він орієнтований на роботу в графічному середовищі.

Основи організації MS-DOS

Всю систему можна розділити на шість основних частин:

1. Система BIOS в ПЗП. Поставляється разом з машиною і може використовуватись будь-якою операційною системою. Функція BIOS полягає в обслуговуванні основних та найбільш фундаментальних операцій комп’ютера.

2. “Завантажуючий запис” диску. “Завантажуючий запис” – це дуже коротка і проста програма, що знаходиться на гнучкому диску або активному розділі HDD. Функція цієї програми полягає в запуску процесу завантаження ОС після включення або перезапуску комп’ютера. “Завантажуючий запис” зчитує ще два модулі ОС в пам’ять і вони завершують процес завантаження DOS.

3. Дисковий файл IBMBIO.COM завантажується в пам’ять завантажуючим записом і залишається в пам’яті під час роботи DOS. Це змінне доповнення до системи BIOS в ПЗП. IO.SYS (MSDOS) – модуль розширення базової системи вводу-виводу. Незалежні драйвери пристроїв – фізичний рівень DOS.

4. Дисковий файл IBMDOS.COM реалізує основні послуги DOS. Це “логічний” рівень вводу/виводу ОС. MSDOS.SYS (MSDOS) – модуль обробки переривань. Ці обидва файли є “прихованими” системними файлами. Імена цих файлів не включаються в заголовок диску, що викликається командою DIR.

5. Дисковий файл COMMAND.COM. Головна його функція – обробка команд, що вводяться користувачем. Команди DOS, які вважаються внутрішніми, реалізуються програмою COMMAND.COM. Вони поділяються на дві частини. Частина входить до IBMDOS.COM (MSDOS.SYS) інша до Процесора додаткових команд.

6. Всі зовнішні команди. Функції зовнішніх команд різні і програми, що їх реалізують, завантажуються в пам’ять тільки у випадку необхідності.

Зовнішні команди – це нерезидентні частини DOS, так як вони не знаходяться в пам’яті постійно. Файли IBMDOS.COM (IO.SYS), IBMDOS.COM (MSDOS.SYS) і драйвери пристроїв знаходяться в пам’яті постійно і утворюють резидентну частину ДОС.

Файли COMMAND.COM можна виділити в окрему категорію як напіврезидентну складову ДОС. “Завантажуючий запис” використовується тільки тимчасово і тому не є резидентною частиною ДОС.

Будова та функції основних складових ДОС

1. BIOS в ПЗП.

Базова система вводу-виводу в постійній пам’яті. Забезпечує найбільш прості та універсальні послуги ОС, пов’язані зі здійсненням вводу-виводу.

Змінюється тільки в тому випадку, коли змінам підлягає апаратна реалізація системи.

Система BIOS складається з кількох частин, більшість з яких є програми, а інші – це важливі таблиці даних.

Програма системи BIOS, яка виконується першою, є тестом функціонування. Вона перевіряє пам’ять і зовнішні пристрої, під’єднані до IBM/PC, як тільки буде увімкнено живлення комп’ютера. Чим більший об’єм пам’яті ЕОМ, тим довше йде тест. Тільки після цього може завантажитись ДОС.

Модуль ініціалізації BIOS читає Master Boot Record – головний завантажуючий запис.

Наступна частина BIOS, яка повинна виконуватись як програма запуску ОС – це програма виклику завантажувача ОС. Ця програма перевіряє, чи під’єднаний дисковід з гнучкими дисками і зчитує з дискети “завантажуючий запис”. Після зчитування “завантажуючого запису” програма запуску передає їй керування, щоб вона зчитала частини ОС, що залишились.

В ПЗП міститься багато інших програм. Сюди входять програми обслуговування всього стандартного периферійного устаткування IBM/PC (керування клавіатурою, дисплеєм, дискетами, асинхронним адаптером зв’язку, пристроєм друку та ін.)

2. Початкове завантаження – завантажуючий запис.

“Завантажуючий запис” необхідний для завантаження ДОС, він містить мінімум необхідних команд для зчитування і запуску основних частин ОС. Його основне призначення полягає просто в завантаженні файлів IO.SYS i MSDOS.SYS. “Завантажуючий запис” має розмір стандартного сектора на диску, 512 байтів. Для спрощення його роботи обидва файли розміщуються в визначених постійних місцях на диску. Це позбавляє програму завантаження від необхідності шукати їх в довіднику дискети. (Цим відрізняється “системна” дискета від звичайної).

3. Додаткові операції з пристроями: IO.SYS.

Цей файл призначений для доповнення функцій системи BIOS в ПЗП. Займається обслуговуванням операцій вводу-виводу або обслуговуванням пристроїв, що те ж саме. Це включає обробку різних подробиць, пов’язаних з функціонуванням пристроїв вводу-виводу, а також виявлення помилок та їх виправлення. Програми цього файлу можна легко змінити.

IO.SYS призначений для вирішення трьох задач, які не може вирішити BIOS ПЗП.

1) Налаштування на потреби конкретної системи, ДОС.

2) Виправлення будь-яких помилок в BIOS в ПЗП, якщо в цьому виявиться необхідність.

3) Обслуговування нових периферійних пристроїв. Коли під’єднується новий пристрій, програма-драйвер, що його обслуговує, повинна включатись в файл IO.SYS.

4. Основа ДОС: MSDOS.SYS.

Файл реалізує службові процедури ДОС, які поділяються на ті, які викликаються за допомогою власних переривань, і ті, які поділяють загальні переривання.

В ДОС перша група – переривання ДОС, друга група – виклики функцій. В обох випадках для їх виклику використовуються програмні переривання.

Програми обслуговування переривань – включають читання і запис секторів дискети, доступ до контролю за помилками ДОС і операціями клавіатури.

Виклики функцій ДОС – забезпечують, в основному, проміжний рівень обслуговування операцій вводу-виводу (ввід з клавіатури, вивід на екран дисплея, ввід/вивід по асинхронній лінії зв’язку і вивід на друк). Передбачені також логічні операції для дискет – відкриття та закриття файлів, пошук в довіднику файлів, видалення та створення файлів, читання та запис даних.

Ці процедури забезпечують практично всі елементарні операції, які можуть бути потрібні програмі для роботи з файлами та даними, що зберігаються в файлі, так щоб програмі не доводилось самостійно розшифровувати дані довідників, таблиць розміщення файлів і інше.

Більша частина цих службових процедур ДОС інтенсивно використовується програмами більш високого рівня ДОС.

5. Файл COMMAND.COM і внутрішні команди.

Файл має декілька функцій:

1. „Процесор команд”, що означає покладені на нього функції вводу команди, що набирається на клавіатурі, і визначення подальших дій. Щоб розпізнати внутрішні команди, COMMAND.COM містить таблицю імен команд. Якщо команди немає в таблиці внутрішніх команд, значить мається на увазі зовнішня команда, яку СOMMAND.COM буде шукати в зовнішньому файлі.

2. Друга частина COMMAND.COM (ініціатор процесору команд) використовується тільки тимчасово: при запуску системи вона здійснює пошук пакетного файлу AUTOEXEC.BAT і, якщо він знайдений, його виконання. Після виконання цієї функції, дана частина COMMAND.COM вже не потрібна.

3. Напіврезидентна. Включає інтерпретатор команд і програми, що реалізують внутрішні команди ДОС.

Інтерпретатор команд достатньо велика програма. Для швидкодії вигідно її мати в ОЗП, але небажано, щоб він займав місце в пам’яті постійно.

В MS/DOS ця проблема вирішена так. Ця частина COMMAND.COM розміщається в верхніх адресах пам’яті і дозволено іншим програмам витирати цю область пам’яті.

Коли виникає необхідність використовувати інтерпретатор команд, резидентна частина COMMAND.COM спочатку перевіряє, чи знаходиться інтерпретатор команд в пам’яті. Для цього вираховується контрольна сума тих комірок пам’яті, в яких він повинен знаходитись. Якщо сума не співпадає з очікуваною, то COMMAND.COM перезавантажується.

Програма завантаження і виконання зовнішніх команд, що знаходяться в файлах з розширенням імен .COM i .EXE викликається функцією ЕХЕС для завантаження вказаних програм в область користувача.

6. Зовнішні команди (транзитна частина DOS).

Ці команди називаються зовнішніми, тому що вони не включені до складу ДОС і не є резидентними в пам’яті ІВМ/РС. Замість цього, зовнішні команди зберігаються в програмних файлах на дискетах.

З одної точки зору, зовнішні команди це всього-навсього допоміжні програмні утиліти, які є корисними, але не є ОС.

Створення та включення нових програм таке ж як команд. Фактично це нові команди. В зв’язку з цим MS-DOS – відкрита система.

Керування пам’яттю

Керування пам’яттю – це забезпечення доступу до неї, її облік та розподілення між програмами. Функції керування пам’яттю відносяться до ОС. В DOS вбудовані тільки мінімальні засоби по керуванню пам’яттю. Всі інші засоби реалізовані як зовнішні драйвери і тому їх треба підключати до системи явно. DOS також підтримує певні команди, які мають безпосереднє відношення до керування пам’яттю.

У верхній області пам’яті логічно знаходяться відеопам’ять та постійна пам’ять з BIOS, а також можуть розміщуватись додаткові модулі постійної та оперативної пам’яті, які конструктивно знаходяться в адаптерах ПУ. Реально використовується невелика частина UMA. Це зарезервована пам’ять або область старших адрес DOS.

ХМА – 1М – UB–1; UB – кількість комірок (байтів) в адресному просторі мікропроцесора (або самого комп’ютера).

8088/86 – ША = 20 розрядів; UB = 1М; (ХМА ними не підтримується).

80286 – 80386SX – ША = 24 розряди; UB=16М;

80386/486 – ША = 32 розряди; UB=4Tбайта;

Якщо адресний простір допускає ХМА, то в ньому логічно може знаходитись розширена пам’ять (extended memory). (Як правило, стандартна АТ, включала всього 384Кбайт такої пам’яті. Разом 1Мбайт і сюди не входили модулі пам’яті з UMA).

DOS без додаткових драйверів може адресувати тільки 1Мбайт адресного простору. (Оскільки вона розглядалась для 8088/86.) Більш сучасні мікропроцесори вимушені емулювати цей простір із усіма обмеженнями. Це реальний режим. В захищеному режимі використовуються всі можливості сучасних МП. Але в цей режим переключитись не просто, ще складніше повернутися з нього в реальний режим без втрати даних.

Вільні фрагменти UMA адресуються безпосередньо. В ОС, в яких використовується захищений режим роботи МП (DOS/Windows, Windows NT, ОS/2, UNIX та ін.) розширена пам’ять доступна так само як і стандартна. Але між двома областями однорідної пам’яті залишається UMA. Тобто не виключається фрагментація оперативної пам’яті. Недоліки концепції: UMA необхідно включити в СМА!!! Але зміни приведуть до несумісності.

Пам’ять розподіляється блоками. Блок – неперервний фрагмент. Перші 16байт кожного блоку пам’яті відводиться під блок керування пам’яттю МСВ – Memory Control Block – описує розмір блоку пам’яті та вказує програму, якій виділений цей блок, а також забезпечує зв’язок з наступним блоком пам’яті. Таким чином, всі МСВ, тобто блоки пам’яті, зв’язуються у ланцюжок, що забезпечує можливість керування пам’яттю (виділення та звільнення).

Коли DOS запускає програму, вона, тобто DOS, спочатку виділяє блок пам’яті для копії свого оточення (Environment), яка передається програмі, а потім весь залишок пам’яті виділяється для самої програми.

Сформовані блоки для одної програми не обов’язково мають бути суміжними. Блоки пам’яті завжди виділяються на початку її вільної області, тому, якщо пам’ять не фрагментована, блок з оточенням та блок з кодом програми будуть суміжними. Разом з оточенням програмі, яка виконується, передається повна специфікація програмного файлу, яка доточується в кінець оточення і заміняє відповідний рядок для батьківського процесу. Тому розмір копії оточення, як правило, не співпадає за розміром оригіналом.

Програма при виконанні може зменшити розмір виділеного під її код блоку, а резидентна програма зобов’язана це зробити (інакше не виконуються інші програми). Після завершення нерезидентної програми зайняті нею блоки пам’яті звільнюються. Але, якщо програма має залишитись резидентною, блоки з її оточенням і кодом залишаються у пам’яті. Вони будуть звільнені тільки при явному вивантаженні програми.

Для вилучення резидентної програми з пам’яті можна використати спеціальні програмні засоби. Але якісна програма повинна уміти сама себе вивантажити, тобто самоліквідуватись.

DOS забезпечує можливість динамічного керування пам’яттю для розміщення інформаційних об’єктів програми, яка використовується. Програма може зробити запит на:

- визначення розміру найбільшого блоку, який можна виділити програмі;

- виділення блоку пам’яті заданого розміру;

- звільнення блоку пам’яті;

- зміну розміру вже виділеного блоку пам’яті як в сторону збільшення, так і в сторону зменшення.

Відображена пам’ять

Концепція розширеної пам’яті (Expanded memory) належить фірмам Lotus, Intel, Microsoft (LIM).

LIM-EMS – Специфікація відображеної пам’яті (Expanded memory Specification).

Використовується як правило для збереження даних.

ЕМS 3.2 – до 8Мбайт.

ЕМS 4.0 –до 32Мбайт. Допускає сторінки нестандартного розміру (більші або менші 16 Кбайтів, але такі, щоб в одній нестандартній сторінці вміщувалось ціле число стандартних, або щоб в одній стандартній було ціле число нестандартних).

У ХТ, АТ використовується спеціальна плата пам’яті, що відповідає вимогам EMS і програмний драйвер, який керує відображеною пам’яттю. Драйвер відображеної пам’яті – ЕММ (Expanded Memory Manager).

На комп’ютерах з мікропроцесором 386 відображена пам’ять емулюється за допомогою драйверу ЕММ386.ЕХЕ (набір функцій, що доступні через переривання 21h).

Як і стандартна, розширена пам’ять також виділяється блоками. Блок виділяється за запитом від програми, яка вказує число потрібних сторінок. Програма, яка видала запит, отримує в своє розпорядження обробник (handle) або маніпулятор виділеного блоку. Цей обробник використовується у всіх операціях читання з блоку та запису в нього.

Обробник – невелика інформаційна структура, яка зберігає всі необхідні дані про блок.

Таким чином, обмін даними між стандартною та відображеною пам’яттю на логічному рівні реалізується аналогічно обміну між стандартною та зовнішньою пам’яттю.

Читайте також:

1. I. ОБРАЗОВАНИЕ СОЕДИНЕННЫХ ШТАТОВ 14 страница
2. А. В. Дудник 1 страница
3. А. В. Дудник 10 страница
4. А. В. Дудник 11 страница
5. А. В. Дудник 12 страница
6. А. В. Дудник 2 страница
7. А. В. Дудник 3 страница
8. А. В. Дудник 4 страница
9. А. В. Дудник 5 страница
10. А. В. Дудник 6 страница
11. А. В. Дудник 7 страница
12. А. В. Дудник 8 страница

Переглядів: 506