Архитектура UNIX. Процессы

Презентация 3-01: ядро UNIX

В прошлой лекции была рассмотрена архитектура операционной системы UNIX и её ядра. Было сказано о том, что эта операционная система базируется на двух «китах»: файлах и процессах. В этой лекции речь пойдет о процессах: что это такое и как они взаимодействуют в рамках UNIX-системы.

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

Управление памятью

Презентация 3-02: управление памятью

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

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

В современных реализациях UNIX для большинства аппаратных архитектур используется страничная организация виртуальной памяти. В этом случае всё адресное пространство процесса разбивается на участки одинакового размера (страницы), аналогичным образом разбивается вся физическая память. Каждая станица адресного пространства процесса может отображаться на какую-то страницу физической памяти. Это обеспечивается специальной таблицей преобразования адресов, которую операционная система поддерживает в адекватном состоянии. Таким образом, физическая память разделяется между множеством процессов, причём каждый из процессов имеет доступ только к «своим» страницам, что гарантируется операционной системой и аппаратными возможностями процессора.

В 32-разрядной архитектуре объём адресного пространства процесса равен 4 гигабайтам. Так как число процессов в системе потенциально не ограничено, очевидно, что суммарный размер адресного пространства, необходимого всем процессам, вполне может превысить размеры физической памяти. Конечно, большая часть программ оперирует довольно небольшим объёмом памяти. Однако страничное преобразование позволяет решить проблему недостатка физической памяти: неиспользуемые страницы могут копироваться из физической памяти на диск в специальную область подкачки и храниться там до момента, когда они вновь потребуются для исполнения процесса.

Ещё один мощный механизм, возможный благодаря страничному преобразованию, — это файлы, проецируемые в память. Процесс может «присоединить» файл к своему виртуальному адресному пространству. Это означает, что при обращении к файлу или изменении данных в нем операционная система будет автоматически выполнять отображение содержимого файла в страницы памяти процесса и обратно. Фактически операционная система здесь использует тот же механизм, что и при работе с областью подкачки, когда данные перемещаются с внешнего носителя в память при обращении к соответствующему адресу виртуальной памяти. Отображаемые в память файлы используются в тех случаях, когда необходимо с минимальными временными затратами многократно модифицировать содержимое файла, например, в базах данных или редакторах.

На рисунке Рисунок 1.38, «Размещение страниц виртуальной памяти» показаны возможные случаи размещения страниц виртуальной памяти — в физической памяти, в области подкачки, в файле.

Рисунок 1.38. Размещение страниц виртуальной памяти

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

Презентация 3-03: контекст процесса

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

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

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

Статическая часть контекста процесса системного уровня включает следующее:

Идентификатор процесса (PID)

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

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

Идентификатор родительского процесса (PPID)

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

Очевидно, что в такой схеме должен присутствовать один процесс с особым статусом: он должен быть порожден ядром операционной системы и будет являться родительским для всех остальных процессов в системе. В UNIX такой процесс имеет собственное имя — init. Подробнее об этом процессе сказано в разделе «Процесс init».

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

Каждый процесс в любой момент времени находится в одном из нескольких определенных состояний: инициализация, исполнение, приостановка, ожидание ввода-вывода, завершение и т. п. (см. Рисунок 1.39, «Состояния процесса в UNIX»).

Рисунок 1.39. Состояния процесса в UNIX

Большинство этих состояний совпадает с классическим набором состояний процессов в многозадачных операционных системах. Для операционной системы UNIX характерно особое состояние процесса — зомби. Процесс получает это состояние, если он завершился раньше, чем этого ожидал его родительский процесс. В UNIX перевод процессов в состояние зомби служит для корректного завершения группы процессов, освобождения ресурсов и т. п.

Идентификаторы пользователя

Идентификатор пользователя и группы, от имени которых исполняется процесс, используются операционной системой для определения границ доступа для процесса. Подробнее о правах доступа будет сказано в лекции «Введение в безопасность UNIX».

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

Число, используемое при планировании (см. «Планирование процессов») исполнения процесса в операционной системе. Традиционное решение операционной системы UNIX состоит в использовании динамически изменяющихся приоритетов. При образовании каждого процесса ему приписывается некоторый устанавливаемый системой статический приоритет, который в дальнейшем может быть изменен с помощью системного вызова nice. Реальным критерием планирования выступает динамический приоритет, статический приоритет составляет основу начального значения динамического приоритета процесса. Все процессы с динамическим приоритетом не ниже порогового участвуют в конкуренции за процессор.

Таблица дескрипторов открытых файлов

Список структур ядра, описывающий все файлы, открытые этим процессом для ввода-вывода.

Другая информация, связанная с процессом

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

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

Презентация 3-04: планирование процессов

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

Наиболее распространенным алгоритмом планирования в системах разделения времени является кольцевой режим (Round Robin). Основной смысл алгоритма состоит в том, что время процессора делится на кванты фиксированного размера, а процессы, готовые к выполнению, выстраиваются в кольцевую очередь (см. Рисунок 1.40, «Схема планирования с кольцевой очередью»). У этой очереди имеются два указателя — начала и конца. Когда процесс, выполняющийся на процессоре, исчерпывает свой квант процессорного времени, он снимается с процессора, ставится в конец очереди, а ресурсы процессора отдаются процессу, находящемуся в начале очереди. Если выполняющийся на процессоре процесс откладывается (например, по причине обмена с некоторым внешним устройством) до того, как он исчерпает свой квант, то после повторной активизации он становится в конец очереди (не смог доработать — не вина системы). Это прекрасная схема разделения времени в случае, когда все процессы одновременно помещаются в оперативной памяти.

Рисунок 1.40. Схема планирования с кольцевой очередью

Однако операционная система UNIX всегда была рассчитана на то, чтобы обслуживать больше процессов, чем можно одновременно разместить в основной памяти. Другими словами, часть процессов, потенциально готовых выполняться, размещалась во внешней памяти (куда образ памяти процесса попадал в результате откачки). Для оптимизации работы в этом случае требуется несколько более гибкая схема планирования при разделении ресурсов процессора. В результате было введено понятие приоритета (см. Рисунок 1.41, «Схема планирования с кольцевой очередью и приоритетами»). В операционной системе UNIX на основании значения приоритета процесса определяется, во-первых, возможность процесса пребывать в основной памяти и на равных конкурировать за процессор. Во-вторых, от значения приоритета процесса зависит размер временного кванта, который предоставляется процессу для работы на процессоре при достижении своей очереди. В-третьих, значение приоритета влияет на место процесса в общей очереди процессов.

Рисунок 1.41. Схема планирования с кольцевой очередью и приоритетами

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

Презентация 3-05: создание новых процессов

Механизм порождения новых процессов довольно существенно различается в разных операционных системах. Во всех операционных системах семейства UNIX новые процессы в системе не появляются «из ниоткуда», а ответвляются от уже существующих в системе процессов.

Когда возникает необходимость создания нового процесса (C), текущий процесс (P) выполняет системный вызов fork (см. рисунок Рисунок 1.42, «Создание нового процесса»). При этом создаётся новый процесс, представляющий собой копию исходного процесса и его контекста. Новый процесс отличается тем, что у него другой PID, а родителем для него является запустивший процесс (P). Далее дочерний процесс (C) с помощью системного вызова exec запускает вместо себя другую программу, заново проинициализировав свои код и данные.

Рисунок 1.42. Создание нового процесса

Существует также и обратная связь между дочерним процессом и родительским. Родительский процесс (P) может синхронизовать своё исполнение с завершением процесса (C) (ожидать завершения дочернего процесса) с помощью специального системного вызова wait.

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

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

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