4. Передача управления

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

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

Типы процессов

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

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

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

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

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

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

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

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

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

1. Процесс пользователя имеет БДП (блок данных процесса) для хранения локальных данных.

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

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

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

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

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

Процессы могут находиться в различных состояниях, обусловливаемых использованием системных ресурсов. Большинству систем присущи следующие состояния:

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

2. Готовность. Любой процесс, стоящий в очереди-на-выполнение, т. е. готовый к выполнению.

3. Выполнение. Любой момент времени, когда процесс имеет контроль над центральным процессором, который был передан ему программами планировщика-диспетчера.

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

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

Эффективность операционной системы может быть неявно измерена или определена в результате наблюдения распределения процессов по состояниям. Система называется ограниченной по вводу-выводу, если большое число процессов пребывает в ожидании доступа к файлу или устройству либо ожидает завершения операции ввода-вывода. Система называется ограниченной по быстродействию, если большая часть процессов находится в очереди на выполнение, а меньшая часть – в очереди к устройствам ввода-вывода. Имеющиеся в операционной системе программы могут производить избирательный вывод состояний процессов, обеспечивая, таким образом, «снимок» операций внутри системы.

Состояние ожидания

Рис. 45. Схема изменений состояния процесса (задачи).

Проблемы управления процессами

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

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

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

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

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

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

Сравнение планирования и диспетчеризации

В большинстве систем не делается различий между планированием и диспетчеризацией, и обе эти операции обычно объединяются в один программный модуль. Однако в системах реального времени необходимо различать эти две функции. Планирование – это организация процессов в некоторую последовательность согласно определенной стратегии. ПЛАНИРОВЩИК– это программа, ответственная за постановку npoцессов в очередь на выполнение, и управляющая структурой этой очереди. ДИСПЕТЧЕР – это программа, которая выбирает процессы из очереди-на-выполнение, переводит их в активное состояние и передает им контроль над центральным процессором.

Структура планировщика-диспетчера

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

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

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

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

ПЛАНИРОВЩИК выбирает процесс

ВОЗОБНОВИТЬ передает контроль процессору ОС

ВЫХОД-ИЗ-ОС передает контроль процессору пользователя

Для возобновления активности процесса необходимы различные модули, так как ОС должна восстановить работу защитных механизмов аппаратного управления памятью. Процесс пользователя выполняется в специально отведенном адресном пространстве – пространстве пользователя. Передача управления через физическую область памяти требует выполнения инструкции «переход в пространство пользователя». Планировщик. ПЛАНИРОВЩИК выбирает следующий, готовый к исполнению процесс. Следующим процессом может быть либо отложенный процесс, переведенный прерыванием в состояние ожидания, либо процесс, выбранный из очереди на выполнение. Планировщик проверяет наличие отложенного процесса и, найдя один, выбирает его в качестве следующего выполняемого процесса. Если отложенного процесса не находится, то следующий процесс выбирается в соответствии с алгоритмом:

Рис. 46 Структура блока сообщения нового процесса.

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

С приоритетом. В этом случае, если очередь на выполнение пуста, выполняется холостой процесс с низшим приоритетом. В тот момент, когда появляется процесс с более высоким приоритетом, он подменяет холостой процесс. При возникновении прерывания выполнение процесса откладывается. В программах, приводимых ниже, предполагается, что мы всегда будем стараться возобновить работу процесса, последнего по времени из выполнявшихся и приостановленных. Адрес блока управления этого процесса находится в области ОТЛОЖЕННЫХ-ПРОЦЕССОВ. Заметим, что ОТ-ЛОЖЕННЫЙ-ПРОЦЕСС имеет значение нуля после выдачи запроса на системное обслуживание. Альтернативный подход предполагает повторную обработку планировщиком отложенного процесса. Для обработки центральным процессором выбирается следующий процесс из очереди на выполнение. Данный алгоритм не предполагает обязательного обслуживания отложенного процесса первым.

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

Рис. 47 Возобновление активности системного процесса (процесса пользователя).

Интересная ситуация возникает при отсутствии для операционной системы полезной работы. В системе без приоритетов Планировщик зацикливается до тех пор, пока процесс путем прерывания не делается «готовым» к выполнению. В системе с приоритетами контроль передается ХОЛОСТОМУ-ПРОЦЕССУ. Холостой процесс выполняет по бесконечному циклу заданную последовательность инструкций. Холостой процесс имеет самый низкий приоритет. Как только какой-нибудь процесс с более высоким приоритетом станет «готовым», он будет выбран на обработку. Холостой процесс используется во многих системах для контроля за их использованием.

