Структура системы

С добавлением в операционные системы все новых функций, а также с рос­том возможностей управляемого операционными системами аппаратного обеспе­чения и его разнообразия возрастает степень их сложности. Операционная сис­тема CTSS, введенная в эксплуатацию в Массачусетском технологическом инсти­туте в 1963 году, занимала в памяти около 32000 36-битовых слов. Операционная система OS/360, выпущенная фирмой IBM через год, содержала более миллиона машинных команд. Система Multics, совместная разработка ко­торой была завершена специалистами Массачусетского технологического инсти­тута и компанией Bell Laboratories к 1975 году, разрослась до 20 миллионов ко­манд. Ради справедливости отметим, что впоследствии на меньших машинах стали появляться операционные системы и попроще, но и они неуклонно услож­нялись с развитием аппаратного обеспечения и ростом требований со стороны пользователей. Так, современная система UNIX по своей сложности намного превосходит свой почти игрушечный первоначальный вариант, разработанный несколькими талантливыми программистами в начале 70-х годов. То же самое произошло с простой системой MS-DOS, со временем переросшей в сложные и мощные операционные системы OS/2 и Windows 2000. Так, операционная сис­тема Windows NT содержит около 16 миллионов строк кода, а в Windows 2000 этот показатель увеличен более чем в два раза.

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

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

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

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

В каждой отдельно взятой операционной системе перечисленные принципы применяются по-разному. Для получения общего представления об операцион­ных системах на данном этапе изложения представим пример обобщенной моде­ли иерархической операционной системы, описанной в [BROW84] и [DENN84]. Она, несомненно, полезна для понимания сути дела, хотя и не соответствует ни одной реальной операционной системе. Сама модель приведена в табл. 2.4 и со­стоит из следующих уровней.

• Уровень 1. В него входят электронные схемы; объектами данного уровня
являются регистры, ячейки памяти и логические элементы. Над этими объектами выполняются различные действия, такие, как очистка содержимого
регистра или считывание ячейки памяти.

• Уровень 2. Набор команд процессора. В число операций, выполняемых на
этом уровне, входят те, которые допускаются набором команд машинного
языка, например сложение, вычитание, загрузка значения из регистра или
сохранение в нем.

• Уровень 3. Содержит концепцию процедуры (подпрограммы), а также операции вызова и возврата.

• Уровень 4. Уровень прерываний, которые заставляют процессор сохранить
текущий контекст и выполнить подпрограмму обработки прерывания.

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

• Уровень 5. На этом уровне вводится понятие процесса, под которым подразумевается работающая программа. В число фундаментальных требований к
операционной системе, способной поддерживать одновременную работу не­
скольких процессов, входят способность приостанавливать процессы и во­зобновлять их выполнение. Для этого необходимо сохранять содержимое
регистров аппаратного обеспечения, чтобы можно было переключаться с од­ного процесса на другой. Кроме того, если процессы должны взаимодейст­вовать между собой, необходим механизм их синхронизации. Одной из важнейших концепций устройства операционных систем является сема­фор — простейший способ передачи сигналов, который рассмотрен в главе 5, "Параллельные вычисления: взаимоисключения и многозадачность".

• Уровень 6. Компоненты этого уровня взаимодействуют со вспомогательны­ми запоминающими устройствами компьютера. На этом уровне происходит
позиционирование считывающих головок и физическая передача блоков
данных. Для планирования работы и уведомления процесса о завершении
запрошенной операции уровень 6 использует компоненты уровня 5.

• Уровень 7. Создает логическое адресное пространство процессов. Уровень
организует виртуальное адресное пространство в виде блоков, которые могут перемещаться между основной памятью и вспомогательным запоми­нающим устройством. Широко распространены следующие три схемы: ис­пользование страниц фиксированного размера, использование сегментов пе­ременного размера и комбинация тех и других. Если нужный блок отсутствует в основной памяти, то данный уровень передает уровню 6 запрос о передаче этого блока.

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

• Уровень 8. Отвечает за обмен информацией и сообщениями между процессами.
На этом уровне происходит более богатый обмен информацией, чем на уровне 5,
который обеспечивает работу первичного сигнального механизма для синхрони­зации процессов. Одним из наиболее мощных инструментов подобного типа является конвейер, представляющий собой логический канал передачи данных
между процессами. Конвейер определяется как канал, передающий вывод одно­го процесса на вход другого; кроме того, он может быть использован и для свя­зи с процессом внешних устройств или файлов. Эта концепция рассматривается в главе 6, "Взаимоблокировка и голодание".

• Уровень 9. Обеспечивает долгосрочное хранение файлов. На этом уровне данные, хранящиеся на вспомогательном запоминающем устройстве, рассматрива­ются как абстрактные объекты переменной длины, в противоположность аппаратно-зависимому рассмотрению вторичной памяти как набора дорожек, секторов и блоков фиксированного размера, присущему уровню 6.

• Уровень 10. Предоставляет доступ к внешним устройствам с помощью
стандартных интерфейсов.

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

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

• Уровень 13. Обеспечивает взаимодействие операционной системы с пользователем. Этот уровень называется оболочкой (shell), так как он отделяет пользователя от деталей внутреннего устройства операционной системы и представляет ее пользователю как набор сервисов. Оболочка принимает ко­манды пользователя или инструкции-управления заданиями, интерпретиру­ет их, создает необходимые процессы и управляет ими. На этом уровне, на­пример, может быть реализован графический интерфейс, предоставляющий пользователю возможность выбора команды с помощью меню и отобра­жающий результаты работы на экране.

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

Таблица 2.4. Иерархическая модель операционной системы2