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

Свойства процесса

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

Идентификаторы процесса

Процесс всегда имеет свой уникальный номер – PID (process ID). PID – это целое число в диапазоне допустимых целых чисел (для 32-х-разрядных систем – от 0 до 65535). Процесс номер 0 – это, обычно, процесс свопинга, фактически являющийся частью кода ядра. Процесс с номером 1 – это всегда init, процесс, который порождает все остальные процессы в системе при ее старте. У всех процессов, кроме init, есть родительский процесс, и каждому процессу, кроме его собственного идентификатора PID, соответствует идентификатор родительского процесса (PPID – parent process ID).

В таблице процессов, кроме идентификаторов PID и PPID, хранятся eUID (effective UID – эффективный идентификатор пользователя) владельца процесса и eGID (effective GID – эффективный идентификатор группы) группы процесса. Фактические (реальные) владелец и группа процесса – это пользователь и группа, которые запустили процесс, а эффективные владелец и группа процесса – это те, от имени которых запущен процесс. Для определения прав доступа используются эффективные идентификаторы, а для задач управления процессом (например, посылки сигнала процессам, которые запустил определенный пользователь, см. описание команды pkill ниже) – реальные. Эти идентификаторы передаются по наследству от родительского процесса к дочернему.

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

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

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

Посмотреть полный список процессов в системе с выводом их идентификаторов и ряда других параметров можно командой ps –ef.

Приоритеты процесса

Во многих системах UNIX процесс имеет базовый приоритет (NICE) и динамический приоритет (PRI). Базовый приоритет может принимать значение от -20 до +20. Чем меньше числовое значение базового приоритета NICE, тем выше приоритет. Процесс с отрицательным приоритетом -20 – самый высокоприоритетный. Динамический приоритет вычисляется планировщиком задач на основе базового приоритета по формуле, в которую входит общее потребленное процессом процессорное время. Чтобы дать возможность выполняться новым и более коротким процессам, динамический приоритет снижается с увеличением потребленного процессом времени процессора.

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

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

Приоритет базируется на классе планирования (scheduling class), Существует всего четыре таких класса: с разделением времени (timesharing), системный (system), реального времени (real-time) и планирования на основе справедливого раздела (fair class scheduling – FSS). У процессов разных классов планирования свои уровни приоритета и свои очереди на выполнение. Стало быть, в системе мы имеем четыре очереди к процессору. Внутри каждого класса процессы, стоящие в очереди, имеют свои уровни приоритета. Эти уровни отображаются в глобальные приоритеты планирования (global scheduling priorities). Первым процессор займет процесс, который имеет наивысший глобальный приоритет. По умолчанию процесс из класса планирования с разделением времени имеет более низкий глобальный приоритет, чем процесс из системного класса, а тот, в свою очередь, более низкий, чем процесс реального времени.

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

Получить информацию о текущих классах планирования процессов можно с помощью команды dispadmin.

Среда окружения

Каждый процесс имеет свою среду окружения – специальную область, в которой хранятся имена переменных и их значения. Среда окружения используется для модификации поведения процесса; так, в зависимости от значения переменной TERM текстовый редактор будет выдавать разные коды управления экраном, поскольку переменная TERM применяется для задания типа терминала. Переменные среды окружения могут быть помечены как экспортируемые: это означает, что такую переменную дочерний процесс унаследует от процесса-родителя. Такие переменные, как TERM, PATH, USER, обычно являются экспортируемыми. Из командной строки пометить переменную как экспортируемую можно с помощью команды export:

export TERM PATH

К переменным среды окружения легко обратиться из прикладной программы – для этого предусмутрен специальный массив строк

char *env[]

Аргументы

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

char *argv[]

Число аргументов обязательно передается в каждый процесс в переменной

int argc

Классы планирования

В Solaris есть шесть классов планирования: с разделением времени (timesharing, TS), интерактивный (interactive, IA), системный (system, SYS), реального времени (real-time, RT), с фиксированным приоритетом (fixed priority, FX) и планирования на основе долевого распределения (fair share scheduling, FSS).

По умолчанию процессы попадают в класс с разделением времени.

С помощью команды

ps –cl

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

Планирование процессов реального времени

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

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

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

В нестрогой среде реального времени период реакции должен иметь гарантированную конечную продолжительность (например, верхний предел времени, за которое приложение должно освободить процессор; в Solaris такой период составляет 5 миллисекунд).

В большинстве систем UNIX поддержки реального времени нет. Это связано с тем, что:

1. "промахи" обращения к памяти из-за отсутствия страниц в оперативной памяти могут вызвать непредсказуемую задержку из-за необходимости подгрузить требуемую страницу в память из swap-раздела;
2. хотя ядро является выгружаемым (preemptable), т.е. может быть смещено из процессора при запуске другого процесса, в некоторых ситуациях оно все же не может быть вытеснено из процессора, например, при обработке прерывания; элементы кода, которые не могут быть выгружены из процессора во время выполнения, называются "точками невыгружаемости" (nonpreemption points).

Решение первой из этих проблем в Solaris состоит в том, что все страницы процесса реального времени в памяти блокируются и их выгрузка на диск запрещается. Решение второй проблемы таково: ядро Solaris многопотоковое, обработчики прерываний реализованы как отдельные потоки, что делает возможным установить для них отдельный приоритет; более того, в Solaris есть priority lending – "одалживание приоритета": когда более приоритетный процесс нуждается в результатах работы менее приоритетного процесса, он может "одолжить" последнему на время свой высокий приоритет для выполнения требуемой задачи.