Файл: А. В. Гордеев А. Ю. Молчанов системное программное обеспечение электронный вариант книги издательства Питер СанктПетербург Челябинск юургу каф. Автоматика и управление 2002 2 Предисловие Настоящий учебник.pdf

20
После окончания работы с ресурсом задача опять с помощью специального вызова супервизора (посредством соответствующей директивы) сообщает операци- онной системе об отказе от ресурса, или операционная система забирает ресурс са- ма, если управление возвращается супервизору после выполнения какой-либо сис- темной функции. Супервизор операционной системы, получив управление по это- му обращению, освобождает ресурс и проверяет, имеется ли очередь к освободив- шемуся ресурсу. Если очередь есть – в зависимости от принятой дисциплины об-
служивания (правила обслуживания)
1
и приоритетов заявок он выводит из состоя- ния ожидания задачу, ждущую ресурс, и переводит её в состояние готовности к выполнению. После этого управление либо передаётся данной задаче, либо воз- вращается той, которая только что освободила ресурс.
При выдаче запроса на ресурс задача может указать, хочет ли она владеть ре- сурсом монопольно или допускает совместное использование с другими задачами.
Например, с файлом можно работать монопольно, а можно и совместно с другими задачами.
Если в системе имеется некоторая совокупность ресурсов, то управлять их ис- пользованием можно на основе определенной стратегии. Стратегия подразумевает четкую формулировку целей, следуя которым можно добиться эффективного рас- пределения ресурсов.
При организации управления ресурсами всегда требуется принять решение о том, что в данной ситуации выгоднее: быстро обслуживать отдельные наиболее важные запросы, предоставлять всем процессам равные возможности либо обслу- живать максимально возможное количество процессов и наиболее полно использо- вать ресурсы [37].
Диаграмма состояний процесса
Необходимо различать системные управляющие процессы, представляющие работу супервизора операционной системы и занимающиеся распределением и управлением ресурсов, от всех других процессов: системных обрабатывающих процессов, которые не входят в ядро операционной системы, и процессов пользо-
1
Например, дисциплина «последний пришедший обслуживается первым» определяет обслуживание в порядке, об- ратном очерёдности поступления соответствующих запросов

21
вателя. Для системных управляющих процессов в большинстве операционных сис- тем ресурсы распределяются изначально и однозначно. Эти процессы управляют ресурсами системы, за использование которых существует конкуренция между всеми остальными процессами. Поэтому исполнение системных управляющих программ не принято называть процессами. Термин задача можно употреблять
только по отношению к процессам пользователей и к системным обрабатываю-
щим процессам. Однако это справедливо не для всех ОС. Например, в так называе- мых «микроядерных» (см. главу 5 «Архитектура операционных систем и интер- фейсы прикладного программирования») ОС (в качестве примера можно привести
ОС реального времени QNX фирмы Quantum Software systems) большинство управ- ляющих программных модулей самой ОС и даже драйверы имеют статус высо- коприоритетных процессов, для выполнения которых необходимо выделить со- ответствующие ресурсы. Аналогично и в UNIX-системах выполнение системных программных модулей тоже имеет статус системных процессов, которые получают ресурсы для своего исполнения.
Если обобщать и рассматривать не только обычные ОС общего назначения, но и, например, ОС реального времени, то можно сказать, что процесс может нахо- диться в активном и пассивном (не активном) состоянии. В активном состоянии
процесс может участвовать в конкуренции за использование ресурсов вычисли- тельной системы, а в пассивном – он только известен системе, но в конкуренции не участвует (хотя его существование в системе и сопряжено с предоставлением ему оперативной и/или внешней памяти). В свою очередь, активный процесс может быть в одном из следующих состояний:
♦ выполнения – все затребованные процессом ресурсы выделены. В этом со- стоянии в каждый момент времени может находиться только один процесс, если речь идёт об однопроцессорной вычислительной системе;
♦ готовности к выполнению – ресурсы могут быть предоставлены, тогда про- цесс перейдёт в состояние выполнения;
♦ блокирования или ожидания – затребованные ресурсы не могут быть предо- ставлены, или не завершена операция ввода/вывода.

