Индекс
НазадОглавлениеВперед


Глава 1
Основные понятия

1.1. Операционная система с точки зрения системного программиста

Операционная система (ОС) есть набор программ, которые распределяют ресурсы процессам.

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

В [8] приведено около десятка определений термина "процесс", из которых автор выбирает: "программа в стадии выполнения". Это определение близко к тому, что интуитивно понимают под "процессом" программисты, но оно не является строгим. Более строгое определение процесса, которое дает терминологический стандарт, представляется нам гораздо более удачным, поэтому ниже мы приводим его полностью.

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

Примечания:

  1. Процесс характеризуется состояниями, которые определяются наличием тех или иных ресурсов в распоряжении процесса и, следовательно, возможностью фактически выполнять действия, относящиеся к процессу.
  2. Перераспределение ресурсов, выполняемое управляющей программой, влияет на продолжительность процесса обработки данных, но не на его конечный результат.
  3. Процесс оформляют с помощью специальных структур управляющих данных, которыми манипулирует управляющий механизм.
  4. В конкретных системах обработки информации встречаются разновидности процессов, которые различаются способом оформления и составом ресурсов, назначаемых процессу и отнимаемых у него, и допускается вводить специальные названия для таких разновидностей, как, например, задача в операционной системе ОС ЕС ЭВМ" [4].

(В соответствии со сложившейся в литературе традицией, мы часто будем употреблять термин "задача" как синоним термина "процесс".)

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

Такой взгляд на разработку и анализ ОС сложился в конце 60-х - начале 70-х годов, в значительной степени под влиянием ОС Unix [5, 24], в которой принцип процессов и ресурсов реализован наиболее последовательно и изящно. Большое количество изданий, посвященных ОС и отражающих как эмпирический (например, [8, 14, 27]), так и аналитический (например, [1, 2, 12]) подходы, разделяет именно такой взгляд. Следование принципу процессов-ресурсов позволяет структурировать изучение ОС в виде таблицы, приведенной на рисунке 1.1. Столбцами этой таблицы являются классы ресурсов, которыми управляют ОС, а строками - конкретные ОС.


Рис.1.1. Операционные системы и ресурсы

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

Попытку "эскизного" заполнения таблицы рис 1.1 мы делаем во второй части.

1.2. Классификация и предварительный обзор операционных систем

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

Мы будем классифицировать ОС по количеству пользователей и количеству задач (процессов), одновременно управляемых системой. Чем вызывается стремление увеличить эти показатели?

Доводы за многопользовательский режим составляют две группы. Во-первых, возьмем на себя смелость утверждать, что сегодня персональный компьютер возможен только как игрушка. Профессиональный программист или пользователь ЭВМ не может сегодня работать на персональном компьютере - он может (и должен) работать на сколь угодно интеллектуальном персональном терминале в глобальной компьютерной сети. Естественно, что стоимость обработки данных в такой сети может быть существенно снижена при концентрации программ и данных, относящихся к одному, например, проекту или предприятию, в одном узле этой сети с обеспечением доступа к ним всех пользователей этой информации. Во-вторых, в 70-е годы состояние средств вычислительной техники и их программного обеспечения позволило специалистам вывести правило о том, что при линейном возрастании стоимости вычислительной системы ее возможности возрастают в квадрате [8]. В середине 80-х годов это правило было нарушено из-за значительного снижения стоимости ПЭВМ за счет их массового производства, но в настоящее время технологии производства компонентов больших ЭВМ (мейнфреймов) по стоимостному показателю сравнялись с ПЭВМ [22, 28], и это правило вновь становится актуальным. Но более мощную вычислительную систему один пользователь будет просто не в состоянии загрузить - отсюда и необходимость в многопользовательском режиме.

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

Разновидностью интерактивного режима можно считать вычисления в режиме клиент/сервер [25]. В этом режиме управление каким-либо ресурсом (например, базой данных) осуществляется отдельным процессом (возможно, и отдельным компьютером в сети) - сервером. Приложения-клиенты - для получения доступа к ресурсу обращаются к серверу. При любой обработке данных имеются три основных уровня манипулирования данными, как показано на рисунке 1.2:


Рис.1.2. Уровни обработки и модели клиент/серверных вычислений

