Основы архитектуры операционных систем

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

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

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

Следующий пункт — использование ресурсов. Здесь имеется в виду, что операционная система предоставляет все средства, обеспечивающие доступность ресурсов ВС пользователю (точнее программам).

И, наконец, распределение: под этим будем понимать обеспечение всевозможных моделей регламентации доступа.

Любая операционная система опирается на набор базовых сущностей, на основе характеристик которых выстраиваются почти все эксплуатационные свойства конкретной операционной системы. При этом, для различных операционных систем наборы базовых сущностей зачастую различаются: одни основаны на понятии устройства, другие — на понятии файла, третьи — на понятии набора данных. Но в большинстве случаев в состав базовых включается сущность, обозначающая исполняемую программу, задачу, задание или процесс. Эта сущность определяет некоторый процесс исполнения последовательности команд, причем здесь может участвовать единственная ветвь вычислений, а может сразу и несколько параллельных ветвей. Из множества трактовок этой сущности мы выберем понимание ее именно как процесса.

Процесс — это совокупность машинных команд и данных, обрабатывающаяся в рамках вычислительной системы и обладающая правами на владение некоторым набором ресурсов.

Разберемся в этом определении. Понятие совокупности машинных команд и данныхобозначает то, что принято называть исполняемой программой, т.е. это код и операнды, используемые в этом коде. Далее, под термином обработки в рамках ВС будем понимать, что эта программа сформирована и находится в системе в режиме обработки (это может быть и ожидание, и исполнение на процессоре, и т.п.). И, третье, понятие обладания правами на владение некоторым набором ресурсов обозначает, по сути, возможность доступа. Отметим, что здесь речь не идет об эксклюзивных правах, поскольку в общем случае это было бы некорректно. Итак, иными словами процесс можно определить как исполняемую программу, которая введена в систему для ее обработки, и с которой ассоциированы некоторые ресурсы вычислительной системы.

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

С точки зрения выделения ресурса процессу используются две модели организации этого выделения. Первый способ — это предварительная декларация ресурсов. В этом случае до ввода программы в систему и формирования для нее процесса описывается перечень тех ресурсов, которыми процесс будет обладать. Например, это может быть перечень областей оперативной памяти, которые будут доступны данному процессу (если система поддерживает механизм виртуальной памяти, то это будет перечень областей виртуальной памяти, доступных процессу). Или же это может быть предельное время центрального процессора, которое может быть потрачено на исполнение данного процесса. Так или иначе, при вводе программы и формировании процесса операционная система постарается выделить все необходимые ресурсы, которые были предварительны декларированы. Если в системе нет заказанного ресурса, то она, скорее всего, не станет запускать процесс, который запросил этот ресурс.

Вторая модель — это динамическое дополнение списка ресурсов. Данная модель предполагает выделение процессу ресурса уже во время выполнения этого процесса. Это означает, что в системе происходит запуск процесса с выделением ему минимально необходимой области виртуальной памяти, а затем, когда процесс обращается к системе за выделением дополнительной области, то ОС обрабатывает эти запросы соответствующим образом. Отметим также, что на практике также применяются и смешанные подходы, но во многих системах, с которыми мы сталкиваемся в нашей повседневной жизни, ориентация сделана на динамическую модель выделения ресурсов.

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

Надежность означает, что система должна быть надежной как программный комплекс, т.е. число программных ошибок в системе должно быть сведено к минимуму и должно быть соизмеримо с количеством возможных аппаратных сбоев.

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

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

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

Структура ОС

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

Простейшая структурная организация основана на представлении операционной системы в виде композиции следующих компонентов (Рис. 64).

Основы архитектуры операционных систем

Рис. 64. Структурная организация ОС.

Ядро (kernel) ОС — это часть ОС, в которой реализована функциональность ОС; ядро работает в режиме супервизора, т.е. в привилегированном режиме, и резидентно (постоянно) размещается в оперативной памяти. Итак, по определению ядро обеспечивает реализацию некоторого набора функций операционной системы. Это может быть очень большой набор функций, а может маленький — все зависит от конкретной реализации системы. Ядро может включать в свой состав драйверы основных физических или виртуальных устройств.

Над уровнем ядра может надстраиваться следующий уровень — это уровень динамически подгружаемых драйверов физических и виртуальных устройств. Под динамически подгружаемыми понимается то, что в зависимости от ситуации состав этих драйверов при инсталляции и загрузке системы может меняться. Соответственно, эти драйверы можно поделить на две категории: резидентныедрайверы и нерезидентные. Резидентные драйверы подгружаются в систему в процессе ее загрузки и находятся в ней до завершения ее работы. Примером резидентного драйвера может быть драйвер физического диска.