22
В большинстве операционных систем последнее состояние, в свою очередь,
подразделяется на множество состояний ожидания, соответствующих определен- ному виду ресурса, из-за отсутствия которого процесс переходит в заблокирован- ное состояние.
В обычных ОС, как правило, процесс появляется при запуске какой-нибудь программы. ОС организует (порождает или выделяет) для нового процесса соответ- ствующий дескриптор (см. об этом дальше) процесса, и процесс (задача) начинает развиваться (выполняться). Поэтому пассивного состояния не существует. В ОС
реального времени (ОСРВ) ситуация иная. Обычно при проектировании системы реального времени уже заранее бывает известен состав программ (задач), которые должны будут выполняться. Известны и многие их параметры, которые необходи- мо учитывать при распределении ресурсов (например, объём памяти, приоритет,
средняя длительность выполнения, открываемые файлы, используемые устройства и т. п.). Поэтому для них заранее заводят дескрипторы задач с тем, чтобы впослед- ствии не тратить драгоценное время на организацию дескриптора и поиск для него необходимых ресурсов. Таким образом, в ОСРВ многие процессы (задачи) могут находиться в состоянии бездействия, что мы и отобразили на рис. 1.3, отделив это состояние от остальных состояний пунктиром.
За время своего существования процесс может неоднократно совершать пере- ходы из одного состояния в другое. Это обусловлено обращениями, к операцион- ной системе с запросами ресурсов и выполнения системных функций, которые предоставляет операционная система, взаимодействием с другими процессами, по- явлением сигналов прерывания от таймера, каналов и устройств ввода/вывода, а также других устройств. Возможные переходы процесса из одного состояния в другое отображены в виде графа состояний на рис. 1.3. Рассмотрим эти переходы из одного состояния в другое более подробно.
Процесс из состояния бездействия может перейти в состояние готовности в следующих случаях:
♦ по команде оператора (пользователя). Имеет место в тех диалоговых опера- ционных системах, где программа может иметь статус задачи (и при этом являться

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

24
мять, находится в состоянии готовности. Считается, что такому процессу уже вы- делены все необходимые ресурсы за исключением процессора.
Из состояния выполнения процесс может выйти по одной из следующих при- чин:
♦ процесс завершается, при этом он посредством обращения к супервизору передаёт управление операционной системе и сообщает о своем завершении. В ре- зультате этих действий супервизор либо переводит его в список бездействующих процессов (процесс переходит в пассивное состояние), либо уничтожает (уничто- жается, естественно, не сама программа, а именно задача, которая соответствовала исполнению некоторой программы). В состояние бездействия процесс может быть переведен принудительно: по команде оператора (действие этой и других команд оператора реализуется системным процессом, который «транслирует» команду в запрос к супервизору с требованием перевести указанный процесс в состояние без- действия), или путем обращения к супервизору операционной системы из другой задачи с требованием остановить данный процесс;
♦ процесс переводится супервизором операционной системы в состояние го- товности к исполнению в связи с появлением более приоритетной задачи или в связи с окончанием выделенного ему кванта времени;
♦ процесс блокируется (переводится в состояние ожидания) либо вследствие запроса операции ввода/вывода (которая должна быть выполнена прежде, чем он сможет продолжить исполнение), либо в силу невозможности предоставить ему ре- сурс, запрошенный в настоящий момент (причиной перевода в состояние ожидания может быть и отсутствие сегмента или страницы в случае организации механизмов виртуальной памяти, см. раздел «Сегментная, страничная и сегментно-страничная организация памяти» в главе 2), а также по команде оператора на приостановку за- дачи или по требованию через супервизор от другой задачи.
При наступлении соответствующего события (завершилась операция вво- да/вывода, освободился затребованный ресурс, в оперативную память загружена необходимая страница виртуальной памяти и т. д.) процесс деблокируется и пере- водится в состояние готовности к исполнению.

25
Таким образом, движущей силой, меняющей состояния процессов, являются события. Один из основных видов событий – это прерывания.
Реализация понятия последовательного
процесса в ОС
Для того чтобы операционная система могла управлять процессами, она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится специальная информационная структура, называемая
дескриптором процесса (описателем задачи, блоком управления задачей). В общем случае дескриптор процесса содержит следующую информацию:
♦ идентификатор процесса (так называемый PID – process identificator);
♦ тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов;
♦ приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы. В рамках одного класса процессов в первую очередь обслуживаются бо- лее приоритетные процессы;
♦ переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства вво- да/вывода и т. д.);
♦ защищённую область памяти (или адрес такой зоны), в которой хранятся те- кущие значения регистров процессора, если процесс прерывается, не закончив ра- боты. Эта информация называется контекстом задачи;
♦информацию о ресурсах, которыми процесс владеет и/или имеет право поль- зоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода и т. п.);
♦ место (или его адрес) для организации общения с другими процессами;
♦ параметры времени запуска (момент времени, когда процесс должен активи- зироваться, и периодичность этой процедуры);
♦ в случае отсутствия системы управления файлами – адрес задачи на диске в её исходном состоянии и адрес на диске, куда она выгружается из оперативной па- мяти, если её вытесняет другая (для диск-резидентных задач, которые постоянно

26
находятся во внешней памяти на системном магнитном диске и загружаются в опе- ративную память только на время выполнения).
Описатели задач, как правило, постоянно располагаются в оперативной памя- ти с целью ускорить работу супервизора, который организует их в списки (очере- ди) и отображает изменение состояния процесса перемещением соответствующего описателя из одного списка в другой. Для каждого состояния (за исключением со- стояния выполнения для однопроцессорной системы) операционная система ведет соответствующий список задач, находящихся в этом состоянии. Однако для со- стояния ожидания может быть не один список, а столько, сколько различных видов ресурсов могут вызывать состояние ожидания. Например, состояний ожидания за- вершения операции ввода/вывода может быть столько, сколько устройств вво- да/вывода имеется в системе.
В некоторых операционных системах количество описателей определяется жестко и заранее (на этапе генерации варианта операционной системы или в кон- фигурационном файле, который используется при загрузке ОС), в других – по мере необходимости система может выделять участки памяти под новые описатели. На- пример, в OS/2 максимально возможное количество описателей задач определяется в конфигурационном файле CONFIG.SYS, а в Windows NT оно в явном виде не за- дается. Справедливости ради стоит заметить, что в упомянутом файле указывается количество не процессов, а именно задач, и под задачей в данном случае понимает- ся как процесс, так и поток этого же процесса, называемый потоком или тредом
(см. следующий раздел). Например, строка в файле CONFIG.SYS
THREADS=1024
указывает» что всего в системе может параллельно существовать и выпол- няться до 1024 задач, включая вычислительные процессы и их потоки.
В ОС реального времени чаще всего количество процессов фиксируется и,
следовательно, целесообразно заранее определять (на этапе генерации или конфи- гурирования ОС) количество дескрипторов. Для использования таких ОС в ка- честве систем общего назначения (что сейчас встречается редко, а в недалеком прошлом достаточно часто в качестве вычислительных систем общего назначения

27
приобретали мини-ЭВМ и устанавливали на них ОС реального времени) обычно количество дескрипторов берется с некоторым запасом, и появление новой задачи связывается с заполнением этой информационной структуры. Поскольку дескрип- торы процессов постоянно располагаются в оперативной памяти (с целью ускорить работу диспетчера), то их количество не должно быть очень большим. При необхо- димости иметь большое количество задач один и тот же дескриптор может в разное время предоставляться для разных задач, но это сильно снижает скорость реагиро- вания системы.
Для более эффективной обработки данных в системах реального времени це- лесообразно иметь постоянные задачи/полностью или частично всегда существую- щие в системе независимо от того, поступило на них требование или нет. Каждая постоянная задача обладает некоторой собственной областью оперативной памяти
(ОЗУ-резидентные задачи) независимо от того, выполняется задача в данный мо- мент или нет. Эта область, в частности, может использоваться для хранения дан- ных, полученных задачей ранее. Данные могут храниться в ней и тогда, когда зада- ча находится в состоянии ожидания или даже в состоянии бездействия.
Для аппаратной поддержки работы операционных систем с этими информаци- онными структурами (дескрипторами задач) в процессорах могут быть реали- зованы соответствующие механизмы. Так, например, в микропроцессорах Intel
80х86 (см. главу 3 «Особенности архитектуры микропроцессоров 180х86 для ор- ганизации мультипрограммных операционных систем»), начиная с 80286, имеется специальный регистр TR (task register), указывающий местонахождение TSS (сег- мента состояния задачи
1
, см. раздел «Новые системные регистры микропро- цессоров i80x86», глава 3), в котором при переключении с задачи на задачу авто- матически сохраняется содержимое регистров процессора [2, 22, 84]. Как правило,
в современных ОС для этих микропроцессоров дескриптор задачи включает в себя
TSS. Другими словами, дескриптор задачи больше по размеру, чем TSS, и включа- ет в себя такие традиционные поля, как идентификатор задачи, её имя, тип, при- оритет и т. п.
1
TSS (task state segment) – сегмент состояния задачи.

