Операционная система UNIX - страница 106

События, в ожидании которых "засыпают" процессы, не являются равноценными.

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

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

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

Процесс завершает свое выполнение с помощью функции >exit(). Эта функция может быть вызвана системным вызовом exit(2), а если завершение процесса вызвано получением сигнала, функцию >exit() вызывает само ядро. Функция >exit() выполняет следующие действия:

□ Отключает все сигналы.

□ Закрывает все открытые файлы.

□ Сохраняет статистику использования вычислительных ресурсов и код возврата в записи >proc таблицы процессов.

□ Изменяет состояние процесса на "зомби".

□ Делает процесс init(1M) родительским для всех потомков данного процесса.

□ Освобождает адресное пространство процесса, u-area, карты отображения и области свопинга, связанные с процессом.

□ Отправляет сигнал >SIGCHLD родительскому процессу, уведомляя его о "смерти" потомка.

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

□ Запускает функцию переключения контекста, в результате чего высокоприоритетный процесс получает доступ к вычислительным ресурсам.

После завершения выполнения функции >exit() процесс находится в состоянии "зомби". При этом от процесса остается запись >proc в таблице процессов, содержащая статистику использования вычислительных ресурсов и код возврата. Эта информация может потребоваться родительскому процессу, поэтому освобождение структуры proc производит родитель с помощью системного вызова wait(2) возвращающего статистику и код возврата потомка. Если родительский процесс заканчивает свое выполнение раньше потомка, "родительские права" переходят к процессу init(1M). В этом случае после смерти потомка init(1M) делает системный вызов wait(2) и освобождает структуру