Отметим, что большинство современных операционных систем имеют в своем составе набор драйверов широкого спектра конкретных физических устройств и, в частности, физических дисков. Поэтому зачастую при смене устройства драйвер менять не надо: он уже есть в системе. Но при этом системе незачем держать драйвера всех устройств в оперативной памяти. Соответственно, следуя той или иной стратегии, будут загружаться драйверы тех физических устройств, которые реально будут обслуживаться системой. Стратегии могут быть различными, одной из них: может быть явное указание системе списка драйверов, которые необходимо подгрузить (в этом случае, если в списке что-то будет указано неправильно, то соответствующее устройство, возможно, просто не будет работать). Вторая стратегия предполагает, что система при загрузке самостоятельно сканирует подключенное к ней оборудование и выбирает те драйверы, которые должны быть подгружены для обслуживания найденного оборудования.

Итак, примером резидентного драйвера может служить драйвер физического диска. Это объясняется тем, что диск является устройством оперативного доступа, поэтому к моменту полной загрузки системы все должно быть готово для работы. А, например, в системах, где пользователи редко используют сканер, держать соответствующий драйвер резидентно не имеет смысла, поскольку скорость работы самого устройства много медленнее, чем скорость загрузки драйвера из внешней памяти в оперативную. Соответственно, драйвер сканера в этом случае служит одним из примеров нерезидентных драйверов, т.е. тех драйверов, которые могут находиться в ОЗУ, а могут быть и отключенными, но они также динамически подгружаемые.

В общем случае драйверы могут работать как в привилегированном режиме, так и в пользовательском.

И, наконец, некоторой логической вершиной рассматриваемой структуры ОС будут являться интерфейсы системных вызовов (API — Application Program Interface). Под системным вызовом будем понимать средство обращения процесса к ядру операционной системы за выполнением той или иной функции (возможности, услуги, сервиса). Примерами системных вызовов являются открытие файла, чтение/запись в него, порождение процесса и т.д. Отличие обращения к системному вызову от обращения к библиотеке программ заключается в том, что библиотечная программа присоединяется к исполняемому коду процесса, поэтому вычисление библиотечных функций будет происходить в рамках процесса. Обращение к системному вызову — это вызов тех команд, которые инициируют обращение к системе. Как уже отмечалось выше, инициацией обращения к операционной системе может служить либо прерывание, либо исполнение специальной команды. Следует понимать различие между системным вызовом и библиотечной функцией. Например, осуществляя работу с файлом, имеется возможность работы с ним посредством обращения к системным вызовам либо посредством использования библиотеки ввода-вывода. В последнем случае в тело процесса включаются дополнительные функции из данной библиотеки, а уже внутри данных функций происходит обращение к необходимым системным вызовам.

Итак, существует несколько подходов к структурной организации операционных систем. Один из них можно назвать классическим: он использовался в первых операционных системах и используется до сих пор — это подход, основанный на использовании монолитного ядра. В этом случае ядро ОС представляет собою единую монолитную программу, в которой отсутствует явная структуризация, хотя, конечно, в ней есть логическая структуризация. Это означает, что монолитное ядро содержит фиксированное число реализованных в нем функций, поэтому модификация функционального набора достаточно затруднительна. Устройство монолитного ядра напоминает физическую организацию первых компьютеров: в них также нельзя было выделить отдельные физические функциональные блоки — все было единым, монолитным и интегрированным друг с другом. Аналогичными свойствами обладают одноплатные компьютеры, у которых все необходимые компоненты (ЦПУ, ОЗУ и пр.) расположены на одной плате, и чтобы что-то изменить в этой конфигурации, требуются соответствующие инженерные знания.

На Рис. 65 проиллюстрирована структурная организация классической системы Unix. В данном случае ядро имеет фиксированный интерфейс системных вызовов. В нем реализовано управление процессами, а также драйвер файловой системы, реализована вся логика системы по организации работы с устройствами, которые можно разделить на байт-ориентированные и блок-ориентированные, и пр.

Основы архитектуры операционных систем

Рис. 65. Структура ОС с монолитным ядром.

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

Альтернативу данному подходу предлагают многослойные операционные системы[R11] . В этом случае все уровни разделяются на некоторые функциональные слои. Здесь можно провести аналогию с моделью сетевых протоколов. Между слоями имеются фиксированные интерфейсы. Управление происходит посредством взаимодействия соседних слоев. Поскольку любая структуризация снижает эффективность (программа, написанная в виде одной большой функции, работает быстрее, чем аналогичная программа, разбитая на подпрограммы, т.к. любое обращение к подпрограмме ведет к накладным расходам), то подобные системы обладают более низкой эффективностью.

