Разработка ядра Linux - читать бесплатно онлайн полную версию книги автора Роберт Лав (Глава 3 Управление процессами) #7

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

Процесс — одно из самых важных абстрактных понятий в Unix-подобных операционных системах[8]. По сути, процесс — это программа, т.е. объектный код, хранящийся на каком-либо носителе информации и находящийся в состоянии исполнения. Однако процесс — это не только исполняемый программный код, который для операционной системы Unix часто называется text section (сегмент текста или сегмент кода). Процессы также включают в себя сегмент данных (data section), содержащий глобальные переменные; набор ресурсов, таких как открытые файлы и ожидающие на обработку сигналы; адресное пространство и один или более потоков выполнения. Процесс — это живой результат выполнения программного кода.

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

В современных операционных системах процессы предусматривают наличие двух виртуальных ресурсов: виртуального процессора и виртуальной памяти. Виртуальный процессор создает для процесса иллюзию, что этот процесс монопольно использует всю компьютерную систему, за исключением, может быть, только того, что физическим процессором совместно пользуются десятки других процессов. В главе 4, "Планирование выполнения процессов", эта виртуализация обсуждается более подробно. Виртуальная память предоставляет процессу иллюзию того, что он один располагает всей памятью компьютерной системы. Виртуальной памяти посвящена глава 11, "Управление памятью". Потоки совместно используют одну и ту же виртуальную память, хотя каждый поток получает свой виртуальный процессор.

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

fork()

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

fork()

, называется порождающим (родительским, parent), новый процесс именуют порожденным (дочерний, child). Родительский процесс после этого продолжает выполнение, а порожденный процесс начинает выполняться с места возврата из системного вызова. Часто после разветвления в одном из процессов желательно выполнить какую-нибудь другую программу. Семейство функций

exec*()

позволяет создать новое адресное пространство и загрузить в него новую программу. В современных ядрах Linux функция

fork()

реализована через системный вызов

clone()

, который будет рассмотрен в следующем разделе.

Выход из программы осуществляется с помощью системного вызова

exit()

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

wait4()

[9], который заставляет один процесс ожидать завершения другого. Когда процесс завершается, он переходит в специальное состояние зомби (zombie), которое используется для представления завершенного процесса до того момента, пока порождающий его процесс не вызовет системную функцию

wait()

или

waitpid()

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

Дескриптор процесса и структура task structure

Ядро хранит информацию о всех процессах в двухсвязном списке, который называется task list[10] (список задач). Каждый элемент этого списка является дескриптором процесса и имеет тип структуры

struct task_struct

, которая описана в файле

include/linux/sched.h

. Дескриптор процесса содержит всю информацию об определенном процессе.

Структура

task_struct

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

Рис. 3.1. Дескриптор процесса и список задач

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

Память для структуры

task_struct

выделяется с помощью подсистемы выделения памяти, которая называется слябовый распределитель (slab allocator), для возможности повторного использования объектов и раскрашивания кэша (cache coloring) (см. главу 11, "Управление памятью"). В ядрах до серии 2.6 структура

task_struct

хранилась в конце стека ядра каждого процесса. Это позволяет для аппаратных платформ, у которых достаточно мало регистров процессора (как, например, платформа x86), вычислять местоположение дескриптора процесса, только зная значение регистра указателя стека (stack pointer), без использования дополнительных регистров для хранения самого адреса этого местоположения. Так как теперь дескриптор процесса создается с помощью слябового распределителя, была введена новая структура

thread_info

, которая хранится в области дна стека (для платформ, у которых стек растет в сторону уменьшения значения адреса памяти) или в области вершины стека (для платформ, у которых стек растет в сторону увеличения значения адреса памяти)[11] (рис. 3.2.).

Рис 3.2. Дескриптор процесса и стек ядра

Структура

struct thread_info

для платформы x86 определена в файле

в следующем виде.

struct thread_info {

 struct task_struct  *task;

 struct exec_domain  *exec_domain;

 unsigned long     flags;

 unsigned long     status;

 __u32         cpu;

 __s32         preempt_count;

 mm_segment_t     addr_limit;

 struct restart_block restart_block;

 unsigned       long previous_esp;

 __u8         supervisor_stack[0];

};

Для каждой задачи ее структура

thread_info

хранится в конце стека ядра этой задачи. Элемент структуры

thread_info

с именем

task

