Операционные системы. Управление ресурсами
Ядро и процессы
Прежде чем приступать к изложению основного материала этого раздела, сделаем несколько общих замечаний о принципах управления ресурсами и о представлении их в нашем пособии.
Ядром (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).
В заключение раздела необходимо сделать некоторые обобщения, важные для нашей дальнейшей работы. Мы показали, что процесс с точки зрения ОС представляется блоком контекста. Обобщение этого принципа можно сформулировать так: активные объекты с точки зрения ниже лежащего уровня представляются структурами данных. Вот пример такого подхода: машинная команда с точки зрения программиста является активной единицей, так как она выполняет некоторые действия, но с точки зрения процессора команда - структура данных, содержащая поля кода операции и операндов и подлежащая обработке по алгоритмам процессора. Пример из совершенно другой области: сотрудник любого учреждения безусловно считает себя активной личностью, но с точки зрения отдела кадров он - всего лишь стандартная карточка учета, и все его перемещения по службе осуществляются простым изменением в графах этой карточки.
Поскольку наше рассмотрение будет сосредоточено в основном на нижних уровнях, становится очевидным, что первостепенную важность для нас имеют структуры данных, описывающие объекты, которые обрабатываются в ОС, и алгоритмы их обработки. Блок контекста процесса - первая из таких структур данных. При представлении системных структур данных мы решили отказаться в большинстве случаев от попыток представить их сколько-нибудь формализовано, например, средствами какого-либо языка программирования. Такой отказ объясняется тем, что мы стремились избежать даже намека на то, что та или иная структура является универсальной, обязательной, фиксированной для всех ОС - это ни в коем случае не так. Состав компонентов таких структур, их именование, взаимное расположение, типы данных и т.д. чрезвычайно разнятся для разных ОС в соответствии с их назначением и даже личными вкусами разработчиков. Поэтому мы ограничиваемся самым свободным описанием структур - простым перечислением той информации, которая в большинстве случаев должна в них содержаться. Описания структур средствами языка программирования или в виде таблиц мы будем применять только там, где речь будет идти о конкретных ОС.
При решении некоторых задач управления ресурсами ОС должна создавать интегрированные структуры данных, содержащие набор объектов одинакового типа. Списки процессов - пример таких интегрированных структур. Как известно, имеется два общих метода представления таких структур в памяти: смежное представление и связное представление. Конструктор ОС также свободен в выборе того или иного метода для представления той или иной интегрированной структуры. Мы в дальнейшем будем употреблять термин "таблица" - для обозначения интегрированной структуры, которая скорее всего (но не обязательно) реализуется смежным представлением, и "список" - для структуры, которая реализуется скорее всего связным представлением.