Итак, каждый слой предоставляет определенный сервис вышестоящему слою. Деление на слои является индивидуальным для каждой конкретной операционной системы. Это может быть слой файловой системы, слой управления внешними устройствами и т.д. Тогда модернизация подобных систем сводится к модернизации соответствующих слоев. Вследствие чего проблема несколько упрощается, но при этом остаются ограничения на структурную организацию (например, имея слой файловой системы, можно заменить его другим вариантом этого слоя, но использовать одновременно две различные файловые системы не представляется возможным).

Третий подход предлагает использовать микроядерную архитектуру (Рис. 66). Функционирование операционных систем подобного типа основывается на использовании т.н. микроядра. В этом случае выделяется минимальный набор функций, которые включаются в ядро. Все оставшиеся функции представляются в виде драйверов, которые подключаются к ядру посредством некоторого стандартного интерфейса.

Основы архитектуры операционных систем Основы архитектуры операционных систем Основы архитектуры операционных систем Основы архитектуры операционных систем Основы архитектуры операционных систем

Рис. 66. Структура ОС с микроядерной архитектурой.

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

Микроядерная система может служить основой для надстройки над микроядром разных операционных систем. В частности, такой подход используется в ряде систем, в основе которых используется микроядро системы Mach.

Итак, только что были продемонстрированы достоинства данного подхода. Что касается недостатков, то они следуют из достоинств и проявляются в значительном возрастании накладных расходов. Положим, процесс обращается к файловой системе, чтобы произвести обмен с конкретным файлом посредством соответствующего системного вызова. Драйвер файловой системы, получив запрос от процесса, перерабатывает его в последовательность запросов на обмен с диском (пускай, сначала это будут виртуальный диск). После чего файловая система обращается к микроядру, которое, в свою очередь, находит драйвер виртуального диска, передает соответствующий запрос. Драйвер виртуального диска определяет, с каким физическим диском будет происходить обмен, и трансформирует поступивший ему запрос в запросы к этому физическому диску, которые ему и передаются по той же схеме. Таким образом, один запрос распадается на множество запросов, следующих от драйвера через микроядро к другому драйверу, благодаря чему эффективность системы снижается.

Напоследок отметим, что в реальности используются системы, получаемые комбинацией указанных подходов.

Логические функции ОС

Рассматривая ОС, ее функциональность можно представить в виде объединения некоторого фиксированного количества блоков функций. Состав этого набора варьирует от системы к системе, но в большинстве случаев можно выделить следующие функции: управление процессами, управление оперативной памятью, планирование и, наконец, управление данными, файловой системой и устройствами, а также в последнее время стали добавлять блок функциональности сетевого взаимодействия.

На уровне управления процессами решаются проблемы формирования процессов, поддержание жизненного цикла процесса, организация взаимодействия процессов, т.е. организация взаимодействия процесса с системой в целом и с другими процессами в частности.

Блок управления оперативной памятью реализует программную поддержку той или иной стратегии организации памяти. При необходимости на этом уровне реализуется поддержка аппарата виртуальной памяти, решается задача выделения и изъятия памяти у процесса.

Функции планирования можно понимать с разных точек зрения. Можно понимать планирование в узком смысле слова, т.е. планирование центрального процессора (т.е. планирование доступа процессов к центральному процессору). На самом деле, функций планирования большое множество, поскольку применять планирование приходится при организации многих механизмов операционной системы. Так, упоминавшаяся только что задача изъятия памяти у процессов является задачей планирования, поскольку ставится вопрос, по какому принципу будет происходить это изъятие. Взаимодействие с внешними устройствами тоже не может обойтись без решения задач планирования: так или иначе, поток заказов на обмен, поступающих в системе, может превосходить пропускную способность устройства, образуется конкуренция по доступу к устройству — выстраивается очередь заказов на обмен. Соответственно, ставится вопрос, как организовать обработку этой очереди. Возможны различные стратегии: FIFO, LIFO и пр. — и для каждой из них будет свой результат. Итак, сфера применения решения задач планирования достаточно широка, просто в одних случаях планирование рассматривают в рамках какой-либо функциональности, а в других случаях — отдельно.

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

01 — Операционные системы. Введение


Похожие статьи.

Понравилась статья? Поделиться с друзьями: