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

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

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

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

Управление исключениями SLIC

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

Прерывания классифицируются по тому, вызваны ли они исполнением конкретной команды или каким-то другим событием в системе. В архитектуре PowerPC определено 15 типов прерываний. Пять прерываний генерируются аппаратно, а именно:

сброс системы (System Reset) – прерывание при выключении или включении системы;

машинная ошибка (Machine Check), служащая для сообщения об аппаратных сбоях;

внешнее (External) – прерывание, уведомляющее процессор о том, что некоторое событие за его пределами (например, ввод-вывод) требует внимания;

монитор производительности (Performance Monitor), при включенном мониторинге производительности уведомляющий процессор о событии, за которым ведется наблюдение;

уменьшитель (Decrementer), используемый таймерами и извещающий процессор об истечении некоторого интервала времени.

Некоторые прерывания генерируются в результате выполнения команд. Перечислим их.

Память данных (Data Storage) – это прерывание сообщает, что команда предприняла безуспешные попытки доступа к хранилищу данных. Используется для сигнализации о невозможности трансляции эффективного адреса (страничная ошибка), нарушении защиты памяти или переполнении эффективного адреса (ЕАО).

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

Ошибка прямого сохранения (Direct-Store Error) также аналогично прерыванию памяти данных, но возникает при обращении по адресу прямого сохранения (DS). Отметьте, что по этому адресу не может произойти страничная ошибка.

Выравнивание (Alignment) происходит при попытке обращения к операнду, который не выровнен на необходимую границу памяти.

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

«Нет плавающей точки» (Floating-Point Unavailable) – прерывание с этим названием возникает при попытке выполнить команду с плавающей точкой, если разряд в MSR указывает, что процессор не может выполнять таких команд. Архитектура PowerPC позволяет отключать операции с плавающей точкой.

Поддержка плавающей точки (Floating-Point Assist) – это прерывание используется для программной поддержки относительно редко используемых и сложных операций с плавающей точкой.

Трассировка (Trace) – прерывание, генерируемое после успешного выполнения каждой трассируемой команды. Возможность пошаговой трассировки всех команд или переходов включается установкой разрядов в MSR.

Системный вызов (System Call) – прерывания этого типа достигаются исполнением соответствующей команды PowerPC. Подробней об этом – в следующем разделе.

Системный вызов по вектору (System Call Vectored) – тип прерывания, похожий на системный вызов. Эта команда, которая также описана в следующем разделе, аналогична команде системного вызова, но может передавать управление любой из 128 процедур.

Для обработки прерываний в SLIC предусмотрены специальные процедуры. Когда аппаратура обнаруживает прерывание, управление передается одному из обработчиков исключений первого уровня FLEH (First Level Exception Handlers). То, каким образом осуществляется аппаратная передача управления, будет рассмотрено далее. Если одна из процедур FLEH обработала исключение (в основном именно так и происходит), то управление возвращается к нормальной обработке команд.

Если исключение вызвано командой и не было обработано, то FLEH передает управление обработчику исключений второго уровня SLEH (Second Level Exception Handler). SLEH обрабатывает менее частые исключения, такие как исключение блокировки системного объекта. Он также отвечает за выделение исключений, которые не могут быть обработаны SLIC. Если необработанное исключение возникло, когда система исполняла команду, транслированную MI, то SLEH передает управление генератору исключений MI.

Если же необработанное исключение произошло при исполнении команды SLIC, то SLEH передает управление обработчику исключений третьего уровня TLEH (Third Level Exception Handler). TLEH получает управление от SLEH, от обработчика машинных ошибок (если таковая произошла при выполнении процедуры SLIC), или от любой другой процедуры SLIC, обнаружившей исключение.

Сначала TLEH вызывает обработчики исключений компонентов CSEH (Component Specific Exception Handlers), которые были установлены различными компонентами SLIC. CSEH используются для освобождения ресурсов, занятых выполнением некоторой операции, или для очистки частичных результатов неудавшейся операции, или исполнения кода, позволяющего продолжать работу при ошибке. CSEH, которые должны выполняться для данной задачи, определяются блоками CSEH, присоединенными к TDE задачи. Каждый блок CSEH содержит адрес процедуры CSEH, указатель стека и данные, необходимые этой процедуре. После выполнения всех CSEH задачи управление возвращается обратно TLEH.

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

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

Аппаратное переключение контекста

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

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

В главе 8 мы рассматривали регистр состояния машины (MSR) и значение некоторых его битов. Архитектура PowerPC определяет для MSR и некоторые другие биты, описанные в предыдущем разделе. Оставшиеся биты рассматриваться не будут, так как не относятся к обсуждаемой теме. Здесь лишь важно понимать, что значения всех битов MSR определяют контекст процессора. Значения битов могут измениться при прерывании процессора.