В персональных вычислительных системах, построенных по персональной идеологии, все три функции в полной мере сосредоточены на одном компьютере. При построении неперсональных систем выполняется перераспределение функций между компьютерами в сети. Распределение функций манипулирования данными между клиентом и сервером может быть различным. Различные варианты распределения функций между сервером и клиентами образуют различные варианты архитектуры клиент/сервер (см.рис.1.2):

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

Сходные задачи стоят и перед системами реального времени, как правило, работающими в непосредственной связи (on-line) с объектом управления и выполняющими некоторые операции по управлению либо периодически, либо по требованию. Но в отличие от интерактивных или клиент/серверных ОС, для систем реального времени основной целью является обеспечение гарантированного времени ответа, ни в коем случае не превышающего некоторого критического значения.

Наконец, современная (и перспективная) модель вычислений предполагает выделение разнесение всех трех уровней клиент-серверной архитектуры - клиент, сервер приложений, сервер данных - по разным ЭВМ. Функции клиента сводятся к презентации информации для конечного пользователя. Сервер приложений обеспечивает разнообразные вычислительные возможности. Сервер данных - прежде всего хранение и выборку данных, хотя может выполнять и значительную часть их обработки. В условиях развития глобальных коммуникаций каждый клиент может получать обслуживание от многих серверов приложений, а каждый сервер приложений - получать данные из многих источников, как показано на рис.1.3.


Рис.1.3. Трехуровневая архитектура клиент/сервер

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

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

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

Простейшим является класс однозадачных однопользовательских систем. Аппаратной платформой их является IBM PC (XT, AT), ОС - MS DOS. Поскольку ресурсы такой системы весьма ограничены, ее рассмотрение не представляет для целей данного пособия существенного интереса.

Класс многозадачных однопользовательских систем начинается с тандема MS DOS + Windows, но настоящими ОС этого класса являются OS/2 и Windows 9x. Эти ОС работают на аппаратной платформе не ниже процессора Intel 80386, ресурсы, поддерживаемые такими ОС, - более мощные, управление ими усложняется. Вместе с тем, в функции системы не входит защита ресурсов от других пользователей: в однопользовательской системе "украсть" ресурсы можно только у самого себя.

Windows 1.x - 3.x представляет собой надстройку над MS DOS, обеспечивающую управление виртуальной памятью (сегментную или сегментно-страничную - в зависимости от процессора - модель) и кооперативную многозадачность.

Операционные системы OS/2 и Windows 95/98/ME - системы многозадачные, однопользовательские.(Хотя OS/2 позиционируется на рынке как серверная система, ядро ее продолжает оставаться однопользовательским.) Они обеспечивают вытесняющую многозадачность и работу с нитями, а также богатый набор средств взаимодействия процессов. В них используется 32-разрядная (плоская) модель памяти

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

Первым примером ОС такого класса, естественно, должна быть названа ОС Unix, которая существует и развивается с 1968г. ОС Unix оказала огромное влияние на развитие концепций построения ОС, породила множество клонов (BSD Unix, Solaris, AIX, Linux и т.д.) и является основой стандартов для ОС.

Windows NT (начиная с версии 5 - Windows 2000) является полностью 32-разрядной ОС с объектно-ориентированной структурой и строится на базе микроядра.

Семейство вычислительных систем AS/400 является результатом длительного эволюционного развития, начавшегося с IBM System/38 (1978г.). По ряду идей и решений эволюционный ряд System/38 - AS/400 является лидером в развитии ОС. Среди особенностей, делающих эту систему интересным примером для нас, следует назвать: объектно-ориентированную ее структуру и архитектуру на базе микроядра, одноуровневую модель памяти, мощные средства защиты. Системное программное обеспечение AS/400 двухуровневое: нижний уровень выполняется Лицензионным Внутренним Кодом (LIC - Licensed Internal Code) и обеспечивает аппаратную независимость верхнего уровня, который составляет собственно ОС OS/400. AS/400 отличается значительной степенью системной интеграции и высоким уровнем системных интерфейсов.

