3. Монолитная архитектура

Организация монолитной системы представляет собой структуру, у ко­торой ОС написана в виде набора процедур, каждая из которых может вызы­вать другие, когда ей это нужно. При использовании такой техники каждая процедура системы имеет строго определенный интерфейс в терминах па­раметров и результатов, и каждая имеет возможность вызвать любую дру­гую для выполнения необходимой для нее работы.

Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их в единый объектный файл с помо­щью компоновщика. Здесь, по существу, полностью отсутствует сокрытие деталей реализации - каждая процедура видит любую другую процедуру (в отличие от структуры, содержащей модули, в которой большая часть ин­формации является локальной для модуля и процедуры модуля можно вы­звать только через специально определенные точки входа).

Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым операци­онной системой, параметры помещаются в строго определенные места - ре­гистры или стек, после чего выполняется специальная команда прерыва­ния, известная как вызов ядра или вызов супервизора. Эта команда пере­ключает машину из режима пользователя в режим ядра и передает управле­ние операционной системе. Затем операционная система проверяет пара­метры вызова, чтобы определить, какой системный вызов должен быть вы­полнен. После этого операционная система обращается к таблице как к мас­сиву с номером системного вызова в качестве индекса. В k-м элементе таб­лицы содержится ссылка на процедуру обработки системного вызова. Такая организация операционной системы предполагает следующую структуру:

1. Главная программа, которая вызывает требуемую служебную проце­дуру.

2. Набор служебных процедур, выполняющих системные вызовы.

3. Набор утилит, обслуживающих служебные процедуры. В этой модели для каждого системного вызова имеется одна служебная процедура. Утилиты выполняют функции, которые нужны нескольким слу­жебным процедурам. Деление процедур на три уровня показано на рис. 1.

Рисунок 1. – Модель монолитной системы

В силу преимуществ объектно-ориентированного подхода приложения создаются на его основе, используя один из языков программирования, наилучшим образом поддерживающий этот подход. Архитектуры же классиче­ских операционных систем реального времени основаны на архитектурах UNIX систем и используют традиционный процедурный подход к програм­мированию. Сочетание объектно-ориентированных приложений и проце­дурных операционных систем имеет ряд недостатков:

1. Происходит разрыв парадигмы программирования: в едином рабо­тающем комплексе (приложение + ОСРВ) разные компоненты используют разные подходы к разработке программного обеспечения.

2. Не используются все возможности объектно-ориентированного под­хода.

3. Возникают некоторые потери производительности из-за разного ти­па интерфейсов в ОСРВ и приложении.

Естественно, возникает идея строить саму СРВ, используя объектно-ориентированный подход. При этом:

- как приложение, так и операционная система полностью объектно-ориентированны и используют все преимущества этого подхода;

- приложение и ОСРВ могут быть полностью интегрированы, посколь­ку используют один объектно-ориентированный язык программирования;

- обеспечивается согласование интерфейсов ОСРВ и приложения;

- приложение может «моделировать» ОСРВ для своих потребностей, заказывая нужные ему объекты;

- единый комплекс (приложение + ОСРВ) является модульным и легко модернизируемым. Идея реализована в ОСРВ SoftKernel, целиком написан­ной на C++. ОСРВ с монолитной архитектурой можно представить в виде:

- прикладного уровня: состоящего из работающих прикладных процес­сов;

- системного уровня: состоящего из монолитного ядра операционной системы, в котором можно выделить следующие части:

а) интерфейс между приложениями и ядром (API);

б) собственно ядро системы;

в) интерфейс между ядром и оборудованием (драйверы устройств). API в таких системах играет двойную роль:

1) управляет взаимодействием прикладных процессов и системы;

2) обеспечивает непрерывность выполнения кода системы (отсутствие переключения задач во время исполнения кода системы).

Основным преимуществом монолитной архитектуры является ее отно­сительная быстрота работы по сравнению с другими архитектурами. Однако, достигается это, в основном, за счет написания значительных частей систе­мы на ассемблере.

Недостатки монолитной архитектуры:

1. Системные вызовы, требующие переключения уровней привилегий (от пользовательской задачи к ядру), должны быть реализованы как преры­вания или ловушки (специальный тип исключений). Это значительно увеличивает время их работы.

2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управ­ления из-за работы низкоприоритетной задачи. Например, низкоприоритет­ная задача запросила выделение памяти, сделала системный вызов, до окон­чания которого сигнал активизации высокоприоритетной задачи не сможет ее активизировать.

3. Сложность переноса на новые архитектуры процессора из-за значи­тельных ассемблерных вставок.

4. Негибкость и сложность развития: изменение части ядра системы требует его полной перекомпиляции.