глава 2 (Методическое пособие по Операционным системам), страница 2

4. Уничтожение другим процессом (непреднамеренно).

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

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

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

Четвертой причиной завершения процесса может служить выполнение другим процессом системного запроса на уничтожение процесса. В UNIX такой системный запрос — kill, а соответствующая функция Win32 —TerminateProcess. В обоих слу­чаях «киллер» должен обладать cooтветствующими полномочиями по отношению к «убиваемому» процессу. В некоторых системах при завершении процесса (пред­намеренно или нет) все процессы, созданные процессом, также завершаются. Впро­чем, это не относится ни к UNIX, ни к Windows.

Иерархия процессов

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

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

Рассмотрим в качестве еще одного примера иерархии процессов инициализа­цию UNIX при запуске. В образе загрузки присутствует специальный процесс init. При запуске этот процесс считывает файл, в котором находится информация о количестве терминалов. Затем процесс разветвляется таким образом, чтобы каж­дому терминалу соответствовал один процесс. Процессы ждут, пока какой-нибудь пользователь не войдет в систему. Если пароль правильный, процесс входа в систе­му запускает оболочку для обработки команд пользователя, которые, в свою очередь, могут запускать процессы. Таким образом, все процессы в системе принадлежат к единому дереву, начинающемуся с процесса init. Напротив, в Windows не суще­ствует понятия иерархии процессов, и все процессы равноправны. Единственное, в чем проявляется что-то вроде иерархии процессов - создание процесса, в кото­ром родительский процесс получает специальный маркер (так называемый деск­риптор), позволяющий контролировать дочерний процесс. Но маркер можно пе­редать другому процессу, нарушая иерархию. В UNIX это невозможно.

Состояния процессов

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

cat chapter1l chapter2 chapter3 | grep tree

первый процесс, исполняющий файл cat, объединяет и выводит три файла. Вто­рой процесс, исполняющий файл grep, отбирает все строки, содержащие слово «tree». В зависимости от относительных скоростей процессов (скорости зависят от относительной сложности программ и процессорного времени, предоставляе­мого каждому процессу), может получиться, что grep уже готов к запуску, но вход­ных данных для этого процесса еще нет. В этом случае процесс блокируется до поступления входных данных,

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

1. Работающий (в этот конкретный момент использующий процессор).

2. Готовый к работе (процесс временно приостановлен, чтобы позволить вы­полняться другому процессу).

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

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

Как показано на рис. 2.2. между этими тремя состояниями возможны четыре перехода. Переход 1 происходит, когда процесс обнаруживает, что продолжение работы невозможно. В некоторых системах процесс должен выполнить системный запрос, например block или pause, чтобы оказаться в заблокированном состоянии, В других системах, как в UNIX, процесс автоматически блокируется, если при счи­тывании из канала или специального файла (предположим, терминала) входные данные не были обнаружены.

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

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

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

Реализация процессов

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

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

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

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

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

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

Таблица 2.2. Схема обработки прерывания нижним уровнем операционной системы

1. Аппаратное обеспечение сохраняет в стеке счетчик команд и т. л,

2. Аппаратное обеспечение загружает новый счетчик команд из вектора прерываний