Передача управления системному процессу. Для передачи управления системному процессу после завершения обслуживания запроса к системе необходимо выполнить две процедуры. Эти процедуры обусловлены структурой блока управления памятью. Программа ВОЗОБНОВИТЬ, возвращает управление системному процессу. У процесса, имеющего блок данных, события в блоке модифицируются в соответствии с совершенными действиями. Из стека процесса извлекается адрес возврата и по нему происходит передача управления. Отметим, что для этого возобновления достаточно обойтись вызовом подпрограммы, так как все системные процессы (включая менеджер файлов) имеют нулевую карту памяти.

Модуль 1(без приоритета)

PROCEDURE планировщик

IF отложенный-процесс "1 =0 THEN

отложенный-процесс проц CLEAR отложенный процесс возобновить ( ) ENDIF

выбрать-из-очереди(очереди-на-выполнение) проц IF проц=0 THEN

GOTO планировщик ENDIF

возобновить( ) ENDPROC

Модуль 2 (с приоритетом)

PROCEDURE планировщик IF отложенный процесс THEN

отложенный-процесс -> проц CLEAR отложенный-процесс возобновить( )

ENDIF

IF счетчик-готовых-к-вып-процессов = О THEN

address(адрес-холостого-проц) ->-проц возобновить ( ) ENDIF

удалить-из-очереди(очереди-на-выполнение) -*■ проц возобновить( ) ENDPROC

Модуль 3

PROCEDURE возобновить IF буд[проц] "1 =0 THEN

выбрать-страницу-буд модиф-события ( ) ENDIF

выбрать адрес возврата из стека процесса

CALL (адрес-возврата) ENDPROC

Передача управления процессу пользователя. Программа ВЫХОД-ИЗ-ОС передает процессу пользователя управление от операционной системы. Система должна восстановить условия, в которых процесс находился непосредственно перед обращением к операционной системе. Во-первых, система должна удалить все системные оверлейные сегменты, которые были загружены для обслуживания системного запроса. Во-вторых, из стека пользователя должны быть удалены аргументы обращения к системной службе. Если процесс имеет блок данных, то БДП должен быть переадресован в область пользователя. Наконец, должны быть восстановлены регистры и слово состояния. Состояние карты устанавливается в режим пользователя и выполняется инструкция «перейти-в-пространство-пользовате-ля». Эта последовательность операций передачи управления процессу пользователя зависит от структуры аппаратной части блока управления памятью и архитектуры операционной системы.

Модуль 3

PROCEDURE выход-из-ОС

вершина-стека (yen)_-*- код-функции оверлейн-таблица-системы[код-функции] -*■ адрес-оверлея IF адрес-оверлея 1=0 THEN

система (удалить-оверлей, адрес-оверлея)

ENDIF

ENTRY выход-из-ОС-2: ■ . '

вершина-стека (yen) —*- код-функции снстемная-таблица[код-функции+1] -*• число-параметров увеличить-усп-на-число-параметров IF усп> = базовый-адрес-стека THEN

address (yen) -*■ yen

address (пространство-стека) -+■ вершина-усп система (удалить-по-ошибке, переполнение-стека) ENDIF

выбрать из стека процесса адр-возврата-пользователя выбрать из стека процесса иомер-карты-пользователя IF номер-карты[проц] "1=0 THEN

выбрать-страницу-буд(номер-карты[проц]) переадресовать буд в пространство пользователя ENDIF

восстановить регистры и слово состояния процессора перевести карту памяти в режим пользователя выполнить инструкцию «перейти в пространство пользователя» ENDPROC

Алгоритмы планирования

Циклическое планирование. Циклический алгоритм является одним из наиболее ранних простых алгоритмов планирования. Согласно этому алгоритму, процесс, использовавший выделенный ему квант времени, помещается в конец очереди на выполнение. Процессы выбираются из очереди, начиная с первого. Приоритет процесса определяется его линейным положением в очереди. Недостаток такого алгоритма заключается в том, что процесс может занимать центральный процессор длительное время. Фактически процесс занимает ЦП в ущерб другим процессам. Для снятия этой проблемы каждому процессу отводится временной интервал (квант). Квант детерминирует то непрерывное время, в течение которого процесс может занимать ЦП после получения к нему очередного доступа. По истечении этого интервала работа процесса прерывается операционной системой. Такой метод квантования известен как циклический алгоритм, так как время равномерно распределяется между активными процессами (t = время доступа/число активных процессов). Он используется в различных вариантах большинством систем с разделением времени, работающих с интерактивными терминалами.

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

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

