Основы AS/400
Шрифт:
Пул памяти, (не путать с пулом вспомогательной памяти!) — это средство резервирования для подсистемы некоторого объема основной (оперативной) памяти. В основной памяти может быть размещено до 16 пулов памяти, один из которых всегда зарезервирован машиной. Пул памяти — это часть памяти, куда осуществляется динамическая подкачка страниц процессов, связанных с этим пулом. Например, один пул памяти может быть выделен для всех интерактивных заданий, а другой — для всех пакетных. Такой подход позволяет гарантировать, что пакетное задание не отберет себе страничный фрейм у интерактивного задания, и таким образом не повлияет на время ожидания ответа пользователем. Пакетные задания могут отбирать только страничные фреймы у других пакетных задач из пакетного пула памяти. Пулы памяти определяются в описании подсистемы.
Размеры, число и уровни активности пулов памяти управляются пользователем системы. Таким образом, система может быть настроена так,
Старая и новая структуры задания
С появлением модели процессов 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.
Выводы
В разных ОС процессы реализованы по-разному. Каждая система определяет мощность процесса, его структуру, а также то, как он должен быть защищен. Модель процессов AS/400 доказала свою высокую эффективность и способность поддержки важнейших приложений. Современнейшая структура задач, на основе которой работают все остальные функции системы, позволяет моделям процессов и заданий эволюционировать для нужд будущих сред приложений.