Управление процессами

Модели выполнения

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

Режим с меньшими привилегиями часто называют пользовательским (user) режимом, потому что обычно в этом режиме выполняются пользовательские программы. Режим с более высокими привилегиями называется системным режимом (system mode), режимом управления (control mode) или режимом ядра (kernel mode). В последнем названии упоминается ядро, т.е. та часть операционной системы, которая выполняет важнейшие ее функции. В табл. 3.7 перечислены те из функций операционной системы, которые обычно возлагаются на ядро.

Таблица 3.7. Типичные функции ядра операционной системы

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

В связи с этим возникают два вопроса: каким образом процессор может определить, в каком режиме должна выполняться данная программа, и как происходит переключение из одного режима в другой? Что касается ответа на первый вопрос, то в слове состояния программы имеется бит, в котором указывается режим выполнения. При некоторых событиях происходит изменение этого бита. Например, если пользователь вызывает службу операционной системы, устанавливается режим ядра (обычно это происходит в результате выполнения команд изменения режима). В качестве примера приведем команду Change Mode (CHM), с помощью которой происходит переключение режима на машинах VAX. Когда пользователь вызывает службу операционной системы или когда в результате прерывания управление переходит к процедуре операционной системы, эта процедура выполняет команду СНМ, чтобы включить более привилегированный режим. Перед тем как вернуть управление пользовательскому процессу, она снова выполняет эту команду, переводя процессор в режим с меньшими привилегиями. Если же команду СНМ попытается выполнить пользовательская программа, это приведет к передаче управления операционной системе, и если такое изменение режима пользовательской программой не разрешено, произойдет ошибка выполнения.

Создание процессов

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

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

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

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

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

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

Переключение процессов

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

Когда нужно переключать процессы

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

Таблица 3.8. Механизмы прерывания процесса

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

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

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

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

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

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

Переключение режимов

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

1. Сохраняет контекст текущей программы.
2. Устанавливает в счетчике команд начальный адрес программы — обработчика прерываний.
3. Переключается из пользовательского режима в режим ядра, чтобы можно было выполнять привилегированные команды, содержащиеся в коде обработки прерывания.

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

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

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

Изменение состояния процесса

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

1. Сохранение контекста процессора, включая содержимое счетчика команд и других регистров.
2. Обновление управляющего блока выполняющегося в данное время процесса. Сюда входит изменение состояния процесса на одно из следующих: готовый, блокированный, готовый приостановленный или завершающийся. Кроме того, должно быть обновлено содержимое других полей с указанием причины переключения процесса из состояния выполнения, а также с сохранением информации по учету используемых ресурсов.
3. Помещение управляющего блока данного процесса в соответствующую очередь (очередь готовых к выполнению процессов; процессов, блокированных событием; очередь готовых приостановленных процессов).
4. Выбор следующего процесса для выполнения; эта тема исследуется в четвертой части книги.
5. Обновление управляющего блока выбранного процесса. Для этого процесса нужно установить состояние выполнения.
6. Обновление структур данных по управлению памятью. Понадобится ли эта информация, зависит от того, каким образом выполняется преобразование адресов (подробно эта тема рассматривается в третьей части книги).
7. Восстановление контекста процессора в состояние, в котором он находился, когда выбранный процесс был последний раз переключен из состояния выполнения. Это происходит путем загрузки содержимого программного счетчика и других регистров процессора.

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

Выполнение кода операционной системы

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

• Операционная система работает точно так же, как и обычная программа; т.е. она тоже является программой, которая выполняется процессором.
• Операционная система часто передает управление другим программам; возврат управления операционной системе зависит от процессора.

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

в) Функции операционной системы выполняются как отдельные процессы
Рис. 3.12. Взаимосвязь между операционной системой и пользовательскими процессами

Ядро вне процессов

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

Выполнение в составе пользовательских процессов

На небольших машинах (персональных компьютерах, рабочих станциях) часто применяется альтернативный подход, при котором почти все программы операционной системы выполняются в контексте пользовательского процесса. Разработчики таких систем придерживаются той точки зрения, что операционная система — это в основном набор процедур, которые вызываются для выяснения различных функций пользовательского процесса. Этот подход проиллюстрирован на рис. 3.12,6. Каждый процесс, принятый операционной системой на обработку, включает в себя не только блоки, изображенные на рис. 3.10, но и области кода, данных и стека программ ядра.

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

Рис. 3.13. Образ процесса: код операционной системы выполняется в пользовательском пространстве

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

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

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

Операционная система на основе процессов

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

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