4 Лекция № 2. Архитектура операционных систем. Часть 1
Продолжительность: 2 часа (90 мин.)
4.1 Ключевые вопросы
Цель и задачи курса.
Информация и данные.
Основные понятия и определения: дисковые операционные системы (ДОС); ОС общего назначения; системы промежуточных типов, Системы виртуальных машин; Системы реального времени; Системы кросс-разработки; системы промежуточных типов.
Основные понятия и определения: Микроядро.
История развития систем.
Назначение и основные компоненты СБД.
Монолитные операционные системы..
4.2 Текст лекции
Структура и сложность операционных систем существенно изменяется по мере развития, как самих операционных систем, так и аппаратного обеспечения [2]. Операционная система CTSS, разработанная в Массачусетском технологическом институте (МТИ) в 1963 году занимала в памяти около 36 тысяч 36-разрядных слов. OS/360, разработанная фирмой IBM через год, содержала уже более миллиона машинных команд. Система Multics, совместно разработанная специалистами МТИ и Bell Laboratories в 1975 году содержала уже около 20 миллионов команд.
Увеличение размера и сложности операционных систем привело к возникновению трех распространенных проблем:
операционные системы доходят до пользователя с существенным опозданием,
в системах присутствуют скрытые ошибки, требующие исправления,
рост производительности операционных систем не так велик, как хотелось бы.
Пути решения эти проблем, вообще говоря, достаточно очевидны:
система должна состоять из модулей – это упрощает ее написание и отладку,
модули должны иметь тщательно разработанные и максимально простые интерфейсы – это также облегчает написание и отладку, а также внесение изменений в систему.
Несмотря на очевидность такого решения, оказалось, что для сложных систем, состоящих и миллионов и более строк, оно не избавляет от всех проблем.
Структура операционной системы во многом зависит от того, к какому из типов она относится. Типов операционных систем можно выделить много, однако по большому счету можно выделить следующие:
микроядерные,
монолитные,
многоуровневые,
виртуальные машины,
экзоядро,
модель клиент-сервер.
4.2.1 Микроядро — до 15 мин.
Микроядро – это минимальная часть операционной системы, являющаяся основой для модульных и переносимых расширений. Основная идея микроядра – создать необходимую среду верхнего уровня, из которой можно получить доступ ко всем функциям уровня аппаратного обеспечения [3].
В микроядре содержится минимальное количество кода, необходимое для реализации основных системных вызовов. К этим вызовам относятся передача сообщений и другие коммуникации между внешними по отношению к ядру процессами, управление прерываниями и некоторые другие функции. Остальные функции реализуются как модульные дополнения, взаимодействующие между собой с помощью сообщений.
Микроядро работает с наивысшим приоритетом и обеспечивает работу остальной части операционной системы как набора серверных приложений. Технология микроядра Mach (мэк) создана в университете Карнеги Меллон и служит основой многих операционных систем.
Функциональность микроядра ограничена с целью сокращения его размеров и перевода большей части операционной системы в ранг прикладной программы. Обычно микроядро поддерживает пять различных типов сервисов [3]:
управление виртуальной памятью,
управление заданиями и потоками,
межпроцессные коммуникации (IPC – inter-process communication),
управление вводом-выводом и прерываниями,
обеспечение клиент-серверного сервиса.
Другие функции операционной системы размещаются в других сервисах ОС, работающих как приложения микроядра.
Суть микроядерной архитектуры состоит в следующем [4]. В привилегированном режиме работает только очень небольшая часть операционной системы, называемая микроядром. Микроядро защищено от остальных частей ОС и от приложений. Набор функций микроядра соответствует функциям слоя базовых механизмов обычного ядра. Это те функции, которые нельзя выполнить в пользовательском режиме. На рисунке 1.2 показан механизм переноса основного объема функций ядра в пространство пользователя [4].
Благодаря своим размерам и способности поддерживать стандартные сервисы программирования микроядро проще ядер монолитных или модульных операционных систем.
Рисунок 4.1 – Перенос основного объема функций ядра в пространство пользователя
Все остальные функции ядра оформляются в виде приложений, работающих в пользовательском режиме. Однозначных рекомендаций о том, какие из системных функций следует выполнять в привилегированном режиме, а какие в пользовательском, не существует.
Менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами ОС, так как их основным назначением является обслуживание запросов приложений и других модулей ОС. Для реализации этого механизма необходимо наличие в ОС эффективного способа вызова процедур одного процесса из другого. Поддержка этого механизма и является основной функцией микроядра.
На рисунке 4.2 показан механизм обращения к функциям ОС, оформленных в виде серверов. Клиент, которым может быть либо прикладная программа, либо другой компонент операционной системы, запрашивает выполнение некоторой функции у соответствующего сервера, посылая ему сообщение. Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы друг от друга. Микроядро, выполняющееся в привилегированном режиме, имеет доступ ко всем адресным пространствам, поэтому может работать в качестве посредника. Таким образом, работа микроядерной операционной системы соответствует модели клиент-сервер, в которой роль транспортных средств выполняет микроядро.
Наиболее ярким представителем микроядерных ОС является операционная система реального времени QNX. Микроядро QNX планирует только планирование и диспетчеризацию процессов, их взаимодействие, обработку прерываний и сетевые службы нижнего уровня. Такое микроядро обеспечивает лишь два десятка системных вызовов и имеет размер от 8 до 46 килобайт.
Рисунок 4.2 – Реализация системного вызова в микроядерной архитектуре
Для построения минимальной системы QNX к микроядру следует добавить менеджер процессов, который создает процессы, управляет ими и их памятью. Для применения QNX в настольной ПЭВМ, к микроядру следует добавить также файловую систему и менеджер устройств.
Все эти менеджеры выполняются вне пространства ядра, так что ядро остается небольшим.
Рассмотрим кратко достоинства и недостатки микроядерных ОС. К достоинствам их можно отнести:
переносимость, обусловленная тем, что весь машинно-зависимый код изолирован в микроядре,
расширяемость, обусловленная ограниченным набором четко определенных интерфейсов микроядра; добавление новой подсистемы требует разработки нового приложения, что никак не затрагивает целостность микроядра,
надежность, обусловленная тем , что каждый сервер выполняется в виде отдельного процесса в собственной области памяти, что защищает его от других серверов ОС (в традиционной операционной системе все модули могут влиять друг на друга); повышению надежности способствует также уменьшенный объем кода микроядра,
пригодность для распределенных вычислений, так как использует механизмы клиент-серверного взаимодействия, причем серверы микроядерной ОС могут находиться как на одном, так и на разных компьютерах.
Основным недостатком микроядерной ОС является сниженная по сравнению с классической ОС производительность. Дело в том, что при классической организации ОС выполнение системного вызова сопровождается двумя переключениями режимов, а при микроядерной архитектуре – четырьмя. Ситуация иллюстрируется рисунком 4.3.
Рисунок 4.3 – Смена режимов при выполнении системного вызова
Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT [3]. В версиях 3.1 и 3.5 диспетчер окон, графическая оболочка и высокоуровневые драйверы графических устройств были включены в состав сервера пользовательского режима, и вызов этих функций осуществлялся в соответствии с микроядерной схемой. Однако, разработчикам стало ясно, что такой механизм существенно снижает быстродействие системы, поэтому в версии 4.0 перечисленные выше модули были включены в ядро. Этот факт отдалил ОС от идеальной микроядерной архитектуры, но сделал систему более производительной.
4.2.2 Монолитные ОС — до 15 мин.
Монолитные операционные системы являются противоположностью микроядерных ОС. В монолитной ОС, даже если она сильно структурирована, очень трудно удалить изменить или добавить уровень или модуль.
В общем случае организация монолитной системы представляет собой «большой беспорядок». Структура такой системы обычно отсутствует вообще. Монолитная операционная система написана в виде набора процедур, каждая из которых может вызывать другие, когда ей это нужно. При этом каждая из процедур имеет строго определенный интерфейс в терминах параметры–результаты. Здесь по существу полностью отсутствует попытка сокрытия деталей реализации системы – каждая процедура видит любую другую.
При обращении к системным вызовам, поддерживаемым операционной системой, параметры помещаются в строго определенные места – регистры или стек, после чего выполняется специальная команда, называемая вызовом ядра или вызовом супервайзера. Эта команда переключает машину из режима пользователя в режим ядра и передает управление операционной системе. Операционная система проверяет параметры вызова, определяет, какой системный вызов должен быть выполнен и обращается к таблице или массиву с номером системного вызова в качестве индекса. В соответствующем элементе массива или таблицы содержится ссылка на процедуру обработки этого вызова. Такая организация операционной системы предполагает наличие, все же, определенной структуры:
главная программа, вызывающая требуемую служебную процедуру,
набор служебных процедур, выполняющих системные вызовы,
набор утилит, обслуживающих служебные процедуры.
На рисунке 4.4 изображена указанная структура разделения процедур на три уровня.
Рисунок 4.4 – Простая модель монолитной системы
Обобщением модели, изображенной на рисунке 1.5 является организация операционной системы в виде уровней иерархии и уровней абстракции [2]. В иерархической структуре современной операционной системы различные функции находятся на разных уровнях иерархии, в зависимости от их сложности, характеристик и уровня абстракции. Работа компонентов одного уровня основана на работе компонентов низших уровней. В идеале изменение одного уровня не должно влиять на все остальные уровни.