
- •Основные параметры и механизмы
- •Базовые концепции построения операционных систем реального времени
- •Монолитная архитектура
- •Модульная архитектура на основе микроядра
- •Объектная архитектура на основе объектов-микроядер
- •Интерфейсы вс
- •Принципы функционирования интерфейса
- •Программное обеспечение интерфейса
- •Аппаратные средства интерфейса
- •Виды интерфейсов ос
Монолитная архитектура
Организация монолитной системы представляет собой структуру, у которой ОС написана в виде набора процедур, каждая из которых может вызывать другие, когда ей это нужно. При использовании такой техники каждая процедура системы имеет строго определенный интерфейс в терминах параметров и результатов, и каждая имеет возможность вызвать любую другую для выполнения необходимой для нее работы.
Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их в единый объектный файл с помощью компоновщика. Здесь, по существу, полностью отсутствует сокрытие деталей реализации - каждая процедура видит любую другую процедуру (в отличие от структуры, содержащей модули, в которой большая часть информации является локальной для модуля и процедуры модуля можно вызвать только через специально определенные точки входа).
Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым операционной системой, параметры помещаются в строго определенные места - регистры или стек, после чего выполняется специальная команда прерывания, известная как вызов ядра или вызов супервизора. Эта команда переключает машину из режима пользователя в режим ядра и передает управление операционной системе. Затем операционная система проверяет параметры вызова, чтобы определить, какой системный вызов должен быть выполнен. После этого операционная система обращается к таблице как к массиву с номером системного вызова в качестве индекса. В k-м элементе таблицы содержится ссылка на процедуру обработки системного вызова. Такая организация операционной системы предполагает следующую структуру:
1. Главная программа, которая вызывает требуемую служебную процедуру.
2. Набор служебных процедур, выполняющих системные вызовы.
3. Набор утилит, обслуживающих служебные процедуры. В этой модели для каждого системного вызова имеется одна служебная процедура. Утилиты выполняют функции, которые нужны нескольким служебным процедурам. Деление процедур на три уровня показано на рис. 1.
Рисунок 1. – Модель монолитной системы
В силу преимуществ объектно-ориентированного подхода приложения создаются на его основе, используя один из языков программирования, наилучшим образом поддерживающий этот подход. Архитектуры же классических операционных систем реального времени основаны на архитектурах UNIX систем и используют традиционный процедурный подход к программированию. Сочетание объектно-ориентированных приложений и процедурных операционных систем имеет ряд недостатков:
1. Происходит разрыв парадигмы программирования: в едином работающем комплексе (приложение + ОСРВ) разные компоненты используют разные подходы к разработке программного обеспечения.
2. Не используются все возможности объектно-ориентированного подхода.
3. Возникают некоторые потери производительности из-за разного типа интерфейсов в ОСРВ и приложении.
Естественно, возникает идея строить саму СРВ, используя объектно-ориентированный подход. При этом:
- как приложение, так и операционная система полностью объектно-ориентированны и используют все преимущества этого подхода;
- приложение и ОСРВ могут быть полностью интегрированы, поскольку используют один объектно-ориентированный язык программирования;
- обеспечивается согласование интерфейсов ОСРВ и приложения;
- приложение может «моделировать» ОСРВ для своих потребностей, заказывая нужные ему объекты;
- единый комплекс (приложение + ОСРВ) является модульным и легко модернизируемым. Идея реализована в ОСРВ SoftKernel, целиком написанной на C++. ОСРВ с монолитной архитектурой можно представить в виде:
- прикладного уровня: состоящего из работающих прикладных процессов;
- системного уровня: состоящего из монолитного ядра операционной системы, в котором можно выделить следующие части:
а) интерфейс между приложениями и ядром (API);
б) собственно ядро системы;
в) интерфейс между ядром и оборудованием (драйверы устройств). API в таких системах играет двойную роль:
1) управляет взаимодействием прикладных процессов и системы;
2) обеспечивает непрерывность выполнения кода системы (отсутствие переключения задач во время исполнения кода системы).
Основным преимуществом монолитной архитектуры является ее относительная быстрота работы по сравнению с другими архитектурами. Однако, достигается это, в основном, за счет написания значительных частей системы на ассемблере.
Недостатки монолитной архитектуры:
1. Системные вызовы, требующие переключения уровней привилегий (от пользовательской задачи к ядру), должны быть реализованы как прерывания или ловушки (специальный тип исключений). Это значительно увеличивает время их работы.
2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управления из-за работы низкоприоритетной задачи. Например, низкоприоритетная задача запросила выделение памяти, сделала системный вызов, до окончания которого сигнал активизации высокоприоритетной задачи не сможет ее активизировать.
3. Сложность переноса на новые архитектуры процессора из-за значительных ассемблерных вставок.
4. Негибкость и сложность развития: изменение части ядра системы требует его полной перекомпиляции.