 |
Монолитные операционные системы
|
|
|
|
Монолитные операционные системы являются прямой противоположностью микроядерным. В монолитной ОС очень трудно удалить один из уровней многоуровневой модульной структуры. Добавление новых функций и изменение существующих для монолитных ОС требует очень хорошего знания всей архитектуры ОС и чрезвычайно больших усилий. Для преодоления этих трудностей используется технология «сервер – клиент».
Модель сервер – клиент предполагает наличие программного компонента, являющегося потребителем какого-либо сервиса – клиента, и программного компонента, поставщика этого сервиса – сервера. Взаимодействие между сервером и клиентом стандартизуется, сервер может обслуживать клиентов, реализованных различными способами. Главное требование – использование единообразного интерфейса. Инициатором обмена является клиент, который посылает запрос серверу. Один и тот же программный компонент может быть и клиентом, и сервером.
При поддержке монолитных ОС возникает ряд проблем, связанных с тем, что все функции микроядра работают в едином адресном пространстве:
- опасность возникновения конфликта между различными частями ядра;
- сложность подключения к ядру новых драйверов.
Преимущество микроядерной архитектуры перед монолитной заключается в том, что каждый компонент системы представляет собой самостоятельный процесс, запуск и останов которого не отражается на работоспособности остальных процессов.
3. Принципы построения интерфейсов операционных систем.
Операционная система – интерфейс между аппаратурой компьютера и пользователем с его задачей.
Интерфейс операционных систем – специальные интерфейсы системного и прикладного программирования, предназначенные для выполнения следующих задач:
|
|
|
1) управление процессами, которое включает в себя следующий набор основных функций:
· запуск, приостанов и снятие задачи с выполнения;
· задание или изменение приоритета задачи;
· взаимодействие задач между собой (сигналы, семафоры, очереди, конвейеры, почтовые ящики);
· удаленный вызов подпрограмм;
2) управление памятью:
· запрос на выделение блока памяти;
· освобождение памяти;
· изменение параметров блока памяти;
· отображение файлов на память;
3) управление вводом/выводом:
· запрос на управление виртуальными устройствами;
· файловые операции.
Пользовательский интерфейс ОС реализуется с помощью специальных программных модулей, которые принимают его команды на соответствующем языке и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Обычно эти модули называются интерпретатором команд.
Имеются два основных подхода к управлению задачами:
1) порождаемая задача наследует все ресурсы задачи-родителя;
2) при порождении нового процесса ресурсы для него запрашиваются у операционной системы.
Обращение к операционной системе в соответствии с имеющимися API может осуществляться:
· посредством вызова подпрограммы с передачей ей необходимых параметров;
· через механизм программных прерываний.
Интерфейс прикладного программирования предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций.
Термин API (application program interface, интерфейс прикладного программирования):
· API как интерфейс высокого уровня, принадлежащий к библиотекам RTL (run time library, библиотека во время выполнения);
· API прикладных и системных программ, входящих в поставку операционной системы;
· прочие API.
API представляет собой набор функций, предоставляемых системой программирования разработчику прикладной программы и ориентированных на организацию взаимодействия результирующей программы с целевой вычислительной системой (совокупность аппаратных и программных средств, в окружении которых выполняется результирующая программа).
|
|
|
API используется не только прикладными, но и многими системными программами как в составе ОС, так и в составе системы программирования.
Программный интерфейс API включает в себя не только сами функции, но и соглашения об их использовании, которые зависят от:
· операционной системы;
· архитектуры целевой вычислительной системы;
· системы программирования.
Варианты реализации API:
· на уровне ОС;
· на уровне системы программирования;
· на уровне внешней библиотеки процедур и функций.
В каждом из этих вариантов разработчику предоставляется возможность подключить функции API к исходному коду программы и организовать их вызов.
Возможности API можно оценить со следующих позиций:
· эффективность выполнения функций API (скорость выполнения, объем вычислительных ресурсов);
· широта предоставляемых возможностей;
· зависимость прикладной программы от архитектуры целевой вычислительной системы.
В идеале набор функций API должен:
· выполняться с наивысшей эффективностью;
· предоставлять пользователю все возможности современных ОС;
· иметь минимальную зависимость от архитектуры вычислительной системы.
4. Требования к операционным системам реального времени (Отрабатывается самостоятельно).
Система реального времени должна давать отклик на непредсказуемые внешние воздействия в течение предсказуемого интервала времени. Свойства операционных систем реального времени:
· ограниченное время отклика, реакция на событие гарантированно последует до наступления крайнего срока;
· одновременность обработки. Даже если возникает более одного события одновременно, временные ограничения для всех событий должны быть выдержаны. В системе реального времени должен присутствовать параллелизм, который достигается использованием нескольких процессоров и/или многозадачного подхода.
Примеры систем реального времени:
· системы управления атомными электростанциями;
|
|
|
· системы управления технологическими процессами;
· системы медицинского мониторинга;
· системы управления вооружением;
· системы космической навигации;
· системы разведки;
· системы управления лабораторными экспериментами;
· системы управления автомобильными двигателями;
· робототехника;
· телеметрические системы управления;
· системы антиблокировки тормозов;
· системы сигнализации и т.д.
Различают системы «мягкого» и «жесткого» реального времени. Различия зависят от требований к системе:
· в «жесткой» системе нарушение временных ограничений не допустимо;
· в «мягкой» системе нарушение временных ограничений нежелательно.
Основные требования к операционной системе реального времени:
1) мультипрограммность и многозадачность (многопоточность). ОС должна активно использовать прерывания для диспетчеризации. Максимальное время выполнения того или иного действия должно быть известно заранее и соответствовать требованиям приложения;
2) приоритеты задач (потоков). Проблема, какой задаче ресурс требуется больше всего. В идеальной ситуации ОСРВ отдает ресурс потоку или драйверу с ближайшим крайнем сроком завершения. Чтобы реализовать этот принцип ОС должна знать, сколько времени требуется каждому процессу для его завершения. Таких ОС нет, так как их очень сложно реализовать, поэтому вводится понятие уровня приоритета для задачи и временные ограничения сводятся к приоритетам;
3) наследование приоритетов. ОСРВ должна допускать наследование приоритета, то есть повышение уровня приоритета потока до уровня приоритета потока, который его вызывает. Наследование означает, что блокирующий ресурс поток наследует приоритет потока, который он блокирует;
4) синхронизация процессов и задач. Так как задачи разделяют данные (ресурсы) и должны сообщаться друг с другом, то должны существовать механизмы блокирования и коммуникации. Эти системные механизмы должны быть всегда доступны процессам, требующим реального времени;
5) предсказуемость. Времена выполнения системных вызовов и временные характеристики поведения системы в различных обстоятельствах должны быть известны разработчику.
Разработчик ОСРВ должен привести следующие характеристики:
· задержку прерывания, время от момента прерывания до момента запуска задачи;
· максимальное время выполнения каждого системного вызова;
· максимальное время маскирования прерываний драйверами и ОС.
|
|
|
