Материал: 6262

101

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

Подсистема управления процессами находится в ядре ОС. Основная ее функция —

обеспечение мультипрограммного режима работы ОС, что связано с:

•созданием процессов в системе и удаление их из системы, что, как было рассмотрено в теме 8, предполагает управление основной памятью ЭВМ;

•переключением процессов в режимы «Готовность», «Выполнение» и «Ожи-

дание».

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

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

Все системы должны обеспечить:

•Справедливость — предоставление каждому процессу справедливой доли процессорного времени.

•Принудительное применение политики - контроль за выполнением принятой политики;

•Баланс — поддержка занятости всей системы.

Системам пакетной обработки данных необходима:

•Пропускная способность — максимальное количество задач в час.

•Оборотное время — минимизация времени, затрачиваемого на ожидание обслуживания и обработку задачи.

•Использование процессора — поддержка постоянной занятости процессора.

Интерактивным системам важно:

•Время отклика — быстрая реакция на запросы.

•Соразмерность — выполнение пожеланий пользователя.

Системам реального времени требуется:

•Окончание работы к сроку — предотвращение потери данных.

•Предстказуемость - предотвращение деградации качества в мультимедийных системах.

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

Планирование в системах пакетной обработки данных:

•Первым пришел — первым обслужен. Является наиболее простым алгоримом

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

102

•Кратчайшая задача — первая. Позволяет очень быстро выполнять маленькие задачи, но требует знания времени их выполнения.

•Наименьшее оставшееся время выполнения. Если имеется задача, время вы-

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

•Трехуровневое планирование. Здесь имеется впускной планировщик, который

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

Планирование в системах интерактивной обработки данных также обладает большим разнообразием. Наиболее известны два алгоритма:

•Циклическое планирование, когда каждому запускаемому процессу выделя-

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

•Приоритетное планирование, когда каждому запускаемому процессу присва-

ивается приоритет и управление передается готовому к работе процессу, с наивысшим приоритетом.

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

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

•Мягкие системы реального времени, для которых нарушение сроков выполнения задач - нежелательно, но допустимо.

Замечание

Как правило, все ОС используют разные и сложные алгоритмы планирования, подробности которых мы изучать не будем, но широкоизвестные ОС, такие как MS Windows или Linux Desktop, относятся к системам интерактивной обработки данных.

3.2 Синхронизация процессов

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

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

•родительский процесс отслеживает завершение дочернего процесса, тем са-

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

103

Замечание

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

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

Модель сигнала, по многим причинам, является самой сложной «конструкцией» ОС:

сигналы должны доставляться всем запущенным процессам ОС, многие из которых находятся в состояниях «Готовность» или «Ожидание»;

реакция процесса на сигнал должна быть своевременной, иначе возможна ошибочная обработка его процессом;

реализация «механизма» сигналов должна быть эффективной, покольку в среде ОС возникает и обрабатывается множество сигналов;

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

Замечание

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

•знания особенностей их использования, в контексте работы ядра ОС;

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

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

Дальнейшее развитие средств синхронизации процессов связано с понятем канала, которое было изучено в теме 7, как реализация части функций «Подсистемы ввода-вывода». Очевидно, что реализация этих каналов тесно связана и с «Подсистемой управления процессами», подчеркивая сложность реализации функций ядра ОС.

Общий «механизм» синхронизации процессов с помощью каналов основан на

функциях блокирования операций чтения из канала и записи в канал:

•неименованные или полудуплексные каналы UNIX обеспечивают синхронизацию только родственных процессов;

104

• именованные каналы, в которых задействована файловая система ОС, обеспе-

чивает синхронизацию всех процессов, даже еще не запущенных в системе. Недостатки такой синхронизации:

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

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

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

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

Замечание

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

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

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

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

3.3 Стандарты POSIX

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

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

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

группы процессов ледний процесс (по причине завершения или смены группы).