Подсистема управления процессами

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

Вызовы, служащие для работы с процессами: fork (создает новый процесса), exec (выполняет процесс), exit (завершает исполнение процесса), wait (один из способов синхронизации), brk (управляет памятью, выделенной процессу), signal (обработчики исключений) и др.

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

Виртуальная память была изобретена в 1962 году, в Англии при создании суперкомпьютера Atlas. В большинстве современных компьютеров оперативная память не так велика, как используемое процессором адресное пространство. Размер ОЗУ типичного персонального компьютера варьируется от десятков до сотен мегабайт. При запуске программа загружается с какого-либо накопителя в оперативную память. Если же программа не помещается в ОЗУ, то те её части, которые в данный момент не выполняются, хранятся во вторичном запоминающем устройстве, чаще всего винчестере, и такая память называется виртуальной. Безусловно, перед выполнением необходимая часть программы должна быть перемещена в оперативную память. Данные функции выполняет ядро операционной системы (диспетчер виртуальной памяти, находящийся в микроядре). И для программы и для пользователя эти действия прозрачны. Естественно, на запросы к виртуальной памяти уходит гораздо большее время, нежели к ОЗУ.

Второй модуль - планировщик. Его задача не менее важна. UNIX - мультизадачная ОС, то есть одновременно может выполняться множество процессов. Мы, однако, знаем, что в фиксированный момент времени на одном процессоре может выполняться только одна команда. Именно поэтому нужен виртуальный рефери, который будет определять, какому процессу исполняться сейчас, а какому - через секунду. На практике же планировщик переключает контекст, то есть перед тем, как остановить исполнение какого-то процесса, он запоминает состояние регистров, памяти и т. д., а уже после этого запускает другой процесс в его собственном адресном пространстве. И еще один тонкий момент: каждый запущенный процесс "думает", что он единственный. Дополнительно существует механизм приоритетов. Очевидно, чем выше приоритет, тем быстрее начнет исполняться процесс. Процессы могут также обмениваться между собой информацией. В случае их синхронного взаимодействия синхронизацию осуществляет модуль взаимодействия (например, функция wait).

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

На архитектуре микроядра построены также FreeBSD и Mac OS X. Монолитные же ядра используются еще и в Linux. Они оптимизированы для более высокой производительности с минимальными контекстными переключениями. Такая архитектура упрощает поддержку кода ядра для разработчиков, но требует перекомпиляции ядра при добавлении новых устройств. Следует отметить, что описанные здесь различия являются "классическими", на практике монолитные ядра могут поддерживать модульность (что зачастую и происходит), а микроядра могут требовать перекомпиляции.

Ядро UNIX/Linux имеет два вида исключений, которые обычно называют "oops" и "panic". Почти в каждой операционной системе паника происходит в тех случаях, когда ядро обнаруживает серьезную неисправность. Если система каким-либо образом повредила сама себя, ей требуется остановиться немедленно, пока она не произведет необратимых критических изменений (типа уничтожения файловой системы). Везде, где только возможно, UNIX/Linux пытается детектировать проблему и справиться с ней без остановки всей системы. Например, многие ситуации типа "oops" приводят к завершению процесса, который нормально запустился, но потом зациклил систему. Бывают, однако, ситуации, когда все настолько плохо, что полная паника является наилучшим выходом. Считается, что пользователи стабильных версий ядра не должны встречать ни "паник", ни "oops". Но в реальном мире они иногда происходят.

Недавно найденный "TF-баг" является хорошим примером паники. Процессор пытается передать управление процессу, которого не существует. Это приводит к краху всей системы. В данном случае, у системы нет другой альтернативы, чем запаниковать.

Ядро, поставляемое с Red Hat Linux 7.3 (и некоторыми другими дистрибутивами), содержит баг в файловой системе ext3. Эта ошибка приводит к "oops", завершая время от времени некоторые процессы (также этот баг приводит к замедлению всей системы). Хотя данная ошибка уже исправлена (патч есть и в обновлении от Red Hat), этот случай познакомил многих пользователей с ошибками типа "oops".

Рис. 4. Фундаментальная архитектура операционной системы GNU/Linux

На верхнем уровне находится пользовательское пространство (пространство приложений). Здесь исполняются приложения пользователя. Под пользовательским пространством располагается пространство ядра. Здесь функционирует ядро Linux.

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

Ядро Linux можно, в свою очередь, разделить на три больших уровня:

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

2. Ниже интерфейса системных вызовов располагается код ядра, точнее говоря, архитектурно-независимый код ядра. Этот код является общим для всех процессорных архитектур, поддерживаемых Linux.

3. Еще ниже располагается архитектурно-зависимый код, образующий т.н. BSP (Board Support Package - пакет поддержки аппаратной платформы). Этот код зависит от процессора и платформы для конкретной архитектуры.

Методы интерфейса системных вызовов (SCI)

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