Наконец, последний рассматриваемый нами класс - гигаресурсные (термин введен нами) системы. Являясь также многозадачными и многопользовательскими, они отличаются от предыдущего класса тем, что ресурсы, управляемые ими, на несколько порядков большие. Их аппаратной платформой являются мейнфреймы System/390 или ESA (Enterprise System Architecture) фирмы IBM, представляющие собой эволюционное развитие ряда System/360 - System/370. Современные мейнфреймы отличаются большим объемом возможностей, реализованных на аппаратном уровне, таких как мультипроцессорная обработка, средства создания системных комплексов, объединяющих несколько мейнфреймов, средства логического разделения ресурсов вычислительной системы, высокоэффективная архитектура каналов ввода-вывода, и т.д. Современные ОС ESA - VSE/ESA, VM/ESA, OS/390 представляют собой развитие работавших на System/360, System/370.

1.3. Точка зрения пользователя

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

Этот принцип иллюстрируется Рисунком 1.4.


Рис. 1.4. Операционная система, процессы, оборудование

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

Управляющие воздействия и прерывания составляют интерфейс оборудования, системные вызовы и отклики на них - интерфейс процессов. В качестве синонима интерфейса процессов мы в соответствии со сложившейся в последнее время традицией часто будем употреблять аббревиатуру API (Application Programm Interface - интерфейс прикладной программы).

Отделение процессов пользователя от оборудования преследует две цели.

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

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

1.4. Аппаратная архитектура и поддержка ОС

Существует несколько различных определений того, что следует считать аппаратной архитектурой ЭВМ, каждое из таких определений "работает" для определенного класса задач. Мы, как программисты, воспользуемся таким определением:

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

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

Аппаратную поддержку управления памятью и вводом-выводом мы рассматриваем отдельно (в главах 3 и 6 соответственно).

Система команд процессора - обеспечивает выполнение программой действий по обработке данных. Большинство команд в системе команд процессора имеет прикладное назначение, однако в некоторые команды из набора команд процессора предназначены для организации управления вычислительным процессом и, таким образом, непосредственно поддерживают функционирование ОС. Такие команды в современных системах являются привилегированными - это, например, команды ввода-вывода и изменения состояния системы. Современные ОС рассчитаны на наличие в вычислительной системе двух (как минимум) режимов функционирования процессора - привилегированного режима (режим ядра в терминологии Unix) и непривилегированного режима (режим процесса в Unix). Если программа, выполняющаяся в режиме ядра, может выполнять любые команды, то для программы, выполняющейся в режиме процесса, привилегированные команды запрещены. Попытка программы выполнить привилегированную команду в режиме процесса вызывает исключение (см. ниже). В системе ESA, например, таких основных состояний два (есть еще ряд промежуточных) [26], они называются "супервизор" и "задача", такие же названия они имеют в процессоре Power PC. В процессорах Intel-Pentium аналогичную роль играют уровни привилегий, они же - кольца защиты [23], причем из четырех аппаратно обеспечиваемых уровней привилегий в современных ОС используются два или три. Возможность для пользователя разрабатывать модули, работающие в режиме ядра, обычно строго регламентируется ОС. Хорошо защищенная ОС должна безоговорочно пресекать попытки процесса перейти в состояние ядра.

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

Содержимое специальных аппаратных регистров процессора (обязательно включая регистр адреса команды) составляет вектор состояния программы/процесса. В большинстве процессорных архитектур вектор состояния может быть загружен в соответствующие регистры или считан из них в память одной или несколькими командами. Так, в процессорах Intel-Pentium имеется структура данных, называемая TSS (Task State Segment - сегмент состояния задачи), содержимое которой играет роль вектора состояния. При выполнении команд JMP или CALL, адресующих дескриптор TSS, процессор среди прочих действий сохраняет содержимое регистров в TSS текущей задачи и загружает регистры из TSS новой задачи [23]. В процессоре S/390 [26] имеется 8-байтная структура PSW (Program Status Word - слово состояния программы), содержащая значительную часть информации вектора состояния (кроме содержимого регистров общего назначения), и имеются две команды - LPSW и SPSW для загрузки и запоминания PSW соответственно.

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

Различаются прерывания трех типов: внешние, программные и исключения.

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

Программное прерывание вызывается специальной командой процессора (в Intel-Pentium мнемоника этой команды - INT, в ESA и Power PC - SVC). Выполняется программное прерывание так же, как и внешнее, но, в отличие от внешних, программные прерывания являются синхронными, так как они вызываются самой программой. Программные прерывания являются средством обращения процесса к ОС, механизмом системного вызова. Обычные команды передачи управления - типа команд CALL или JMP изменяют регистр адреса команды, но не весь вектор состояния. Прерывание же позволяет изменить весь вектор состояния, то есть, не только передать управление на другую программу, но и перевести процессор из непривилегированного режима в привилегированный.

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

1.5. Ядро и процессы

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

Ядром (kernel) называется часть ОС, выполняющая некоторый минимально необходимый набор функций по управлению ресурсами. Дополнительные функции управления ресурсами выполняются вспомогательными модулями - утилитами. Точное определение ядра дать трудно, так как оно по-разному понимается в разных ОС. В "старых", не работавших с виртуальной памятью системах под ядром обычно понималась часть системы, резидентная в оперативной памяти. В современных ОС ядро резидентно в виртуальной памяти, и это также может служить его классификационным признаком. Более узкое определение, трактующую ядро как часть ОС, которая работает в привилегированном режиме, представляется нам более подходящей для определения микроядра (см. раздел 1.6).

На ядро, как правило, возлагаются такие основные функции:

Для ОС процесс представляется блоком контекста процесса (вспомните примечание 3 к определению процесса). Блок контекста содержит информацию о процессе, необходимую для ОС, например:

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

Вспомним теперь примечание 1 к определению процесса: процесс в системе может находиться в различных состояниях. Количество состояний процесса разное в разных ОС (так, в ОС Unix различают 9 возможных состояний процесса), но все они сводятся к трем основным, показанным на Рис.1.5.


Рис. 1.5. Состояния процесса

Активное состояние - процесс имеет все необходимые для выполнения ресурсы, в том числе и ресурс центрального процессора; активный процесс выполняется.

Готовое состояние - процесс имеет все необходимые для выполнения ресурсы, кроме ресурса центрального процессора.

Заблокированное (ожидающее) состояние - процессу не хватает еще какого-либо ресурса (ресурсов).

Рассмотрим (пока в общих чертах) переходы между состояниями.

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

Активный процесс может перейти в блокированное состояние (2 на рис.1.5) по двум причинам: по собственной инициативе - процесс выдает системный вызов - запрос на ресурсы, которые не могут быть ему предоставлены немедленно (например, выполнение операции ввода-вывода), или по инициативе ОС - ОС "насильственно" отбирает у процесса ресурсы, чтобы отдать их другому (более приоритетному) процессу. По этой же причине ОС может забрать ресурсы и у процесса, находящегося в готовом состоянии (4 на рис.1.5). Когда ресурс, которого не хватает процессу, освободится, ОС назначает его процессу и, если у процесса теперь есть все ресурсы, переводит процесс в готовое состояние (5 на рис.1.5). Теперь процесс будет состязаться с другими готовыми процессами за обладание ресурсом центрального процессора. В некоторых случаях (в зависимости от принятой в ОС дисциплины планирования) высокоприоритетный процесс может сразу после получения ресурса переводиться в активное состояние (3 на рис.1.5), вытесняя текущий активный процесс. (Как правило, переход 3 непосредственно не реализуется, а выполняется через переходы 5 и 7.) Перемещение процессов между активным/готовым и заблокированным состояниями называется планированием ресурсов или среднесрочным планированием.

Процесс может перейти из активного состояния в готовое (6 на рис.1.5) либо по собственной инициативе, добровольно отказавшись от использования центрального процессора, либо по инициативе ОС. Перевод процессов из готового состояния в активное (7 на рис.1.5) выполняет ОС в соответствии с принятой дисциплиной планирования процессов или краткосрочного планирования.

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

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

Каждый уровень планирования осуществляется отдельным планировщиком (или планировщиками) в составе ОС - процедурой или процессом. В последующих главах мы рассмотрим работу большей части этих планировщиков. В литературе часто собственно планировщиком (scheduler) называют планировщик процессорного времени, планировщики различных ресурсов называют менеджерами (manager) или мониторами (monitor) соответствующих ресурсов, а планировщик заданий носит название диспетчера заданий (jobs dispatcher).

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

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

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

1.6. Архитектурные концепции операционных систем

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

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


Рис.1.6. Иерархия абстрактных машин в системе THE

Реализация архитектуры абстрактных машин сопряжена со значительными трудностями, связанными с правильным выбором уровней и их иерархическим упорядочением. Система THE представляет только один из возможных вариантов, применимый далеко не во всех случаях. Успешность решения этой проблемы во многом зависит от выбранного метода проектирования. В первоисточнике реализация иерархии абстрактных машин производилась методом "снизу-вверх". Другие авторы (например, [11]) настаивают на реализации методом "сверху вниз". По-видимому, наиболее продуктивным является комбинированный метод, пример применения которого приведен в [10]: спецификации уровней разрабатываются "сверху вниз", а реализация ведется "снизу вверх". При любом методе проектирования обеспечиваются некоторые некоторые общие свойства уровней абстракции, важнейшие из которых следующие:

Иногда иерархию абстрактных машин иллюстрируют набором концентрических окружностей (например, [30]), чтобы подчеркнуть, что каждый следующий уровень иерархии полностью скрывает все лежащие ниже него уровни и каждый уровень может обращаться только к непосредственно нижележащему уровню. Обращения, адресованные к более низким уровням, последовательно проходят все промежуточные уровни.

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

В концепции виртуальной машины интерфейс процесса выглядит как интерфейс оборудования. В предельном случае, который можно наблюдать, например, в VM/ESA [34] внешние формы этих двух интерфейсов полностью совпадают. В этом случае процессу доступны все машинные команды, в том числе и привилегированные. Но эта доступность кажущаяся. На самом деле, выдача процессом привилегированной команды вызывает исключение. В большинстве ОС обработка такого исключения включает в себя аварийное завершение процесса, но в VM/ESA управление по исключению получает нижний уровень системы - CP (управляющая программа). CP определяет причину исключения и выполняет для процесса требуемую команду или моделирует выполнение этой команды на виртуальном оборудовании. У процесса создается иллюзия, что в его полном распоряжении находится реальная вычислительная система (с той, однако, поправкой, что временные соотношения выполнения некоторых команд не выдерживаются). А если так, то процесс в свою очередь может быть ОС, так называемой гостевой (guest) ОС, которая в полном объеме управляет выделенным ей подмножеством ресурсов.

Другой вариант концепции виртуальной машины представляет интерфейс нижнего уровня системного программного обеспечения как полнофункциональный набор команд некоторой воображаемой машины. Все вышележащие уровни программного обеспечения пишутся в этом наборе команд (или компилируются в него). Программный модуль, готовый для выполнения, представляет собой двоичный код программы в командах виртуальной машины. Перевод команд виртуальной машины в команды конкретной аппаратной платформы выполняется нижележащим уровнем программного обеспечения в режиме перекомпиляции (например, AS/400 [18]) или интерпретации (например, технология Java [29]), компилятор или интерпретатор входит в состав нижнего уровня. Использование промежуточного кода в командах виртуальной машины обеспечивает переносимость программного обеспечения на другие платформы, так как все, в том числе и системное, программное обеспечения, лежащее выше уровня интерфейса виртуальной машины, является платформенно-независимым и при переносе не требует даже перекомпиляции.

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

Архитектурная концепция микроядра также обеспечивает переносимость системного программного обеспечения верхнего уровня (хотя и с необходимостью его перекомпиляции).

Набор преимуществ, обеспечиваемых микроядром, очень велик, и в разных системах это понятие трактуется по-разному - в зависимости от того, какие требования к системе являются доминирующими. Так, описанный выше подход минимизации кода, выполняемого в режиме ядра, и повышения эффективности в полной мере реализован, например, в ОС QNX [32]. В Windows NT/200 [16] микроядром называют часть, обеспечивающую независимость от внешнего оборудования и ряд функций режима ядра, но одним микроядром эти функции не исчерпываются. В AS/400[18] часть кода, лежащую ниже интерфейса виртуальной машины тоже иногда называют микроядром, хотя для программного обеспечения, состоящего из более, чем 1 млн. строк кода на языке C++, префикс "микро" вряд ли уместен.

Еще одной тенденцией в развитии ОС является объектно-ориентированный подход к их проектированию. Как известно, основными свойствами объектно-ориентированного программирования являются инкапсуляция, полиморфизм и наследование. Из указанных свойств в объектно-ориентированных ОС в полной мере реализуется прежде всего первое. Ресурсы в таких системах представляются в виде экземпляров тех или иных классов, внутренняя структура класса недоступна вне класса, но для класса определены методы работы с ним. Наряду с повышением степени интеграции тех базовых элементов, из которых строится ОС, инкапсуляция обеспечивает также защиту ресурсов и возможность менять в новых версиях ОС или при переносе на новую платформу структуру системных объектов без изменения тех программ, которые оперируют объектами. Для каждого типа объектов определен набор допустимых операций над ним. Свойство полиморфизма состоит в том, что для различных системных классов могут быть определены одноименные операции, выполнение которых для разных классов будет включать в себя как общие, так и специфические для каждого класса действия. Важнейшей из таких операций является получение доступа к объекту, отдельно рассматриваемое нами в главе 10. Свойство наследования реализуется в объектно-ориентированных ОС лишь отчасти, в связи с чем некоторые авторы (например, [18]) считают, что правильнее называть эти ОС объектно-базированными. В системах с иерархической структурой (Windows NT, AS/400) объекты более высокого уровня могут включать в себя объекты нижних уровней, однако, производные классы не наследуют методы базовых и, следовательно, их экземпляры не могут обрабатываться как экземпляры базового класса. Нельзя, однако, говорить об этом ограничении, как о недостатке, так как оно диктуется концепцией иерархической архитектуры: каждый уровень должен оперировать только объектами своего уровня.

Архитектурные концепции построения ОС не являются взаимоисключающими. Как вы, по-видимому, заметили из приводимых примеров, существуют системы, в архитектурах которых комбинируются несколько подходов.

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

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

Еще один важный вопрос - организация взаимодействия между модулями и здесь можно выделить две модели [14]: интерфейс процедур и интерфейс сообщений. Интерфейс процедур подразумевает непосредственное обращение вызывающего модуля к вызываемому, подобное обращению к подпрограмме в языках программирования. Обращение может быть либо действительно обращением к процедуре (команда CALL), либо сводиться к прерыванию и переключению процессов. Модель интерфейса процедур синхронная, то есть, как и при вызове подпрограммы, выполнение вызывающего модуля приостанавливается до получения результата вызова. Эта модель может быть построена на базе как процедурных модулей ОС, так и модулей-процессов. Другая модель обеспечивает взаимодействие процессов через единый системный механизм очередей. Процесс-клиент (в этой модели модули ОС должны быть именно процессами) оформляет свой запрос в виде сообщения и отправляет его процессу-серверу. Процесс-сервер получает сообщение из своей входной очереди, выполняет содержащийся в сообщении запрос и отправляет результат в виде сообщения процессу-клиенту. Процесс-клиент после отправки своего сообщения может либо продолжать выполняться, либо ожидать прихода ответного сообщения. Взаимодействие процессов, таким образом, происходит асинхронно.

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

Контрольные вопросы

  1. Один из авторов [11] заявляет, что он не может дать определения ОС, но сразу узнает ОС, если ее увидит. В чем, по-Вашему, состоит ошибочность такого утверждения?
  2. Прокомментируйте примечания 1-3 к определению ОС, данному в разделе 1.1. Покажите их отображения на реальные ОС.
  3. Дайте определение пакетному и интерактивному режимам функционирования ОС. Какой из режимов представляется Вам более полезным?
  4. В чем сходство работы многопользовательской ОС с ОС-сервером? В чем их различия?
  5. Каковы достоинства и недостатки изоляции пользователя от реальных ресурсов?
  6. Назовите основные состояния процесса в системе и охарактеризуйте переходы между ними. Какие состояния Вы считаете необязательными?
  7. Почему ОС, называемые объекто-ориентированными, правильнее называть объектно-базированными?
  8. Назовите общие черты архитектурных концепций микроядра, виртуальной машины и иерархической ОС. В чем различия между ними?
  9. В чем достоинства архитектуры микроядра? Почему разработчики стремятся минимизировать объем микроядра?
  10. Сравните способы обращения процесса к ОС: через вызов процедур и через прерывания. В чем достоинства и недостатки этих способов?

НазадОглавлениеВперед
Индекс