ос и с. ОСиС. 1. Классификация программного обеспечения
 Скачать 2.7 Mb.
|
|
Образ, дескриптор, контекст процесса В основе UNIX лежит концепция процесса - единицы управления и единицы потребления ресурсов. Процесс представляет собой программу в состоянии выполнения, причем в UNIX в рамках одного процесса не могут выполняться никакие параллельные действия. Каждый процесс работает в своем виртуальном адресном пространстве. Совокупность участков физической памяти, отображаемых на виртуальные адреса процесса, называется образом процесса. При управлении процессами операционная система использует два основных типа информационных структур: дескриптор процесса (структура proc) и контекст процесса (структура user). Дескриптор процесса содержит такую информацию о процессе, которая необходима ядру в течение всего жизненного цикла процесса, независимо от того, находится ли он в активном или пассивном состоянии, находится ли образ процесса в оперативной памяти или выгружен на диск. Дескрипторы отдельных процессов объединены в список, образующий таблицу процессов. Память для таблицы процессов отводится динамически в области ядра. На основании информации, содержащейся в таблице процессов, операционная система осуществляет планирование и синхронизацию процессов. В дескрипторе прямо или косвенно (через указатели на связанные с ним структуры) содержится информация о состоянии процесса, расположении образа процесса в оперативной памяти и на диске, о значении отдельных составляющих приоритета, а также его итоговое значение - глобальный приоритет, идентификатор пользователя, создавшего процесс, информация о родственных процессах, о событиях, осуществления которых ожидает данный процесс и некоторая другая информация. Контекст процесса содержит менее оперативную, но более объемную часть информации о процессе, необходимую для возобновления выполнения процесса с прерванного места: содержимое регистров процессора, коды ошибок выполняемых процессором системных вызовов, информацию о всех открытых данным процессом файлов и незавершенных операциях ввода-вывода (указатели на структуры file) и другие данные, характеризующие состояние вычислительной среды в момент прерывания. Контекст, так же как и дескриптор процесса, доступен только программам ядра, то есть находится в виртуальном адресном пространстве операционной системы, однако он хранится не в области ядра, а непосредственно примыкает к образу процесса и перемещается вместе с ним, если это необходимо, из оперативной памяти на диск. В UNIX для процессов предусмотрены два режима выполнения: привилегированный режим - "система" и обычный режим - "пользователь". В режиме "пользователь" запрещено выполнение действий, связанных с управлением ресурсами системы, в частности, корректировка системных таблиц, управление внешними устройствами, маскирование прерываний, обработка прерываний. В режиме "система" выполняются программы ядра, а в режиме "пользователь" - оболочка и прикладные программы. При необходимости выполнить привилегированные действия пользовательский процесс обращается с запросом к ядру в форме так называемого системного вызова. В результате системного вызова управление передается соответствующей программе ядра. С момента начала выполнения системного вызова процесс считается системным. Таким образом, один и тот же процесс может находиться в пользовательской и системной фазах. Эти фазы никогда не выполняются одновременно. В данных версиях UNIX процесс, работающий в режиме системы, не мог быть вытеснен другим процессом. Из-за этого организация ядра, которое составляет привилегированную общую часть всех процессов, упрощалась, т.к. все функции ядра не были реентерабельными. Однако, при этом реактивность системы страдала - любой процесс, даже низкоприоритетный, войдя в системную фазу, мог оставаться в ней сколь угодно долго. Из-за этого свойства UNIX не мог использоваться в качестве ОС реального времени. В более поздних версиях организация ядра усложнилась и процесс можно вытеснить и в системной фазе, но не в произвольный момент времени, а только в определенные периоды его работы, когда процесс сам разрешает это сделать установкой специального сигнала. Так же меется несколько процессов, которые не имеют пользовательской фазы, например, процесс pageout, организующий выталкивание страниц на диск. Порождение процессов Порождение процессов в системе UNIX происходит следующим образом. При создании процесса строится образ порожденного процесса, являющийся точной копией образа породившего процесса. Сегмент данных и сегмент стека отца действительно копируются на новое место, образуя сегменты данных и стека сына. Процедурный сегмент копируется только тогда, когда он не является разделяемым. В противном случае сын становится еще одним процессом, разделяющим данный процедурный сегмент. После выполнения системного вызова fork оба процесса продолжают выполнение с одной и той же точки. Чтобы процесс мог опознать, является ли он отцом или сыном, системный вызов fork возвращает в качестве своего значения в породивший процесс идентификатор порожденного процесса, а в порожденный процесс NULL. Типичное разветвление на языке C записывается так: if( fork() ) { действия отца } else { действия сына } Идентификатор сына может быть присвоен переменной, входящей в контекст процесса-отца. Так как контекст процесса наследуется его потомками, то дети могут узнать идентификаторы своих старших братьев, так образом сумма знаний наследуется при порождении и может быть распространена между родственными процессами. Наследуются все характеристики процесса, содержащиеся в контексте. На независимости идентификатора процесса от выполняемой процессом программы построен механизм, позволяющий процессу придти к выполнению другой программы с помощью системного вызова exec. Таким образом в UNIX порождение нового процесса происходит в два этапа - сначала создается копия процесса-родителя, то есть дублируется дескриптор, контекст и образ процесса. Затем у нового процесса производится замена кодового сегмента на заданный. Вновь созданному процессу операционная система присваивает целочисленный идентификатор, уникальный за весь период функционирования системы. Планирование процессов В системе UNIX реализована вытесняющая многозадачность, основанная на использовании приоритетов и квантования. Все процессы разбиты на несколько групп, называемых классами приоритетов. Каждая группа имеет свои характеристики планирования процессов. Созданный процесс наследует характеристики планирования процесса-родителя, которые включают класс приоритета и величину приоритета в этом классе. Процесс остается в данном классе до тех пор, пока не будет выполнен системный вызов, изменяющий его класс. В UNIX возможно включение новых классов приоритетов при инсталляции системы. В настоящее время имеется три приоритетных класса: класс реального времени, класс системных процессов и класс процессов разделения времени. В отличие от ранних версий UNIX приоритетность (привилегии) процесса тем выше, чем больше число, выражающее приоритет. На рисунке 5.2 показаны диапазоны изменения приоритетов для разных классов. Значения приоритетов определяются для разных классов по разному. Процессы системного класса используют стратегию фиксированных приоритетов. Системный класс зарезервирован для процессов ядра. Уровень приоритета процессу назначается ядром и никогда не изменяется. Заметим, что пользовательский процесс, перешедший в системную фазу, не переходит при этом в системный класс приоритетов. Процессы реального времени также используют стратегию фиксированных приоритетов, но пользователь может их изменять. Так как при наличии готовых к выполнению процессов реального времени другие процессы не рассматриваются, то процессы реального времени надо тщательно проектировать, чтобы они не захватывали процессор на слишком долгое время. Характеристики планирования процессов реального времени включают две величины: уровень глобального приоритета и квант времени. Для каждого уровня приоритета имеется по умолчанию своя величина кванта времени. Процессу разрешается захватывать процессор на указанный квант времени, а по его истечении планировщик снимает процесс с выполнения. Состав класса процессов разделения времени наиболее неопределенный и часто меняющийся, в отличие от системных процессов и процессов реального времени. Для справедливого распределения времени процессора между процессами, в этом классе используется стратегия динамических приоритетов, которая адаптируется к операционным характеристикам процесса. Величина приоритета, назначаемого процессам разделения времени, вычисляется пропорционально значениям двух составляющих: пользовательской части и системной части. Пользовательская часть приоритета может быть изменена суперпользователем и владельцем процесса, но в последнем случае только в сторону его снижения.
Рис. 5.2. Приоритетные классы процессов Системная составляющая позволяет планировщику управлять процессами в зависимости от того, как долго они используют процессор, не уходя в состояние ожидания. Тем процессам, которые потребляют большие периоды времени без ухода в состояние ожидания, приоритет снижается, а тем процессам, которые часто уходят в состояние ожидания после короткого периода использования процессора, приоритет повышается. Таким образом, процессам, ведущим себя не по-джентльменски, дается низкий приоритет, что означает, что они реже выбираются на выполнение. Но процессам с низким приоритетом даются большие кванты времени, чем процессам с высокими приоритетами. Таким образом, хотя низкоприоритетный процесс и не работает так часто, как высокоприоритетный, но зато, когда он наконец выбирается на выполнение, ему отводится больше времени. Планировщик использует следующие характеристики для процессов разделения времени:
Для процессов разделения времени в дескрипторе процесса proc имеется указатель на структуру, специфическую для данного класса процесса. Эта структура состоит из полей, используемых для вычисления глобального приоритета:
В некоторых версиях UNIX нет поддержки многонитевой (multithreading) организации процессов на уровне ядра, хотя и есть два системных вызова для организации нитей в пользовательском режиме. Во многих коммерческих реализациях UNIX в ядро включена поддержка нитей за счет собственной модификации исходных текстов. 28. Режимы ядра в Unix В действительности расположенный в ядре планировщик Unix работает не со "статическими" приоритетами nice, а с приоритетами, динамически изменяемыми по ходу выполнения процесса. Так, в BSD-системах к процессам, которые "скушали" определенный объем процессорного времени, например 20 минут, автоматически применяется вызов nice [4]. Схема, введенная в BSD 4.3, рассмотрена в [6]. Дальнейшее изложение в данном разделе статьи будет ориентировано на Unix System V. Как значение nice, так и значение динамического приоритета для процессов можно определить из вывода команды ps -l. Эти значения приводятся в колонках, озаглавленных NI и PRI соответственно. Здесь можно провести некоторую аналогию с языком управления заданиями в ОС MVS. Параметр PRTY оператора EXEC является в определенном смысле аналогом nice: от их значений зависит динамический приоритет. Однако "настоящий" приоритет выполнения в MVS может быть задан параметром DPRTY, хотя и этот приоритет MVS может динамически изменить. Планировщик Unix поддерживает фактически несколько циклических (round robin) очередей c обратной связью. Процесс, квант времени которого истек, возвращается в зависимости от динамического приоритета в одну из таких очередей, весь набор которых называют "очередью выполнения" (run queue). Планировщик просматривает набор процессов, находящихся в оперативной памяти и готовых к выполнению, и выбирает среди них наиболее приоритетный процесс. Если имеется несколько процессов с одинаково высокой приоритетностью на выполнение выбирается тот, который дольше всего ждет процессорный ресурс в состоянии готовности к выполнению. Если же не удается вообще найти готовые к выполнению процессы, планировщик ожидает следующего прерывания, которое произойдет не позднее чем через один такт часов, и снова выполняет процесс планирования. Все процессы в соответствии с их приоритетами можно разбить на два класса: пользовательские процессы разделения времени и системные процессы (процессы ядра). В классе имеется несколько уровней приоритета, каждому из которых в классе пользовательских процессов соответствует своя очередь. Приоритетность пользовательских процессов лежит ниже некоторого порогового значения, а процессов ядра - выше этого порога. Далее речь пойдет только о пользовательских процессах, принадлежащих классу процессов разделения времени. Когда процесс "отправляется спать", планировщик присваивает ему фиксированный приоритет в зависимости от причины засыпания, который не зависит от наблюдавшейся перед этим событием активности "поедания" процессом процессорных ресурсов. Дополнительные подробности можно найти в [7]. Динамические приоритеты процессов, работающих в пользовательском режиме, перевычисляются планировщиком Unix System V один раз в секунду [7]. Обработчик прерываний от часов может прерывать пользовательский процесс несколько раз за его квант времени. Каждый раз при обработке такого прерывания счетчик "С" использования процессора в соответствующей строке таблицы процессов увеличивается на 1. Каждую секунду обработчик прерываний от часов пересчитывает счетчик использования процессора для каждого пользовательского процесса по формуле С=С*k (8) где 0 dprty=K*C + базовый_приоритет + nice (9) где базовый_приоритет - это указанное пороговое значение приоритета пользовательских процессов (более приоритетными бывают только системные процессы). Константа К для System V равна 0.5. Близкие к (8), (9) алгоритмы использует Digital Unix. Чем ниже величина dprty динамического приоритета процесса, тем выше его приоритетность. Самая низкая величина dprty отвечает пороговому значению, ниже которого располагаются только системные процессы, работающие в режиме ядра. В результате перерасчета dprty, пользовательские процессы, активно использующие процессор перемещаются из очереди с одним приоритетом в очереди с другим, более высоким dprty (в очереди менее приоритетных процессов). Чтобы понять, как работает механизм перерасчета динамических приоритетов в соответствии с формулами (8) и (9), рассмотрим конкретный пример, взятый из [7] для простейшего случая nice=0. Пусть имеется три готовых к выполнению процесса A, B, C, находящихся в памяти и имеющих стартовое значение приоритета, равное базовому значению (60), - максимально возможную приоритетность. Предположим, что эти процессы не делают системных вызовов и что в системе нет других готовых к выполнению процессов. Пусть квант времени равен 1 сек, а прерывания от часов происходят 60 раз за 1 сек. Если A начинает выполняться первым, то через 1 сек его счетчик использования процессора будет равен 60. В этот момент времени планировщик пересчитает dprty (рис.1), и далее будет выполняться процесс B, а его счетчик использования процессора будет возрастать. При t=2 cек управление получит наиболее приоритетный процесс С и т. д. | |||||||||||||||||||||||||||||||||||