является указателем на структуру

task_struct

этой задачи.

Хранение дескриптора процесса

Система идентифицирует процессы с помощью уникального значения, которое называется идентификатором процесса (process identification, PID). Идентификатор

PID

— это целое число, представленное с помощью скрытого типа

pid_t

[12] , который обычно соответствует знаковому целому—

int

Однако, для обратной совместимости со старыми версиями ОС Unix и Linux максимальное значение этого параметра по умолчанию составляет всего лишь 32768 (что соответствует типу данных

short int

). Ядро хранит значение данного параметра в поле

pid

дескриптора процесса.

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

/proc/sys/kernel/pid_max

Обычно в ядре на задачи ссылаются непосредственно с помощью указателя на их структуры

task_struct

. И действительно, большая часть кода ядра, работающего с процессами, работает прямо со структурами

task_struct

. Следовательно, очень полезной возможностью было бы быстро находить дескриптор процесса, который выполняется в данный момент, что и делается с помощью макроса current. Этот макрос должен быть отдельно реализован для всех поддерживаемых аппаратных платформ. Для одних платформ указатель на структуру

task_struct

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

thread_info

хранится в стеке ядра. При этом вычисляется положение структуры

thread_info

, а вслед за этим и адрес структуры

task_struct

процесса.

Для платформы x86 значение параметра

current

вычисляется путем маскирования 13 младших бит указателя стека для получения адреса структуры

thread_info

. Это может быть сделано с помощью функции

current_thread_info()

. Соответствующий код на языке ассемблера показан ниже.

movl $-8192, %eax

andl %esp, %eax

Окончательно значение параметра

current

получается путем разыменования значения поля

task

полученной структуры

thread_info

current_thread_info()->task;

Для контраста можно сравнить такой подход с используемым на платформе PowerPC (современный процессор на основе RISC-архитектуры фирмы IBM), для которого значение переменной

current

хранится в регистре процессора

r2

. На платформе PPC такой подход можно использовать, так как, в отличие от платформы x86, здесь регистры процессора доступны в изобилии. Так как доступ к дескриптору процесса — это очень частая и важная операция, разработчики ядра для платформы PPC сочли правильным пожертвовать одним регистром для этой цели.

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

Поле

state

дескриптора процесса описывает текущее состояние процесса (рис. 3.3). Каждый процесс в системе гарантированно находится в одном из пяти различных состояний.

Рис. 3.3. Диаграмма состояний процесса

Эти состояния представляются значением одного из пяти возможных флагов, описанных ниже.

•

TASK_RUNNING

— процесс готов к выполнению (runnable). Иными словами, либо процесс выполняется в данный момент, либо находится в одной из очередей процессов, ожидающих на выполнение (эти очереди,

runqueue

, обсуждаются в главе 4. "Планирование выполнения процессов").

•

TASK_INTERRUPTIBLE

— процесс приостановлен (находится в состоянии ожидания, sleeping), т.е. заблокирован в ожидании выполнения некоторого условия. Когда это условие выполнится, ядро переведет процесс в состояние

TASK_RUNNING

. Процесс также возобновляет выполнение (wake up) преждевременно при получении им сигнала.

•

TASK_UNINTERRUPTIBLE

— аналогично

TASK_INTERRUPTIBLE

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

TASK_UNINTERRUPTIBLE

используется менее часто, чем

TASK_INTERRUPTIBLE

[13].

•

TASK_ZOMBIE

— процесс завершен, однако порождающий его процесс еще не вызвал системный вызов

wait4()

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

wait4()

, то такой дескриптор освобождается.

•

TASK_STOPPED

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

SIGSTOP

SIGTSTP

SIGTTIN

или

SIGTTOU

, а также если сигнал приходит в тот момент, когда процесс находится в состоянии отладки.

Манипулирование текущим состоянием процесса

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

set_task state(task, state);

/* установить задание 'task' в состояние 'state' */

которая устанавливает указанное состояние для указанной задачи. Если применимо, то эта функция также пытается применить барьер памяти (memory barrier), чтобы гарантировать доступность установленного состояния для всех процессоров (необходимо только для SMP-систем). В других случаях это эквивалентно выражению:

task->state = state;

Вызов

set_current_state(state)

является синонимом к вызову

set_task_state(current, state)

Контекст процесса

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

С этого момента говорят, что ядро "выполняется от имени процесса" и делает это в контексте процесса. В контексте процесса макрос