Если при вызове процедуры SLIC необходимо изменить контекст процессора, то может быть использована команда «Системный вызов» («sc»). Эта команда в транслированных программах MI позволяет обратиться за обслуживанием к компонентам ОС в SLIC. Как мы только что упоминали, при исполнении команды «sc» процессор генерирует прерывание системного вызова. Читатели, знакомые с System/370, могут заметить, что этим команда «sc» в PowerPC очень похожа на команду «Вызов супервизора» («SVC») в архитектуре System/370. Архитектура PowerPC ведет свою родословную от разработанного в середине 70-х миникомпьютера 801, архитектура которого создавалась под большим влиянием мэйнфреймов System/370. В некотором роде и MSR – аналог «Слова состояния программы» («PSW») System/370.

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

рядном регистре процессора, который называется «Регистр сохранения-восстановления состояния машины 0» или SSR 0 (Machine Status Save/Restore Register 0). Если прерывание было вызвано командой «sc», то в SSR 0 будет помещен адрес команды, следующей за «sc». Далее некоторые биты текущего MSR сохраняются в другом 64-разрядном регистре, который называется SSR 1. Наконец, остальные разряды SSR 1 заполняются информацией, специфичной для типа данного прерывания.

После сохранения текущего состояния машины, аппаратура прерываний изменяет некоторые биты MSR, причем для каждого типа прерываний – свои. В частности, биты перемещения (MSRIR и MSRDR) всегда отключаются, так что процедуры – обработчики прерываний используют реальные адреса и не могут вызвать страничных ошибок. После изменения битов MSR аппаратура прерываний устанавливает адрес следующей выбираемой команды по определенному смещению относительно некоторого базового адреса. Архитектурой PowerPC определены конкретные смещения для каждого типа прерываний. Еще один бит MSR, называемый префиксом прерывания, выбирает один из двух базовых адресов.

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

В конце процедуры обработки прерываний выполняется еще одна специальная команда PowerPC – «Возврат из прерывания» или «rfi» («Return From Interrupt))). По этой команде происходит восстановление процессора в состояние, в котором он находился до прерывания. Сначала часть битов SSR 1 помещается в соответствующие биты MSR. Затем, под управлением нового значения MSR, выбирается следующая команда по адресу из SSR 0. Если на момент возникновения только что обработанного прерывания имелись и другие ожидающие исключения, то перед выполнением первой команды в контексте, установленном командой «rti», генерируется прерывание, связанное с ожидающим исключением наивысшего приоритета.

Две только что описанные команды PowerPC: «sc» и «rti», – позволяют процессору вызывать, если надо, обработчик прерывания и возвращаться к нормальной деятельности, когда прерывание обработано.

В AS/400 мы хотели иметь аналогичный механизм, позволяющий одной процедуре SLIC вызывать другую. Например, планировалось обеспечить высокую эффективность вызова SLEH из FLEH. С этой целью в архитектуре PowerPC появились две новые команды: «системный вызов по вектору» или «scv» («System Call Vectored») и «возврат из системного вызова по вектору» или «rfscv» («Return From System Call Vectored»).

Команда «scv» похожа на команду «sc», но есть и несколько важных отличий. Так, вместо передачи управление только по одному адресу, команда «scv» задает один из 128 адресов, по каждому из которых располагается отдельная процедура SLIC. Таким образом, с помощью команды «scv» можно эффективно передавать управление между процедурами SLIC.

Другая отличительная черта «scv» в том, что эта команда не изменяет значения битов MSR. Это означает, например, что вызванная процедура может использовать виртуальные адреса. При использовании виртуальной адресации процедуры SLIC можно писать так, что будет возможна откачка их страниц на диск.

Кроме того, команда «scv» не использует регистры SSR 0 и SSR 1 для сохранения состояния машины. Вместо этого, она задействует два процессорных регистра общего назначения.

Команда «rfscv», как это и следует из ее названия, выполняет возврат после «scv».

Задания и управление ими OS/400

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

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

Важно отметить, что структура задач AS/400 на аппаратном уровне – одна из наиболее эффективных. В коммерческом приложении значительная часть (до 80 – 90 процентов) обработки, выполняется ОС, а не самим приложением. Приложение запрашивает обработку у ОС, вместо того чтобы выполнять ее самостоятельно. Непосредственно выполнением такой обработки занимается, в основном, SLIC, где структура задач очень эффективна.

Давайте рассмотрим, как в AS/400 поддерживаются потоки, и как это позволяет переносить приложения, написанные для других ОС.

Концепции управления заданиями

Управление заданиями, переданными пользователем AS/400, выполняется компонентом управления заданиями OS/400. Задание – это единица работы, переданной на выполнение. Как Вы помните, управление заданиями различает несколько типов заданий, включая традиционные интерактивные и пакетные.

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

Рисунок 9.6. Концепции управления работой

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

Подсистемы

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