28
Процессы и треды
Понятие процесса было введено для реализации идей мультипрограммирова- ния. Напомним, в свое время различали термины «мультизадачность» и «мульти- программирование». Таким образом, для реализации «мультизадачности» в её ис- ходном толковании необходимо было тоже ввести соответствующую сущность.
Такой сущностью и стали так называемые «легковесные» процессы, или, как их те- перь преимущественно называют, – потоки или треды (нити)
2
. Рассмотрим эти понятия подробнее.
Когда говорят о процессах (process), то тем самым хотят отметить, что опера- ционная система поддерживает их обособленность: у каждого процесса имеется свое виртуальное адресное пространство, каждому процессу назначаются свои ре- сурсы – файлы, окна, семафоры и т. д. Такая обособленность нужна для того, что- бы защитить один процесс от другого, поскольку они, совместно используя все ре- сурсы вычислительной системы, конкурируют друг с другом. В общем случае про- цессы просто никак не связаны между собой и могут принадлежать даже разным пользователям, разделяющим одну вычислительную систему. Другими словами, в случае процессов ОС считает их совершенно несвязанными и независимыми. При этом именно ОС берет на себя роль арбитра в конкуренции между процессами по поводу ресурсов.
Однако желательно иметь ещё и возможность задействовать внутренний па- раллелизм, который может быть в самих процессах. Такой внутренний паралле- лизм встречается достаточно часто и его использование позволяет ускорить их ре- шение. Например, некоторые операции, выполняемые приложением, могут требо- вать для своего исполнения достаточно длительного использования центрального процессора. В этом случае при интерактивной работе с приложением пользователь вынужден долго ожидать завершения заказанной операции и не может управлять приложением до тех пор, пока операция не выполнится до самого конца. Такие си- туации встречаются достаточно часто, например, при обработке больших изобра- жений в графических редакторах. Если же программные модули, исполняющие та-
2
Thread – поток, нить.