Второе издание
 Скачать 3.09 Mb.
|
|
Функция fork () В операционной системе Linux функция fork () реализована через системный вызов c l o n e () . Этот системный вызов может принимать в качестве аргументов набор флагов, определяющих, какие ресурсы должны быть общими (если вообще должны) у родительского и порожденного процессов. Далее в разделе "Реализация потоков в ядре Linux" об этих флагах рассказано более подробно. Библиотечные вызовы f o r k ( ) , v f o r k ( ) и c l o n e d вызывают системную функцию c l o n e () с соответствующими флагами. В свою очередь системный вызов c l o n e () вызывает функцию ядра do_fork (). 54 Глава 3 Основную массу работы по разветвлению процесса выполняет функция do_f ork (), которая определена в файле kernel/fork.с. Эта функция, в свою очередь, вызыва- ет функцию copy_pracess () и запускает новый процесс на выполнение. Ниже опи- сана та интересная работа, которую выполняет функция copy_process (). • Вызывается функция dup_task_struct (), которая создает стек ядра, струк- туры thread_info и task_struct для нового процесса, причем все значения указанных структур данных идентичны для порождающего и порожденного процессов. На этом этапе дескрипторы родительского и порожденного про- цессов идентичны. • Проверяется, не произойдет ли при создании нового процесса переполнение лимита на количество процессов для данного пользователя. • Теперь необходимо сделать порожденный процесс отличным от родительско- го. При этом различные поля дескриптора порожденного процесса очищаются или устанавливаются в начальные значения. Большое количество данных де- скриптора процесса является совместно используемым. • Далее состояние порожденного процесса устанавливается в значение TASK_ UNINTERRUPTIBLE, чтобы гарантировать, что порожденный процесс не будет выполняться. • Из функции copy_process () вызывается функция copy_f lags (), которая об- новляет значение поля flags структуры task struct. При этом сбрасывается флаг PF_SUPERPRIV, который определяет, имеет ли процесс права суперполь- зователя. Флаг PF_FORKNOEXEC, который указывает на то, что процесс не вы- звал функцию exec (), — устанавливается. • Вызывается функция get_pid () , которая назначает новое значение иденти- фикатора PID для новой задачи. • В зависимости от значений флагов, переданных в функцию clone (), осущест- вляется копирование или совместное использование открытых файлов, инфор- мации о файловой системе, обработчиков сигналов, адресного пространства процесса и пространства имен (namespace). Обычно эти ресурсы совместно ис- пользуются потоками одного процесса. В противном случае они будут уникаль- ными и будут копироваться на этом этапе. • Происходит разделение оставшейся части кванта времени между родитель- ским и порожденным процессами (это более подробно обсуждается в главе 4, "Планирование выполнения процессов"). • Наконец, происходит окончательная зачистка структур данных и возвращается указатель на новый порожденный процесс. Далее происходит возврат в функцию do_fork () . Если возврат из функции copy_process () происходит успешно, то новый порожденный процесс возобновля- ет выполнение. Порожденный процесс намеренно запускается на выполнение рань- ше родительского 9 9 В действительности сейчас это работает не так, как хотелось бы, однако усилия прилагаются к тому, чтобы порожденный процесс запускался на выполнение первым. Управление процессами 55 В обычной ситуации, когда порожденный процесс сразу же вызывает функцию exec () , это позволяет избежать накладных расходов, связанных с тем, что если родительский процесс начинает выполняться первым, то он будет ожидать возмож- ности записи в адресное пространство посредством механизма копирования при за- писи. Функция vfork () Системный вызов vfork () позволяет получить тот же эффект, что и системный вызов fork (), за исключением того, что записи таблиц страниц родительского про- цесса не копируются. Вместо этого порожденный процесс запускается как отдель- ный поток в адресном пространстве родительского процесса и родительский про- цесс блокируется до того момента, пока порожденный процесс не вызовет функцию exec () или не завершится. Порожденному процессу запрещена запись в адресное пространство. Такая оптимизация была желанной в старые времена 3BSD, когда реализация системного вызова fork () не базировалась на технике копирования страниц памяти при записи. Сегодня, при использовании техники копирования страниц памяти при записи и запуске порожденного процесса перед родительским, единственное преимущество вызова vfork () — это отсутствие копирования таблиц страниц родительского процесса. Если когда-нибудь в операционной системе Linux будет реализовано копирование полей таблиц страниц при записи 10 , то вообще не останется никаких преимуществ. Поскольку семантика функции 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() родительский процесс возобновляет вы- полнение и выходит из этой функции. 10 В действительности уже сейчас есть заплаты для добавления такой функции в ОС Linux. Хотя, ско- рее всего, возможность совместного использования таблиц страниц в ядрах серии 2.6 реализована не будет, такая возможность может появиться в будущих версиях. 56 Глава 3 Если все прошло так, как запланировано, то теперь порожденный процесс выпол- няется в новом адресном пространстве, а родительский процесс — в первоначальном адресном пространстве. Накладные расходы меньше, но реализация не очень при- влекательна. Реализация потоков в ядре Linux Многопоточность — это популярная сегодня программная абстракция. Она обе- спечивает выполнение нескольких потоков в совместно используемом адресном про- странстве памяти. Потоки также могут совместно использовать открытые файлы и другие ресурсы. Многопоточность используется для параллельного программирования (concurrent programming), что на многопроцессорных системах обеспечивает истинный параллелизм. Реализация потоков в операционной системе Linux уникальна. Для ядра Linux не существует отдельной концепции потоков. В ядре Linux потоки реализованы так же, как и обычные процессы. В ОС Linux нет никакой особенной семантики для планирования выполнения потоков или каких-либо особенных структур данных для представления потоков. Поток— это просто процесс, который использует не- которые ресурсы совместно с другими процессами. Каждый поток имеет структуру t a s k _ s t r u c t и представляется для ядра обычным процессом (который совместно использует ресурсы, такие как адресное пространство, с другими процессами). В этом смысле Linux отличается от других операционных систем, таких как Microsoft Windows или Sun Solaris, которые имеют явные средства поддержки пото- ков в ядре (в этих системах иногда потоки называются процессами с быстрым пере- ключением контекста, lightweight process). Название "процесс с быстрым переключени- ем контекста" показывает разницу между философией Linux и других операционных систем. Для остальных операционных систем потоки— это абстракция, которая обеспечивает облегченные, более быстрые для исполнения сущности, чем обычные тяжелые процессы. Для операционной системы Linux потоки — это просто способ совместного использования ресурсов несколькими процессами (которые и так име- ют достаточно малое время переключения контекста) 11 Допустим, у нас есть процесс, состоящий из четырех потоков. В операционных системах с явной поддержкой потоков должен существовать дескриптор процесса, который далее указывает на четыре потока. Дескриптор процесса описывает со- вместно используемые ресурсы, такие как адресное пространство и открытые фай- лы. Потоки описываются ресурсами, которые принадлежат только им. В ОС Linux, наоборот, существует просто четыре процесса и, соответственно, четыре обычные структуры t a s k _ s t r u c t . Четыре процесса построены так, чтобы совместно исполь- зовать определенные ресурсы. Потоки создаются так же, как и обычные задания, за исключением того, что в системный вызов clone () передаются флаги с указанием, какие ресурсы должны ис- пользоваться совместно: Clone (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0 ) ; 11 Как пример можно привести тесты по измерению времени создания процессов (и даже потоков) и операционной системе Linux по сравнению с другими операционными системами. Результаты очень хорошие. Управление процессами - 57 Результат выполнения показанного кода будет таким же, как и при выполнении обычного вызова f o r k (), за исключением того, что адресное пространство, ресур- сы файловой системы, дескрипторы файлов и обработчики сигналов останутся об- щими. Другими словами, новая задача, так же как и родительский процесс, — обыч- ные потоки. В отличие от этого, обычный вызов f o r k () может быть реализован следующим образом: clone (SIGCHLD, 0 ) ; а вызов vfork () в таком виде: clone (CLONE_VFORK | CLONE_VM | SIGCHLD, 0); Флаги, которые передаются в системный вызов c l o n e () , помогают указать осо- бенности поведения нового процесса и детализировать, какие ресурсы должны быть общими для родительского и порожденного процессов. В табл. 3.1 приведены флаги системного вызова clone () и их эффект. Таблица 3.1. Флаги системного вызова c l o n e () Флаг Описание CLONE_FILES CLONE_FS CLONE_IDLETASK CLONE_NEWNS CLONE_PARENT CLONE_PTRACE CLONE_SETTID CLONE_SETTLS CLONE_SIGHAND CLONE_SYSVSEM CLONE_THREAD CLONE_VFOK CLONE_ONTRACED CLONE_3T0P CLONE_CHILD_CLEARTID CLONE_CHILD_SETTID CLONE_PARENT_SETTID CLONE_VM 58 Глава 3 Родительский и порожденный процессы совместно используют открытые файлы Родительский и порожденный процессы совместно используют информацию о файловой системе Установить значение PID в нуль (используется только для холостых (idle) задач) Создать новое пространство имен для порожденной задачи Родительский процесс вызывающего процесса становится родитель- ским и для порожденного Продолжить трассировку и для порожденного процесса Возвратить значение идентификатора TID в пространство пользовател? Для порожденного процесса создать новую область локальных дан- ных потока (thread local storage, TLS) У порожденного и родительского процессов будут общие обработчи- ки сигналов У родительского и порожденного процессов будет общая семантика обработки флага SEM_UNDO ДЛЯ семафоров System V Родительский и порожденный процессы будут принадлежать одной группе потоков Использовать v f o r k (): родительский процесс будет находиться а приостановленном состоянии, пока порожденный процесс не воз- обновит его работу Запретить родительскому процессу использование флага CLONE_PTRACE для порожденного процесса Запустить процесс в состоянии TASK_STOPPED Очистить идентификатор TID для порожденного процесса Установить идентификатор TID для порожденного процесса Установить идентификатор TID для родительского процесса У порожденного и родительского процессов будет общее адресное пространство Потоки в пространстве ядра Часто в ядре полезно выполнить некоторые операции в фоновом режиме. В ядре такая возможность реализована с помощью потоков пространства ядра (kernel thread) — обычных процессов, которые выполняются исключительно в пространстве ядра. Наиболее существенным отличием между потоками пространства ядра и обычными процессами является то, что потоки в пространстве ядра не имеют адресного про- странства (значение указателя mm для них равно NULL). Эти потоки работают только в пространстве ядра, и их контекст не переключается в пространство пользователя. Тем не менее потоки в пространстве ядра планируются и вытесняются так же, как и обычные процессы. В ядре Linux потоки пространства ядра выполняют определенные задания, наиболее часто используемые, — это pdflush и ksoftirq. Эти потоки создаются при за- грузке системы другими потоками пространства ядра. В действительности поток в пространстве ядра может быть создан только другим потоком, работающим в про- странстве ядра. Интерфейс для запуска нового потока в пространстве ядра из уже существующего потока следующий: int kernel_thread(int (*fn) (void * ) , void * arg, unsigned long flags) Новая задача создается с помощью обычного системного вызова clone () с соот- ветствующими значениями флагов, указанными в параметре f l a g s . При возврате из системного вызова родительский поток режима ядра завершается и возвращает ука- затель на структуру t a s k _ s t r u c t порожденного процесса. Порожденный процесс выполняет функцию, адрес которой указан в параметре fn, в качестве аргумента этой функции передается параметр arg. Для указания обычных флагов потоков про- странства ядра существует флаг CLONE_KERNEL, который объединяет в себе флаги CLONE_FS, CLONE_FILES и CLONE_SIGHAND, так как большинство потоков простран- ства ядра должны указывать эти флаги в параметре flags. Чаще всего поток пространства ядра продолжает выполнять свою функцию вечно (или, по крайней мере, до перегрузки системы, но когда она произойдет в случае ОС Linux- неизвестно). Функция потока обычно содержит замкнутый цикл, в котором поток пространства ядра по необходимости возобновляет выполнение, исполняет свои обязанности и снова переходит в приостановленное состояние. В следующих главах более детально будут рассмотрены конкретные примеры по- токов пространства ядра. Завершение процесса Как это ни грустно, но любой процесс в конечном итоге должен завершиться. Когда процесс завершается, ядро должно освободить ресурсы, занятые процессом, и оповестить процесс, который является родительским для завершившегося, о том, что его порожденный процесс, к сожалению, "умер". Обычно уничтожение процесса происходит тогда, когда процесс вызывает си- стемный вызов e x i t () явно или неявно при выходе из главной функции программы (компилятор языка С помещает вызов функции e x i t () после возврата из функции main ()). Процесс также может быть завершен непроизвольно. Это происходит, ког- да процесс получает сигнал или возникает исключительная ситуация, которую про- Управление процессами 59 цесс не может обработать или проигнорировать. Независимо от того, каким обра- зом процесс завершается, основную массу работы выполняет функция doexec (), а именно указанные далее операции. • Устанавливается флаг PF_EXITING в поле flags структуры task s t r u c t . • Вызывается функция del_timer_sync (), чтобы удалить все таймеры ядра. После выхода из этой функции гарантируется, что нет никаких ожидающих таймеров и никакой обработчик таймера не выполняется. • Если включена возможность учета системных ресурсов, занятых процессами (BSD process accounting), то вызывается функция acct_process () для записи информации об учете ресурсов, которые использовались процессом. • Вызывается функция __exit_mm() для освобождения структуры mm_struct, занятой процессом. Если эта структура не используется больше ни одним про- цессом (другими словами, не является разделяемой), то она освобождается со- всем. • Вызывается функция exit_sem (). Если процесс находится в очереди ожида- ния на освобождение семафора подсистемы IPC, то в этой функции процесс удаляется из этой очереди. • Вызываются функции __exit_files (), __exit_fs () , exit_namespace () и e x i t _ s i g n a l s () для уменьшения счетчика ссылок на объекты, которые от- вечают файловым дескрипторам, данным по файловой системе, пространству имен и обработчикам сигналов соответственно. Если счетчик ссылок какого- либо объекта достигает значения, равного нулю, то соответствующий объект больше не используется никаким процессом и удаляется. • Устанавливается код завершения задания, который хранится в поле e x i t c o d e структуры task s t r u c t . Значение этого кода передается как аргумент функ- ции exit () или задается тем механизмом ядра, из-за которого процесс завер- шается. • Вызывается функция e x i t n o t i f у (), которая отправляет сигналы родитель- скому процессу завершающегося задания и назначает новый родительский про- цесс (reparent) для всех порожденных завершающимся заданием процессов, этим процессом становится или какой-либо один поток из группы потоков за- вершающегося процесса, или процесс i n i t . Состояние завершающегося про- цесса устанавливается в значение TASK_ZOMBIE. • Вызывается функция schedule () для переключения на новый процесс (см. гла- ву 4, "Планирование выполнения процессов"). Поскольку процесс в состоянии TASK_ZOMBIE никогда не планируется на выполнение, этот код является по- следним, который выполняется завершающимся процессом. Исходный код функции do_exit () описан в файле kernel/exit.с. К этому моменту освобождены все объекты, занятые задачей (если они использу- ются только этой задачей). Задача больше не может выполняться (действительно, у нее больше нет адресного пространства, в котором она может выполняться), а кро- ме того, состояние задачи — TASK_ZOMBIE. Единственные области памяти, которые теперь занимает процесс, — это стек режима ядра и слябовый объект, соответствен- но содержащие структуры thread_inf о и task_struct. |