Описание задания – это объект OS/400, задающий атрибуты и ресурсы, связанные с заданием. Он определяет:

список библиотек (по умолчанию);

очередь заданий;

данные маршрутизации;

принтер (по умолчанию);

приоритет планировщика вывода;

профиль пользователя.

Класс представляет собой объект OS/400, содержащий параметры, которые задают среду выполнения. Некоторые из них относятся к выделенным заданию ресурсам процессора. Например, может быть ограничено число процессов класса, выполняющихся одновременно. Это позволяет управлять объемом взаимного влияния процессов, конкурирующих за один и тот же системный ресурс. Данный предел, обычно называемый уровнем активности, связан с пулом памяти.

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

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

Старая и новая структуры задания

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

Старая структура задания	Новая структура задания на основе
	модели процессов ILE
Разделяемые файлы видимы всем	Разделяемые файлы видимы всем
прикладным программам задания	прикладным программам задания,
	либо каждое приложение определяет
	собственное использование файлов
Внешние имена – общие на уровне	Область видимости внешних имен —
задания, а не на уровне приложений	одиночное приложение, то есть каж
	дое приложение задания имеет свое
	собственное пространство имен для
	внешних переменных
Управление транзакциями	Управление транзакциями осуществ
осуществляется для всего задания	ляется как на уровне задания, так и
	на уровне приложений
Допускается только одна активизация	Допускаются множественные активи
программы в задании	зации одной и той же программы.
	Каждая активизация имеет собствен
	ные (защищенные) области памяти
Выделяется только одна область	У каждой программы своя собствен-
статической и автоматической (стек)	ная защищенная статическая, авто-
памяти и одна область динамической	матическая (стек) и динамическая
памяти для каждого языка	(куча) память
программирования

Процессы, задачи, задания, группы активизации и потоки

Как уже упоминалось, первоначально в AS/400 было определено три уровня работы. Самый низкий уровень, под MI, – задача. Процесс «живет» на уровне MI и построен на структуре задач SLIC. Поверх модели процессов MI OS/400 в качестве единицы работы поддерживает задание. Большинство других ОС работают непосредственно с процессами. Но не OS/400. В этом отношении задание в ней – аналог процесса в других ОС.

Полнофункциональное задание обеспечивает лучшие возможности разделения ресурсов и защиты, чем процессы в других ОС; однако, для создания такого задания нужно больше времени. Задание AS/400 можно называть «полновесным».

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

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

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

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

Достоинство потоков в том, что они позволяют разным частям одного приложения исполняться параллельно. Особенно важны потоки в распределенной среде, они обязательны для стандарта, известного как DCE (Distributed Computing Environment). DCE использует модель процессов POSIX.

Поскольку мы хотели реализовать в AS/400 интерфейсы DCE и POSIX, нам нужно было найти некоторый способ поддержки потоков POSIX. Мы рассмотрели две модели. Первая – встроенные потоки, где в процессе принимают участие множество TDE, для каждой группы активизации – собственный. Таким образом, группа активизации становится отдельной единицей диспетчирования, своего рода аналогом потока. Данная модель достаточно точно соответствует общепринятой модели потоков. К сожалению, она также требовала внесения в OS/400 множества изменений, больше, чем позволяло время, отведенное на проект V3R1. Поэтому для начала нам пришлось выбрать вторую, несколько менее удачную модель.

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

Такое использование задания OS/400 в качестве потока, успешно работает, но имеет один существенный недостаток: для создания полнофункционального задания требуется больше времени, по сравнению с другими системами, где применяются «легковесные» потоки. Для повышения производительности AS/400 мы предусмотрели пул заранее созданных заданий. Когда нужно быстро создать поток, используется одно из заданий пула. При разрушении потока задание возвращается в пул.

Данная модель потоков была представлена как часть CPA (Common Programming) API в V3R1. Начальная цель была достигнута, но мы знали, что это паллиатив. Хотелось перенести на AS/400 несколько других приложений, например, Lotus Domino. Мы рассмотрим Domino в его связи с AS/400 в главе 11, сейчас же нам следует признать, что Domino написан для потоковой модели. Так, подгоняемые мечтой о нормальной работе Domino на AS/400, мы начали проектирование встроенных потоков для версии V4 OS/400.

На рисунке 9.7 показано соотношение двух потоковых моделей системы и средств поддержки приложений (application enabler). Последние включают в себя библиотеки времени исполнения для языков, типа С, С+ + и Java, интегрированную файловую систему и библиотеки классов объектов. В главе 11 мы рассмотрим Java и его объектную модель, а также модели IBM SOM (System Object Model) и DSOM (Distributed System Object Model).

Рисунок 9.7. Средства поддержки приложений для потоков

Мы полагаем, что с течением времени все больше и больше приложений будет создаваться для потоковой модели. Поддержка потоков часто позволяет приложениям, написанным для какой-либо другой ОС, эффективно работать на AS/400.