current

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

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

Дерево семейства процессов

В операционной системе Linux существует четкая иерархия процессов. Все процессы являются потомками процесса

init

, значение идентификатора

PID

для которого равно 1. Ядро запускает процесс

init

на последнем шаге процедуры загрузки системы. Процесс

init

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

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

task_struct

содержит указатель на структуру

task_struct

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

children

. Следовательно, если известен текущий процесс (

current

), то для него можно определить дескриптор родительского процесса с помощью выражения:

struct task_struct *task = current->parent;

Аналогично можно выполнить цикл по процессам, порожденным от текущего процесса, с помощью кода:

struct task_struct *task;

struct list_head *list;

list_for_each(list, ¤t->children) {

 task = list_entry(list, struct task_struct, sibling);

 /* переменная task теперь указывает на один из процессов,

   порожденных текущим процессом */

Дескриптор процесса

init

— это статически выделенная структура данных с именем

init_task

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

struct task_struct *task;

for (task = current; task != $init_task; task = task->parent)

/* переменная task теперь указывает на процесс init */

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

list_entry(task->tasks.next, struct task_struct, tasks);

Получение указателя на предыдущее задание работает аналогично.

list_entry(task->tasks.prev, struct task_struct, tasks);

Дна указанных выше выражения доступны также в виде макросов

next_task(task)

(получить следующую задачу),

prev_task(task)

(получить предыдущую задачу). Наконец, макрос

for_each_process(task)

позволяет выполнить цикл по всему списку задач. На каждом шаге цикла переменная

task

указывает на следующую задачу из списка:

struct task_struct *task;

for_each_process(task) {

 /* просто печатается имя команды и идентификатор PID

   для каждой задачи */

 printk("%s[%d]\n", task->comm, task->pid);

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

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

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

fork()

exec()

[15].

В начале с помощью функции

fork()

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

PID

(который является уникальным в системе), значением параметра

PPID

(идентификатор

PID

родительского процесса, который устанавливается в значение

PID

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

exec()

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

fork()

exec()

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

Копирование при записи

Традиционно при выполнении функции

fork()

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

fork()

реализован с использованием механизма копирования при записи (copy-on-write) страниц памяти. Технология копирования при записи (copy-on-write, COW) позволяет отложить или вообще предотвратить копирование данных. Вместо создания дубликата адресного пространства процесса родительский и порожденный процессы могут совместно использовать одну и ту же копию адресного пространства. Однако при этом данные помечаются особым образом, и если вдруг один из процессов начинает изменять данные, то создается дубликат данных, и каждый процесс получает уникальную копию данных. Следовательно, дубликаты ресурсов создаются только тогда, когда в эти ресурсы осуществляется запись, а до того момента они используются совместно в режиме только для чтения (read-only). Такая техника позволяет задержать копирование каждой страницы памяти до того момента, пока в эту страницу памяти не будет осуществляться запись. В случае, если в страницы памяти никогда не делается запись, как, например, при вызове функции

exec()

сразу после вызова

fork()

, то эти страницы никогда и не копируются. Единственные накладные расходы, которые вносит вызов функции

fork()

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

Функция

fork()

В операционной системе Linux функция

fork()

реализована через системный вызов

clone()

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

fork()

vfork()

__clone()

вызывают системную функцию

clone()

с соответствующими флагами. В свою очередь системный вызов

clone()

вызывает функцию ядра

do_fork()

Основную массу работы по разветвлению процесса выполняет функция

do_fork()

, которая определена в файле

kernel/fork.c

. Эта функция, в свою очередь, вызывает функцию

copy_process()

и запускает новый процесс на выполнение. Ниже описана та интересная работа, которую выполняет функция

copy_process()

• Вызывается функция

dup_task_struct()

, которая создает стек ядра, структуры

thread_info

task_struct

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

• Проверяется, не произойдет ли при создании нового процесса переполнение лимита на количество процессов для данного пользователя.

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

• Далее состояние порожденного процесса устанавливается в значение

TASK_UNINTERRUPTIBLE

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

• Из функции

copy_process()

вызывается функция

copy_flags()

, которая обновляет значение поля

flags

структуры

task struct

. При этом сбрасывается флаг

PF_SUPERPRIV

, который определяет, имеет ли процесс права суперпользователя. Флаг

PF_FORKNOEXEC

, который указывает на то, что процесс не вызвал функцию

exec()

, — устанавливается.

• Вызывается функция

get_pid()

, которая назначает новое значение идентификатора

PID

для новой задачи.

• В зависимости от значений флагов, переданных в функцию

clone()

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

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

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

Далее происходит возврат в функцию

do_fork()

. Если возврат из функции

copy_process()

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

В обычной ситуации, когда порожденный процесс сразу же вызывает функцию

exec()

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

Функция

vfork()

Системный вызов

vfork()

позволяет получить тот же эффект, что и системный вызов

fork()

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

exec()

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

fork()

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

vfork()

— это отсутствие копирования таблиц страниц родительского процесса. Если когда-нибудь в операционной системе Linux будет реализовано копирование полей таблиц страниц при записи[17], то вообще не останется никаких преимуществ. Поскольку семантика функции

vfork()

достаточно ненадежна (что, например, будет, если вызов

exec()

завершится неудачно?), то было бы здорово, если бы системный вызов

vfork()

умер медленной и мучительной смертью. Вполне можно реализовать системный вызов

vfork()

через обычный вызов

fork()

, что действительно имело место в ядрах Linux до версии 2.2.

Сейчас системный вызов

vfork()

реализован через специальный флаг в системном вызове

clone()

, как показано ниже.

• При выполнении функции

copy_process()

поле

vfork_done

структуры

task_struct

устанавливается в значение

NULL

• При выполнении функции

do_fvork()

, если соответствующий флаг установлен, поле

vfork_done

устанавливается в ненулевое значение (начинает указывать на определенный адрес).

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

copy_process()

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

vfork_done

• При выполнении порожденным процессом функции

mm_release()

(которая вызывается, когда задание заканчивает работу со своим адресным пространством), если значение поля

vfork_done

не равно

NULL

, родительский процесс получает указанный выше сигнал.

• При возврате в функцию

do_fork()

родительский процесс возобновляет выполнение и выходит из этой функции.

Если все прошло так, как запланировано, то теперь порожденный процесс выполняется в новом адресном пространстве, а родительский процесс — в первоначальном адресном пространстве. Накладные расходы меньше, но реализация не очень привлекательна.

Реализация потоков в ядре Linux

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

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

task_struct

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

В этом смысле Linux отличается от других операционных систем, таких как Microsoft Windows или Sun Solaris, которые имеют явные средства поддержки потоков в ядре (в этих системах иногда потоки называются процессами с быстрым переключением контекста, lightweight process). Название "процесс с быстрым переключением контекста" показывает разницу между философией Linux и других операционных систем. Для остальных операционных систем потоки— это абстракция, которая обеспечивает облегченные, более быстрые для исполнения сущности, чем обычные тяжелые процессы. Для операционной системы Linux потоки — это просто способ совместного использования ресурсов несколькими процессами (которые и так имеют достаточно малое время переключения контекста)[18].

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

task_struct

. Четыре процесса построены так, чтобы совместно использовать определенные ресурсы.

Потоки создаются так же, как и обычные задания, за исключением того, что в системный вызов

clone()

передаются флаги с указанием, какие ресурсы должны использоваться совместно:

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0);

Результат выполнения показанного кода будет таким же, как и при выполнении обычного вызова

fork()

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

fork()

может быть реализован следующим образом:

clone(SIGCHLD, 0);

а вызов

vfork()

в таком виде:

clone(CLONE_VFORK | CLONE_VM | SIGCHLD, 0);

Флаги, которые передаются в системный вызов

clone()

, помогают указать особенности поведения нового процесса и детализировать, какие ресурсы должны быть общими для родительского и порожденного процессов. В табл. 3.1 приведены флаги системного вызова

clone()

и их эффект.

Таблица 3.1. Флаги системного вызова clone()

Флаг	Описание
`CLONE_FILES`	Родительский и порожденный процессы совместно используют открытые файлы
`CLONE_FS`	Родительский и порожденный процессы совместно используют информацию о файловой системе
`CLONE_IDLETASK`	Установить значение PID в нуль (используется только для холостых (idle) задач)
`CLONE_NEWNS`	Создать новое пространство имен для порожденной задачи
`CLONE_PARENT`	Родительский процесс вызывающего процесса становится родительским и для порожденного
`CLONE_PTRACE`	Продолжить трассировку и для порожденного процесса
`CLONE_SETTID`	Возвратить значение идентификатора TID в пространство пользователя
`CLONE_SETTLS`	Для порожденного процесса создать новую область локальных данных потока (thread local storage, TLS)
`CLONE_SIGHAND`	У порожденного и родительского процессов будут общие обработчики сигналов
`CLONE_SYSVSEM`	У родительского и порожденного процессов будет общая семантика обработки флага `SEM_UNDO` для семафоров System V
`CLONE_THREAD`	Родительский и порожденный процессы будут принадлежать одной группе потоков
`CLONE_VFORK`	Использовать `vfork()` : родительский процесс будет находиться а приостановленном состоянии, пока порожденный процесс не возобновит его работу
`CLONE_UNTRACED`	Запретить родительскому процессу использование флага `CLONE_PTRACE` для порожденного процесса
`CLONE_STOP`	Запустить процесс в состоянии `TASK_STOPPED`
`CLONE_CHILD_CLEARTID`	Очистить идентификатор TID для порожденного процесса
`CLONE_CHILD_SETTID`	Установить идентификатор TID для порожденного процесса
`CLONE_PARENT_SETTID`	Установить идентификатор TID для родительского процесса
`CLONE_VM`	У порожденного и родительского процессов будет общее адресное пространство

Потоки в пространстве ядра

Часто в ядре полезно выполнить некоторые операции в фоновом режиме. В ядре такая возможность реализована с помощью потоков пространства ядра (kernel thread) — обычных процессов, которые выполняются исключительно в пространстве ядра. Наиболее существенным отличием между потоками пространства ядра и обычными процессами является то, что потоки в пространстве ядра не имеют адресного пространства (значение указателя

mm

для них равно

NULL

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

В ядре Linux потоки пространства ядра выполняют определенные задания, наиболее часто используемые, — это pdfush и ksoftirq. Эти потоки создаются при загрузке системы другими потоками пространства ядра. В действительности поток в пространстве ядра может быть создан только другим потоком, работающим в пространстве ядра. Интерфейс для запуска нового потока в пространстве ядра из уже существующего потока следующий:

int kernel_thread(int (*fn)(void*), void* arg, unsigned long flags);

Новая задача создается с помощью обычного системного вызова

clone()

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

task_struct

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

fn

, в качестве аргумента этой функции передается параметр

arg

. Для указания обычных флагов потоков пространства ядра существует флаг

CLONE_KERNEL

, который объединяет в себе флаги

CLONE_FS

CLONE_FILES

CLONE_SIGHAND

, так как большинство потоков пространства ядра должны указывать эти флаги в параметре

flags

Чаще всего поток пространства ядра продолжает выполнять свою функцию вечно (или, по крайней мере, до перегрузки системы, но когда она произойдет в случае ОС Linux- неизвестно). Функция потока обычно содержит замкнутый цикл, в котором поток пространства ядра по необходимости возобновляет выполнение, исполняет свои обязанности и снова переходит в приостановленное состояние.

В следующих главах более детально будут рассмотрены конкретные примеры потоков пространства ядра.

Завершение процесса

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

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

exit()

явно или неявно при выходе из главной функции программы (компилятор языка С помещает вызов функции

exit()

после возврата из функции

main()

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

do_exit(),

а именно указанные далее операции.

• Устанавливается флаг

PF_EXITING

в поле

flags

структуры

task struct

• Вызывается функция

del_timer_sync()

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

• Если включена возможность учета системных ресурсов, занятых процессами (BSD process accounting), то вызывается функция

acct_process()

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

• Вызывается функция

__exit_mm()

для освобождения структуры

mm_struct

, занятой процессом. Если эта структура не используется больше ни одним процессом (другими словами, не является разделяемой), то она освобождается совсем.

• Вызывается функция

exit_sem()

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

• Вызываются функции

__exit_files()

__exit_fs()

exit_namespace()

exit_signals()

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

• Устанавливается код завершения задания, который хранится в поле

exit_code

структуры

task struct

. Значение этого кода передается как аргумент функции

exit()

или задается тем механизмом ядра, из-за которого процесс завершается.

• Вызывается функция

exit_notify()

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

init

. Состояние завершающегося процесса устанавливается в значение

TASK_ZOMBIE

• Вызывается функция

schedule()

для переключения на новый процесс (см. главу 4, "Планирование выполнения процессов"). Поскольку процесс в состоянии

TASK_ZOMBIE

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

Исходный код функции

do_exit()

описан в файле

kernel/exit.c

К этому моменту освобождены все объекты, занятые задачей (если они используются только этой задачей). Задача больше не может выполняться (действительно, у нее больше нет адресного пространства, в котором она может выполняться), а кроме того, состояние задачи —

TASK_ZOMBIE

Единственные области памяти, которые теперь занимает процесс, — это стек режима ядра и слябовый объект, соответственно содержащие структуры

thread_info

task_struct

Задание завершено настолько, насколько остается возможность передать необходимую информацию родительскому процессу.

Удаление дескриптора процесса

После возврата из функции

do_exit()

дескриптор завершенного процесса все еще существует в системе, но процесс находится в состоянии

TASK_ZOMBIE

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

task_struct

порожденного процесса освобождается.

Семейство функций

wait()

реализовано через единственный (и достаточно сложный) системный вызов

wait4()

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

PID

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

Когда приходит время окончательно освободить дескриптор процесса, вызывается функция

release_task()

, которая выполняет указанные ниже операции.

• Вызывается функция

free_uid()

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

• Вызывается функция

unhash_process()

для удаления процесса из хеш-таблицы идентификаторов процессов

pidhash

и удаления задачи из списка задач.

• Если задача была в состоянии трассировки (ptrace), то родительским для нее снова назначается первоначальный родительский процесс и задача удаляется из списка задач, которые находятся в состоянии трассировки (ptrace) данным процессом.

• В конце концов вызывается функция

put_task_struct()

для освобождения страниц памяти, содержащих стек ядра процесса и структуру

thread_info

, a также освобождается слябовый кэш, содержащий структуру

task_struct

На данном этапе дескриптор процесса, а также все ресурсы, которые принадлежали только этому процессу, освобождены.

Дилемма "беспризорного" процесса

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

init

. При выполнении функции

do_exit()

вызывается функция

notify_parent()

, которая в свою очередь вызывает

forget_original_parent()

для осуществления переназначения родительского процесса (reparent), как показано ниже.

struct task_struct *p, *reaper = father;

struct list_head *list;

if (father->exit_signal != -1)

 reaper = prev_thread(reaper);

else

 reaper = child_reaper;

if (reaper == father)

 reaper = child_reaper;

Этот программный код присваивает переменной reaper указатель на другое задание в группе потоков данного процесса. Если в этой группе потоков нет другого задания, то переменной

reaper

присваивается значение переменной

child_reaper,

которая содержит указатель на процесс

init

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

list_for_each(list, &father->children) {

 p = list_entry(list, struct task_struct, sibling);

 reparent_thread(p, reaper, child_reaper);

list_for_each(list, &father->ptrace_children) {

 p = list_entry(list, struct task_struct, ptrace_list);

 reparent_thread(p, reaper, child_reaper);

В этом программном коде организован цикл по двум спискам: по списку порожденных процессов child list и по списку порожденных процессов, находящихся в состоянии трассировки другими процессами ptraced child list. Основная причина, по которой используется именно два списка, достаточно интересна (эта новая особенность появилась в ядрах серии 2.6). Когда задача находится в состоянии ptrace, для нее временно назначается родительским тот процесс, который осуществляет отладку (debugging). Когда завершается истинный родительский процесс для такого задания, то для такой дочерней задачи также нужно осуществить переназначение родительского процесса. В ядрах более ранних версий это приводило к необходимости организации цикла по всем заданиям системы для поиска порожденных процессов. Решение проблемы, как было указано выше, — это поддержка отдельного списка для порожденных процессов, которые находятся в состоянии трассировки, что уменьшает число операций поиска: происходит переход от поиска порожденных процессов по всему списку задач к поиску только по двум спискам с достаточно малым числом элементов.

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

init

периодически вызывает функцию

wait()

для всех своих порожденных процессов и, соответственно, удаляет все зомби-процессы, назначенные ему.

Резюме

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

task_struct

thread_info

), как создаются процессы (вызовы

clone()

fork()

), каким образом новые исполняемые образы загружаются в адресное пространство (семейство вызовов

exec()

), иерархия процессов, каким образом родительский процесс собирает информацию о своих потомках (семейство функций

wait()

) и как в конце концов процесс завершается (непроизвольно или с помощью вызова

exit()

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

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