«Политическое планирование». Процесс пользователя получает определенное число услуг, зависящее от «класса», к которому он принадлежит. Приоритет процесса изменяется как функция разницы между услугой, обещанной пользователю, и услугой, фактически полученной. Реализация такой функции может быть статической и динамической. Статическая политическая функция представлена операционной системой IBM/360, которая распределяет пользователей по классам, исходя из их запросов на ресурсы. Динамическая политическая функция представлена алгоритмом планирования в операционной системе серии UNIVAC 1100. Процесс пользователя перемещается по приоритетным классам в зависимости от израсходованного им времени и использования приоритетных ресурсов.

Адаптивно-рефлективное планирование. Адаптивное планирование предполагает контроль над реальным использованием памяти. При таком подходе к началу планирования для каждого процесса устанавливаются ограничения на использование памяти и виртуального вРемени центрального процессора. Ограничения на память определяются оценкой текущего объема памяти, необходимого процессу, и оценкой направления изменения этого объема," получаемого анализом работы процесса в течение предыдущего кванта времени. Процессу выделяется очередной временной интервал только при наличии в памяти достаточного количества свободных страниц, удовлетворяющего полученной оценке. Система приспосабливается к рабочей области каждого про. цесса в течение всего его выполнения. Виртуальная временная граница ЦП устанавливается для процесса непосредственно перед его выполнением. Ее величина обратно пропорциональна максимальному объему памяти, необходимому процессу. Процессам с большими рабочими областями (квотами) отводится меньшее время доступа к ЦП с целью увеличения эффективного времени их работы. Идея подхода – ориентировать систему на процессы с минимальной рабочей областью. Такие процессы имеют большее отношение эффективного времени выполнения к общему, так как их виртуальный квант времени длиннее, а количество требуемых страниц ниже среднего числа. Это приводит к возникновению иерархии скоростей выполнения процессов.

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

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

Сравнение статических и динамических приоритетов.

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

1. Приоритет совпадает с приоритетом программы, к которой принадлежит данный процесс.

2. Приоритет вычисляется, исходя из предполагаемых запросов на ресурсы (памяти, устройств ввода-вывода, циклов ЦП).

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

4. Приоритет основывается на типе процесса независимо от использования им ресурсов.

Статическая установка приоритетов может привести к тому, что взаимодействие определенного числа процессов резко снижает эффективность системы. Решением этой проблемы является динамическое присвоение процессу приоритетов в течение всего времени его работы. Это решение имеет два аспекта: при создании процесса его приоритет устанавливается в соответствии с текущим состоянием системы; при каждой постановке процесса в очередь или окончании отведенного кванта времени ЦП приоритет корректируется.

Большое число алгоритмов, основывающихся на приведенной стратегии, было внедрено в различные операционные системы, работающие в реальном масштабе времени. Интересный алгоритм, учитывающий несколько факторов использования ресурсов, применен в операционной системе серии UNIVAC1100. Обзор литературы по ОС для мини-ЭВМ даст возможность ознакомиться с иными существующими алгоритмами.

Базы данных для управления процессами

Процесс планирования базируется на двух структурах данных: блоке управления процессом и очереди на выполнение.

Процесс может быть рассмотрен как организационное средство, поставляющее информацию о вычислениях. Каждый процесс состоит из последовательности инструкций и контрольных параметров. Информация, описывающая процесс, содержится в базе данных и называется Блоком Управления Процессом БУП. С процессом может быть связана локальная область памяти для хранения данных, именуемая Блоком Данных Процесса (БДП). В БДП находятся стек пользователя и векторы событий. Часть БДП доступна процессу пользователя для хранения временных данных. Остальная часть доступна исключительно операционной системе.

Очередью на выполнение называется список процессов, составленный в том порядке, в каком они поступают на обработку. Диспетчер выбирает БУП из начала очереди и передает ему управление центральным процессором.

Эти базы данных отличаются по сложности и содержанию. Различные версии операционных систем содержат в БУП различную информацию. В некоторых системах информация в БУП и БДП объединяется в один управляющий блок.

Базовая область блока управления процессом. Каждый БУП содержит базовую область, которая неизменна для всех процессов и всех связей процесса с другими БУП в цепи. В течение существования процесса его БУП постоянно находится в системной очереди. Идентичность этой очереди устанавливается в СИСТЕМНОИ-ОЧЕРЕДИ.

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

