Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 29 (всего у книги 41 страниц)

Динамическое планирование приоритетов

В предыдущих разделах мы рассмотрели более понятную, но упрощенную модель диспетчеризации задач в AS/400. Со времен первой System/38 в структуру задач было внесено множество изменений для удовлетворения требований различных приложений и структур системы. Например, мы предполагали, что когда-нибудь системе понадобится динамически настраивать приоритет задачи во время исполнения. Предположим, что задача не получает достаточного для ее решения процессорного времени, или заблокировала некоторый системный ресурс, которого ожидает задача с большим приоритетом. Если бы система могла временно повышать и понижать приоритеты подобных задач, то можно было бы найти выход из только что описанных ситуаций. Такая возможность была добавлена в System/38 и ранние AS/400.

С появлением многопроцессорных конфигураций, и особенно в связи с нашим намерением использовать большее количество процессоров в конфигурациях SMP, было решено, что нужна более гибкая настройка приоритета задач. Группа исследователей в подразделении IBM Research в Нью-Йорке работала над механизмом, который они назвали планировщик с оценкой задержки (delay-cost scheduler). Специалисты из Рочестера подключились к этому проекту и вместе с IBM Research создали версию этого планировщика, которая теперь используется в SLIC на всех RISC-системах AS/400. Применяемые в планировщике алгоритмы, пожалуй, слишком сложны для этой книги. Но они вполне позволяют выполнять задачи вне порядка их приоритетов, если производительность системы при этом возрастает. В результате, загрузка RISC-процессоров становится более эффективной, особенно, в n-канальных конфигурациях.

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

Процессы в MI

Процесс в MI – это системный объект, называемый пространством управления процессом. Обратите внимание, что эквивалентного объекта OS/400 нет. (Мы еще поговорим об этом в разделах, посвященных управлению работами). Задача процесса в MI – связать воедино ресурсы, необходимые для исполнения, или, точнее, вызова программы. Программы разделяемы, поэтому одна программа может исполняться несколькими пользователями. Конечно, данные, используемые программой, для всех пользователей будут разными. Так как программе необходимо некоторое место для временного хранения используемых переменных, то для каждого ее вызова нужно выделить рабочую область. Ответственность за это лежит на процессе MI.

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

Чтобы понять, какие варианты размещения переменных должен поддерживать процесс, необходимо рассмотреть три отдельные области, используемые для размещения данных современными ЯВУ, а именно:

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

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

3.Область кучи. Эта область памяти используется для размещения динамичес-

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

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

Исходная модель процессов

Подобно исходной модели программ (ОРМ), обсуждавшейся в главе 4, исходная модель процессов была разработана для поддержки таких языков, как RPG, Cobol и CL. Исходная модель соответствует структуре, в которой каждый процесс – единица работы. Программы, исполнявшиеся процессами, зачастую не были модульными.

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

1. Область статической памяти программы PSSA (Program Static Storage Area) – единственная копия статической области памяти для всего процесса.

Область автоматической памяти программы PASA (Program Automatic Storage Area) содержала стек вызовов.

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

Системный объект MI для процесса исходной модели, который также называется пространством управления процессом, содержит два сегмента: базовый сегмент, где находится основная часть управляющей информации вместе с TDE процесса; а также сегмент рабочей области вызова IWA (invocation work area). Основное назначение последнего – хранение стека вызовов-возвратов процесса.

Исходная модель процессов очень хорошо работала для приложений, написанных для System/38 и ранних моделей AS/400. Однако переход на блочно-структурирован-ные языки и необходимость поддержки приложений, написанных в соответствии со стандартами POSIX, привели к разработке модели процессов ILE.

Модель процессов ILE

Модель процессов ILE впервые появилась на AS/400 в версии V2R3 вместе с одноименной программной моделью и компиляторами. Исходная модель процессов и модель процессов ILE сосуществовали в AS/400 до перехода на RISC-процессоры. Затем исходные модели были устранены, ведь RISC-системы поддерживают только модель программ и модель процессов ILE. (Модели ILE для программ и процессов создавались специально в расчете на RISC-процессоры.)

Давайте рассмотрим модель процессов ILE более подробно. Но прежде остановимся на изменениях, внесенных в AS/400 для поддержки программной модели ILE. В MI для этого используются активизации программ, группы активизации, вызовы процедур и новый процедурный указатель.

В главе 4 мы говорили о компиляторах и программной модели ILE. Мы рассмотрели, как ILE изменила способ создания программ, а также концепцию модуля. Вспомним, что модуль – это результат работы компилятора ILE. Модуль содержит одну или несколько процедур. Средство связывания (binder) ILE упаковывает модули в программы и служебные программы. Таким образом, программы и служебные программы могут содержать один или несколько модулей, которые, в свою очередь, состоят из одной или нескольких процедур. Для обращения к программам и процедурам внутри модулей как часть ILE были введены два типа команд вызова («CALLPGM» и «CALLBP»).

Программа – это системный объект MI, который всегда вызывается с помощью команды: внешнего вызова «CALLPGM» MI. Аналогично старой команде «CALLX», команда «CALLPGM» для идентификации программы использует системный указатель. Затем эта команда активизирует программу. В ходе активизации завершается межпрограммное связывание: например, если программа использует модули, связанные через ссылку, то происходит разрешение связей со служебной программой. Активизация программы неявно создает группу активизации, которая предоставляет рабочую область для программы, а также инициализирует ее статическую память.

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

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

ку). Обратите внимание, что MI контролирует последовательность вызовов на уровне процедур, а не программ.

