Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.1. Учебное пособие
.pdf
3.2. Архитектура ОС РВ
51
Здесь следует напомнить, что большинство современных операционных систем сейчас построено на базе UNIX, так что они в той или иной
мере переняли особенности этого стандарта (POSIX) и используют традиционный подход к программированию.
Монолитная архитектура
Монолитная архитектура операционной системы позволяет ей быть
одной большой программой, так что строится она из огромного числа процедур и функций.
В таком случае компонентами системы являются не отдельные модули, а программные компоненты одной и той же большой программы. Такая структура организации ОС РВ носит называние монолитного ядра
(monolithic kernel).
В общем случае структуру системы с монолитной архитектурой составляют следующие элементы:
компоненты прикладного уровня, представляющие собой рабо-
тающие прикладные процессы;
компоненты системного уровня, входящие в состав монолитного
ядра операционной системы и состоящие из трех частей: интерфейсы
между приложениями и ядром ОС; само по себе ядро системы; драйверы
устройств.
Программный интерфейс, т.е. API, занимается управлением взаимодействия прикладных задач и обеспечением непрерывности выполнения
программного кода операционной системы. Здесь имеется в виду то, что
программный код ядра операционной системы или ее важных модулей не
должен прерываться выполнением кода других приложений.
Пример структуры такой операционной системы показан на рис. 4.
Это все обеспечивается благодаря процедурному подходу к решению задач. Монолитная система представляет собой набор вызываемых
процедур. Вызываться процедуры могут как из системы, так и из других
процедур. Все процедуры имеют один уровень приоритета, так что они все
считаются привилегированными.
При этом в монолитных ОС ядро как бы “масштабируется” на всю
систему, так что все процедуры, решающие системные “проблемы”, и считаются самой системой, т.е. одной огромной программой.
3. Архитектура ОС РВ
52
Рис. 4. Пример структуры ОС РВ с монолитной архитектурой
Для многих монолитных ОС считается нормальной сборка всей си-
стемы как единой программы на каком-то отдельном компьютере и другой
операционной системы, установленной там. При этом, используя специальные средства сборки, можно настроить процесс, выбрав отдельно определенное оборудование, состав программ, драйверы, программы и протоколы, которые будет поддерживать собираемая система на целевом оборудовании (для которого она собирается).
Так как ядро системы практически всегда загружается в оперативную память, то при сборке нужно грамотно оптимизировать процесс, исключив компоненты, которые не будут нужны в целевой системе. Этот процесс так же повышает надежность собираемой системы, ее стабильность
работы и оптимальность расходования ресурсов.
Такой способ сборки операционной системы, как и сам монолитный
подход к структуре ОС, является старейшим и используется до сих пор.
Например, можно пересобрать Linux-систему на одном компьютере и перенести на другой методом клонирования, можно на одной машине иметь
несколько ядер ОС разных версий и поколений и переключаться между
ними. Можно собрать ОС на “чистой” машине, загрузившись с USBнакопителя или LiveCD, можно уже установленную на машине среду разработки Lazarus пересобрать прямо там же, но с другим составом модулей
и с оптимизацией под архитектуру процессора и так далее.
3.2. Архитектура ОС РВ
53
Следует помнить, что монолитная система имеет определенную
структуру со “вкраплениями инородных тел”. Эти программные агенты несколько выделяются по своему составу и принципам работы от системных
модулей и называются сервисными процедурами.
Сервисные процедуры срабатывают после системных вызовов и работают в привилегированном режиме. Пользовательские программы, естественно, работают в не привилегированном режиме.
Иногда появляется необходимость временного изменения приоритета
программы, т.е. переход с одного уровня привилегий в другой. Для этого
также существуют специальные программы, которые анализируют ситуацию, определяют возможность такого перехода, корректность данных, доступность ресурсов, возможность вызова, а затем передают управление соответствующей сервисной процедуре уже с новым уровнем привилегий.
Качественным преимуществом монолитной ОС по сравнению с
остальными архитектурами является ее скорость работы. В основном этот
эффект достигается за счет написания большой части системы на языке Ассемблера. Управляющие конструкции и бизнес-логика системы пишется на
языках высокого уровня, а критические с точки зрения производительности
места – на языке низкого уровня.
В качестве основных недостатков монолитной архитектуры можно
выделить следующие:
системные вызовы и их вспомогательные процедуры оформля-
ются как прерывания и ловушки, так как они должны изменять свой уровень привилегий. То же самое касается и программных интерфейсов (API).
А так как выполнение этих механизмов – это дополнительные затраты времени и мощности процессора, то большое количество таких элементов программного обеспечения в конечном счете приводит к снижению производительности;
ядро системы априори не может быть прервано пользовательской
задачей, следовательно, даже высокоприоритетная задача не может быть
выполнена из-за работы приоритетной;
вследствие большого числа ассемблерных вставок, перенос мо-
нолитной ОС между архитектурами процессоров чрезвычайно сложен. Это
3. Архитектура ОС РВ
54
логично, так как язык Ассемблера специфичен для каждого типа процессора и ориентирован на выполнение команд, имеющих аппаратное ускорение внутри ядра процессора;
сложность развития и модификации в общем. Для каждого из-
менения, модификации или исправления требуется перекомпиляция всей
системы.
Слоистая или многоуровневая ОС
Для повышения гибкости и структурированности ОС, они посте-
пенно разбивались на обособленные части, выделялись микроядра или
слои системы.
Уровни системы снабжались связями, состав, структура и возмож-
ности которых строго определялись в момент проектирования и разработки.
Для каждого уровня ОС со временем установилось правило: про-
граммные компоненты уровня Х могут иметь доступ только к объектам
уровня Х или Х-1.
Прикладное программное обеспечение здесь может получить доступ
к аппаратуре не только через ядро системы и ее сервисы, но и минуя дополнительные уровни. Соответственно, был выделен отдельный уровень
hardware, который является самым “нижним” и обеспечивает доступ к аппаратным ресурсам. В современных системах он называется HAL
(Hardware Abstraction Layer).
Соответственно, самым высшим является уровень представления
пользователя, т.е. интерфейс.
Чем ниже уровень, тем более привилегированные модули в нем расположены и тем более важные действия они могут выполнять.
Впервые такой подход был показан на примере системы MS-DOS,
разработанной в 1968 г. в Техническом университете Эйндховена.
Пример многоуровневой архитектуры показан на рис. 5.
Многоуровневая архитектура операционной системы обеспечивает
большую степень надежности и предсказуемости, позволяет более быстро
обращаться к аппаратуре.
3.2. Архитектура ОС РВ
55
Рис. 5. Многоуровневая архитектура ОС
Слоеные архитектуры легче пишутся и реализуются на практике.
Очень важным моментом является “абстракция”. Это значит, что,
имея программный интерфейс между слоями, мы не задумываемся, как
этот слой реализован внутри, мы просто принимаем правила общения с
этим слоем. Для нас соседний слой – это просто “черный ящик”, имеющий
вход и выход.
Слоеные системы легче тестируются, чем монолитные. Если
найдены ошибки, то они однозначно локализованы в тестируемом слое, так
как слои не вызывают так называемый “side effect”, т.е. не изменяют напрямую состояние соседних слоев.
Слои легко модифицируются, так как при необходимости изменения
вносятся только в целевой слой, не затрагивая остальные.
Слоеные системы тяжелее в разработке и проектировании. Ведь
нужно не просто разделить функции ОС между слоями, нужно еще и грамотно проработать программный интерфейс между ними, определить порядок следования слоев по приоритету и выполнить модульное тестирование.
3. Архитектура ОС РВ
56
Другой проблемой слоеных ОС является отсутствие явной многоза-
дачности, так как необходимо выполнять переключение не только между
задачами, но и между слоями.
И еще одной важной проблемой является необходимость “проходить” через слои, если выполняемая задача требует выполнения другой задачи, расположенной в другом слое. Например, обращение к аппаратуре
фактически вызывает необходимость прохождения (т.е. проброски вызова)
сразу всех слоев от текущего до HAL.
Микроядерная архитектура ОС
Микроядерная архитектура (microkernel architecute) операционных
систем также иногда называется “модульной”. Этот подход к построению
ОС появился в результате попыток убрать такое “узкое” место ОС как программные интерфейсы API. Другой причиной является необходимость
частой модернизации и переноса системы на новые типы процессоров. В
таком случае API обеспечивает связь прикладных процессов и обслуживающего их модуля: менеджера процессов.
Выделение микроядер из операционной системы обусловлено процессом распределения функций между пользовательским уровнем представления задач и системным. В таком случае пользовательское программное обеспечение постепенно становилось самостоятельным, забирая некоторые функции из ядра.
Естественно, что в этом процессе появилась необходимость обмениваться данными между разными видами программ. При этом чем “стандартнее” программный интерфейс связи, тем меньше.
Сейчас этот подход постоянно применяется при построении программного обеспечения. Различные модули соединяют между собой не чистыми или прямыми вызовами функций с передачей управления, а специализированным программным интерфейсом, который фиксируется в одном
состоянии и не меняется в ходе разработки. Интерфейс дает возможность
воспринимать модуль как “черный ящик” и скрывать реализацию алгоритмов от их потребителей, оставляя только правила и форматы обращения.
Этот же принцип начал применяться в микроядерной архитектуре.
Именно микроядро играло роль программного интерфейса между пользовательским ПО и аппаратурой.
3.2. Архитектура ОС РВ
57
Микроядро работает в привилегированном режиме и обеспечивает
взаимодействие между программами и еще несколько дополнительных и
очень важных функций:
планирование использования ресурсов микропроцессора;
первичную обработку прерываний;
базовые операции ввода-вывода;
базовое управление оперативной памятью;
базовое управление системными контроллерами.
Все компоненты “вне” микроядра общаются между собой именно
через микроядро, так что они проектируются как отдельные модули – им
не нужно быть тесно связанными между собой. В любой момент один из
модулей может выключиться и подключиться снова – существенного сбоя
не произойдет: просто исчезнет и появится еще один потребитель программного интерфейса.
Микроядерная архитектура операционной системы существенно облегчает процесс проектирования и внедрения программных компонент.
Нет необходимости перекомпилировать ядро системы после внесения каких-либо второстепенных изменений. Если поменялся старый модуль или
добавился новый: все они просто подключаются к интерфейсу. Если модуль допустил отказ, то его легко можно отключить от интерфейса, отладить, пересобрать и запустить снова, подключив к тому же самому интерфейсу микроядра. При этом, естественно, перезапуска всей операционной
системы в целом не произойдет.
Тот же принцип работает и с “другой” стороны – со стороны аппаратуры. Если поменяется “железо”, то вместе с некоторыми низкоуровневыми процедурами обработки изменится лишь драйвер устройства, который также является отдельным модулем. Перезагрузка драйвера и подключение его к интерфейсу решает проблемы модернизации оборудования.
Операционные системы реального времени с микроядерной архитектурой отказоустойчивы. Время непрерывной работы без отказов у таких
систем по статистике больше, чем у других, например, монолитных.
Микроядро защищено от влияния остальных модулей операционной
системы. Существуют даже несколько слоев защиты со своими элементами. В общем случае, работают машинно-зависимые модули, менеджеры
ресурсов, шлюзы.
3. Архитектура ОС РВ
58
Интересно так же то, что вроде бы “системные” модули, типа мене-
джеры ресурсов, запускаются в пользовательском режиме и “оформляются” в системе как обычные модули.
Это значит, что в микроядерной архитектуре “вертикальное” распо-
ложение уровней (иерархия) или слоев заменяется на “горизонтальное” с
разделением модулей.
Внешне, по отношению к микроядру, все компоненты операционной
системы реализуются как обслуживающие процессы. Они взаимодействуют между собой как обычные процессы: сообщениями.
Сообщения передаются через микроядро, как это показано на рис. 6.
Рис. 6. Микроядерная архитектура
Поскольку основной задачей этих компонент операционной системы является обслуживание запросов приложений пользователей, а
также утилит и системных программ, менеджеров ресурсов и проч., то они
называются “серверами” ОС, т.е. модулями, которые обслуживают других
“клиентов” в данной ОС.
В современных версиях микроядерных ОС микроядро играет одновременно две роли:
управляет взаимодействием частей системы;
обеспечивает непрерывное управление кодом системы.
Для того чтобы микроядерная ОС была сравнима по скорости с монолитной операционной системой, а иногда даже ее и превосходила, тре-
3.2. Архитектура ОС РВ
59
буется аккуратное проектирование системы и ее сервисов, корректное разбиение на компоненты, правильное выделение функций, составляющих ОС
элементов, чтобы минимизировать обменные процессы.
Компоненты микроядерной ОС РВ также ускоряются за счет исполь-
зования языка Ассемблера. Вследствие этого уменьшаются проблемы переносимости ядра, но остается проблема адаптации к аппаратуре.
Смешанные или гибридные системы
Каждый подход к реализации ОС РВ имеет свои достоинства и недостатки. Поэтому “чистых” систем практически нет. Сейчас в основном
применяется комбинированный подход. Для запуска ОС с монолитным ядром может использоваться микроядро. Микроядро обеспечивает управление виртуальной памятью, работу драйверов и системного ПО. Все остальные функции отдаются на откуп системному программному обеспечению
и монолитному ядру.
Примером такой смешанной ОС может являться Windows NT. Это
достаточно старая система, но она хорошо известна во всем мире. Микроядро Windows NT занимает много места по сравнению с аналогами – более
1 Мб, хотя и называется в некоторых источниках “микроядром”. Его компоненты располагаются в особой области оперативной памяти, называемой
“вытесняемой” и взаимодействуют друг с другом при помощи механизма
передачи сообщений, как это и принято в микроядерных ОС. В это же самое время все компоненты ядра работают в едином адресном пространстве,
используют общие структуры данных и другие ресурсы. А это уже черта
операционной системы с монолитным ядром.
Кроме всего прочего, в Windows NT существуют режимы работы
ядра – это еще одна черта монолита. Эта особенность реализации была введена компанией Microsoft вследствие соображений практичности и коммерческой выгоды. В компании тех лет считали, что применение чисто
микроядерного дизайна ОС неэффективно.
Объектная архитектура на основе микроядер
Это неклассический подход к проектированию и реализации операционных систем. Традиционные подходы к разработке ОС не являются чисто объектно-ориентированными.
3. Архитектура ОС РВ
60
Как известно, объектно-ориентированный подход (ООП) основыва-
ется на дроблении программы на сущности – объекты, каждый из которых
имеет свою зону ответственности, свой интерфейс для вызова и управления, свои скрытые методы и данные, а также возможность наследоваться и
изменяться при наследовании.
ОС, реализуемая с такими чертами, также использует понятие объ-
ектов. Только объекты для таких ОС – это задачи. Задачи со своими реализациями. Для таких задач характер понятие “ядра пользователя” и принцип
“свободного” взаимодействия компонентов между собой. Характер и принципы взаимодействия определяются типом ОС и ее настройками.
Каждая программа для такой ОС также включает в свой состав микроядро, которое обеспечивает уровень интерфейса для остальных компонентов, работу основных функций, управление приоритетами, процедуру
загрузки задач и так далее. Взаимодействие между компонентами происходит через отдельные потоки, в своей общей массе реализующие буфер для
обмена информацией.
Этот буфер также иногда называется “почтовым ящиком”, куда компоненты ОС и прикладные программы могут “класть” свои сообщения.
Этот “ящик” по своей сути является сервером сообщений. Он сам обеспечивает прием сообщений, управление трансфером данных, безопасностью,
сохранностью информации, а, самое главное, гарантированную доставку
до адресата.
При всем этом конкретная реализация “почтового сервера” не зависит от реализаций других компонентов, а его изменения не затрагивают
другие модули.
Следует отметить, что в объектной архитектура как таковой отсутствует программный интерфейс или API (рис. 7).
Само по себе взаимодействие между компонентами системы, а, по
сути, между микроядрами, и пользовательскими процессами, носит характер обычного вызова функции и передачи управления. Если эти компоненты разработаны на одном языке программирования (обычно это С++),
то скорость взаимодействия максимальна. Если это правило не выполняется, то могут присутствовать “просадки” в производительности.
Модульный подход позволяет более оптимально расходовать ресурсы инструментов разработчика. Можно отлаживать и разрабатывать
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]