Процесс может иметь блок данных, использующийся для •хранения локальных данных процесса (см. ниже). Адрес БДП хранится в БУП, так как БДП может переадресовываться из области пользователя в системную и обратно. Для БДП отводится реальная страница памяти, поэтому его адрес – это адрес Реальной страницы памяти. У некоторых процессов блоки отсутствуют, и они не могут обращаться к системным службам. Однако процессу необходима область для хранения локальных Данных. Эта область устанавливается в БДП в поле ДАННЫЕ-ПРОЦЕССА.

Большинство процессов имеет процесс-прародитель, который создал их для своих специфических нужд. Исключение составляют системные процессы, созданные на этапе инициализаций. Некоторые системные процессы (например, созданные для операций ввода-вывода) существуют очень короткое время. Они самоуничтожаются после выполнения своих функций. Процессы информируют своего прародителя об успехе или неудаче в своих действиях, передавая код события. Идентификатор порождающего процесса и код события, сообщающий о статусе завершения, устанавливаются в полях ПРАРОДИТЕЛЬ-ИД и КОД-СОБЫТИЯ. Две другие точки входа – СТАТУС-СОБЫТИЯ и. ДАННЫЕ-СОБЫТИЯ –служат для временного хранения статуса и значения события.

Управление приоритетами задач

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

Очевидно, что ни одной операционной системе не потребуется столько приоритетных классов. Фактически большинство систем ограничивает величину приоритета числами в диапазонах 0—128, 0—256, которые могут быть записаны в один байт. Такой подход может быть дополнен схемой, снижающей затраты системы на постановку блока управления в очередь на выполнение.

Обобщенная приоритетная схема использует список со 128 (256) полями, содержащий указатели на подсписки блоков управления. Внутри каждого приоритетного класса процесс обслуживается по циклическому алгоритму. Постановка в очередь сравнительно проста: система выбирает необходимую очередь, исходя из приоритета процесса, а затем вызывает программу ВСТАТЬ-В-ОЧЕРЕДЬ с указанием адреса начала очереди. Аналогичным образом при выборке блока управления система локализует первый непустой подсписок и извлекает оттуда первый блок управления. Программы, реализующие эту обобщенную приоритетную схему, представлены ниже.

1. ВСТАТЬ-В- ПРИОРИТЕТНУЮ- ОЧЕРЕДЬ (ОЧЕРЕДЬ НА-ВЫП, АДРЕС-БУП) 1

ПРИОРИТЕТ[АДРЕС-БУП] ПРИОРИТЕТ-БУП |

IF ПРИОРИТЕТ-БУП<0 OR ПРИОРИТЕТ-БУП>255 Ц

THEN

RETURN ПРИОРИТЕТ-ОШИБКА END IF

ОЧЕРЕДЬ-НАЧАЛО[ОЧЕРЕДЬ-НА-ВЫП] НАЧАЛО-ОЧЕР НАЧАЛО-ОЧЕР[ПРИОРИТЕТ-БУП] ТЕКУЩИЙ-БУП ' АДРЕС-БУП -> НАЧАЛО-ОЧЕР[ПРИОРИТЕТ-БУП] ОЧЕРЕДЬ-СЧЕТЧИК[ОЧЕРЕДЬ-НА-ВЫП] -> СЧЕТЧИК-ОЧЕРЕДИ INCREMENT ОЧЕРЕДЬ-СЧЕТЧИК[ПРИОРИТЕТ-БУП]

2. УДАЛИТЬ- ИЗ- ПРИОРИТЕТНОЙ -ОЧЕРЕДИ (ОЧЕ-РЕДЬ-НА-ВЫП)—и АДРЕС-БУП

ОЧЕРЕДЬ-СЧЕТЧИК[ОЧЕРЕДЬ-НА-ВЫП] ОЧЕРЕДЬ-СЧЕТЧИК §

FOR ИНДЕКС-ПРИОРИТЕТА FROM О ТО 255 I

DO I

IF СЧЕТЧИКЮЧЕРЕДЩИНДЕКС-ПРИОРИТЕТА] 1 =0 I

THEN 1 EXITDO

ENDIF ENDDO