Когда приложение впервые переносится на RISC-процессор, программа исходной модели конвертируется в программу ILE, состоящую из одной процедуры. Таким образом, преобразованная программа исходной модели, как и любая программа с единственной процедурой, всегда вызывается с помощью «CALLPGM». Если программа, созданная компилятором ILE, состоит из нескольких процедур, то первая процедура вызывается с помощью «CALLPGM», а последующие – с помощью «CALLBP».

В главе 4 мы также затронули группы активизации. Они предоставляют рабочие области для активизации одной или нескольких программ. Каждая группа активизации имеет собственную область статической памяти, область стека и область кучи. Так как с появлением RISC-процессоров осталась только модель ILE, данная рабочая область поддерживает также все процессы оригинальной модели и заменяет собой старые области памяти PASA/PSSA.

Группа активизации – это не системный объект, а часть объекта-процесса MI. Каждый объект-процесс содержит две или более групп активизации, одна из которых используется системой. Каждый процесс содержит также, по крайней мере, одну пользовательскую группу активизации. При переносе процесса исходной модели, созданного на системе с процессором IMPI, на систему с RISC-процессором, этот процесс трансформируется в процесс ILE с одной пользовательской группой активизации.

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

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

Внутри процесса ILE

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

Структура процессов ILE

Сначала разберемся с компонентами процесса ILE и сокращениями, их обозначающими:

Блок управления процессом PCB (Process Control Block) содержится в системном объекте MI. Ранее мы говорили, что этот системный объект, кроме всего прочего, содержит TDE процесса. Далее мы увидим, что PCB также содержит адреса других связанных с процессом компонентов.

Рабочая область активизации процесса PAWA (Process Activation Work Area) представляет собой кучу, используемую для размещения структур времени выполнения, таких как группы активизации. У каждого процесса – одна PAWA.

Родительская группа активизации PAGP (Parent Activation Group) – это корневая структура подструктуры процесса, содержащая список всех групп активизации процесса. Несмотря на свое название, сама PAGP не является группой активизации.

Группа активизации ACTGRP (Activation Group) предоставляет активизации программы ресурсы памяти (стек, статическую память и кучу). ACTGRP похожа на минипроцесс.

Могильные сегменты (Tombstone Segments) используются для создания указателей объектов процесса POP (process object pointer) – описателей (handle) структур SLIC. Описатели используются многими ОС, включая OS/ 2 и Apple Macintosh как косвенные указатели блоков памяти в куче. Вместо прямой адресации таких блоков описатель ссылается а основной указатель, обычно расположенный по фиксированному адресу и содержащий адрес блока. При перемещении блоков по памяти нужно изменять только значение основного указателя. Сегменты называются могильными, так как они предотвращают непосредственный доступ к структурам SLIC; даже если уровень защиты системы разрешает доступ к этим сегментам. Основной указатель находится в области памяти, доступной только SLIC.

Область очередей процесса (Process Queue Space) – в ней размещаются одна или несколько очередей приема-передачи (SRQ) сообщений.

На рисунке 9.4 показано расположение перечисленных компонентов в структуре процессов ILE. Обратите внимание, что в PAWA содержится список всех групп активизации (PAGP) и сами эти группы. На рисунке показаны четыре группы активизации, хотя как уже упоминалось, их может быть минимум две. По умолчанию всегда первая ACTGRP – это системная группа активизации, а вторая – пользовательская группа активизации.

PCB = Блок управления процессом PAWA = Рабочая область активизации процесса PAGP = Родительская группа активизации ACTGRP = Группа активизации

Рисунок 9.4. Структура процесса ILE

А теперь заглянем внутрь группы активизации.

Группа активизации ILE

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

Блок управления активизацией программы PACB (Program Activation Control Block) используется в процессе выполнения программы для хранения адресов. Эта структура позволяет находить процедуры и данные, связанные с программой. Для каждой активной программы имеется по одному PACB, и каждый PACB содержит один или несколько векторов связывания модулей.

Вектор связывания модулей MBV (Module Binding Vector) предназначен для хранения адресов, используемых модулем. Он содержит адреса данных и процедур, на которые ссылается модуль.

Справочник группы активизации (Activation Group Directory) представляет собой каталог имен, используемый для позднего связывания программ и данных.

Справочная таблица процедур PRT (Procedure Reference Table) – одна на каждую группу активизации. Ее сегменты содержат точки входа процедур, используемые для вызовов между группами активизации и через процедурные указатели.

Список кучи (Heap List) идентифицирует области кучи, связанные с данной группой активизации.

Область кучи (Heap Spaces) состоит из управляющего сегмента и нескольких сегментов данных. Управление кучами для MI и SLIC осуществляется диспетчером кучи SLIC.

Сегменты автоматической памяти (Auto Storage Segments) содержат стек, используемый группой активизации для автоматической памяти.

Сегменты статической памяти (Static Storage Segments) – место, где располагается статическая память группы активизации.

На рисунке 9.5 показано расположение перечисленных компонентов в группе активизации.

PACB = Блок управления активизацией программы MBV = Вектор связывания модулей PRT = Справочная таблица процедур

Рисунок 9.5. Группа активизации ILE

Итак, подведем итоги. Каждый процесс AS/400 содержит PAWA. Внутри PAWA находятся PAGP, а также две или более ACTGRP. В каждой ACTGRP – PACB, содержащий несколько MBV, каталог группы активизации, PRT, список кучи, одну или несколько областей кучи, сегменты автоматической и статической памяти. Надеюсь, теперь Вам все понятно?

Исключения, события и прерывания

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

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

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

Исключения и события MI

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

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

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

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

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

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

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