ОЧЕРЕДЬ-НАЧАЛО[ОЧЕРЕДЬ-НА-ВЫП] НАЧАЛО-ОЧЕР НАЧАЛО-ОЧЕР[ИНДЕКС-ПРИОРИТЕТА] АДРЕС-БУП СЛЕДУЮЩИЙ-БУ[АДРЕС-БУП] ->- НАЧАЛО-ОЧЕР[ИНДЕКС-ПРИОРИТЕТА1

DECREMENT СЧЕТЧИК-ОЧЕРЕДИ[ИНДЕКС-ПРИОРИТЕТА]

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

Задание для выполнения работы

Задача 1.

Инициализация процесса пользователя. Действия, необходимые для инициализации блока управления процессом, показаны в модуле 1. На первом шаге БУП помещается в ОЧЕРЕДЬ-ВСЕХ-ПРОЦЕССОВ. Эта очередь содержит список всех процессов в системе. Единый список всех процессов необходим, так как процесс может передвигаться по различным очередям и ошибка в системе может привести к его исчезновению. СИСТЕМНЫИ-ФЛАГ-ПРОЦЕССА в приоритетном слове устанавливается в нуль, указывая отсутствие активных событий. Также устанавливается в нуль текущий номер карты процесса. Область стека, зарезервированная для системных программ, устанавливается в БУП, а адрес возврата записывается в стек.

Затем БДП инициализируется данными, относящимися к порождающему процессу. В БДП помещаются код события и идентификатор процесса-прародителя. Если имеется блок данных, то он перезаписывается из пространства процесса-прародителя в БДП. Наконец, инициализируется область стека пользователя записью туда стартового адреса и номера карты памяти, содержащей коды программы.

Модуль 1

PROCEDURE иниц-процесс-польз (адрес-буп, стартовый-адрес, приоритет, адрес, объем, карта, код-событня, карта-программы, объем-данных, бл

данных, карта-даин"

встать-в-очередь (очередь-всех-процессов, адрес-буп) приоритет -*■ приоритет[адрес-буп]

SET системный-флаг-процесса ТО приоритет[адрес-буп] j CLEAR активные-события[адрес-буп]

CLEAR завершенные-события[адрес-буп] CLEAR цепь-событий[адрес-буп]

CLEAR номер-карты[адрес-буп] /

address (оспл[адрес-буп]) успр[адрес-буп]

address (выход-из-ОС) -*■ оспл[адрес-буп]

проц -*■ идентификатор-процесса[адрес-буп]

код-события код-события[адрес-буп]

объем-данных ->- количество-блоков-данных[адрес-буп]

скопировать-из-простр-польз (карта-данных,

блок-данных, данные-процесса[адрес-буп], объем-даиных) address (yen — 3) -*■ временн-ук-стека

address (пространство-стека) -»- граница-усп[временн-ук-стека]

address (пауза) -*■ функция[временн-ук-стека] address (стартовый-адрес) ->- возврат [временн-ук-стека]

карта-программы -*■ карта[времен-ук-стека] ENDPROC

Задача 2.

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

Решение.

Операция УНИЧТОЖИТЬ позволяет процессу удалить себя самому. Логика удаления приведена в модуле 2. На первом этапе процесс переводится в состояние ожидания и ждет завершения всех внешних системных запросов. Затем процесс удаляется из ОЧЕРЕДИ-ВСЕХ-ПРО-ЦЕССОВ и счетчик процессов пользователя уменьшается на единицу. Если процесс является последним пользовательским процессом в системе, то система, обращаясь к программе ВОЗВРАТ, переводится в холостое состояние. В противном случае ресурсы на КВВ, БУП и БДП освобождаются и возвращаются в соответствующие пулы. Формат запроса имеет вид

Модуль 2

PROCEDURE уничтожить запрос (ждать-рес)

выбрать-из-очереди(очередь-всех-процессов) DECREMENT счетчики-процессов-пользователя IF ириоритет[проц]<0 THEN

IF счетчик-процессов-пользователя=О THEN

система (возврат, 0, адрес-буп) ENDIF ' ENDIF

освободить(карта-вв-выв-рес, бдп-карта-вв-выв[проц]) освободить (бдп-рес, бдп[проц]) освободить (бдп-рес, проц) планировщик ( ) ENDPROC

В многопроцесных системах процесс-прародитель обычно создает ряд процессов, работающих параллельно. После окончания работы каждый из таких процессов может либо удалить сам себя командой УНИЧТОЖИТЬ, либо быть удаленным процессом-прародителем. Прародитель может уничтожить созданный им процесс по различным причинам. Команда УДАЛИТЬ позволяет одному процессу уничтожить другой. Формат запроса имеет вид

СИСТЕМА (УДАЛИТЬ, КОД-ОБЫТИЯ, ИДЕНТИФИКД'. ТОР-ПРОЦЕССА),

где КОД-СОБЫТИЯ используется для информирования главного процесса о том, когда был удален второстепенный процесс; ИДЕНТИФИКАТОР-ПРОЦЕССА – идентификатор удаляемого процесса.

Если идентификатор процесса был указан неверно, то статус завершения возвращает код ошибки.