Как уже упоминалось, первоначально в 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 доказала свою высокую эффективность и способность поддержки важнейших приложений. Современнейшая структура задач, на основе которой работают все остальные функции системы, позволяет моделям процессов и заданий эволюционировать для нужд будущих сред приложений.

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

Ввод-вывод — это Родни Дэнжерфилд[ 76 ] (Rodney Dangerfield) вычислительных систем: на него никто не обращает внимания. Всеобщий любимчик — процессор, а подсистема ввода-вывода рядом с ним — падчерица. Вот пример: когда надо охарактеризовать производительность компьютера чаще всего начинают считать мегагерцы. Создается впечатление, что сегодняшних разработчиков процессоров больше всего заботит максимум мегагерц, а не другие аспекты общей архитектуры. Между тем, пусть мегагерцы даже и показывают, как быстро «вертится» процессор, они все же мало что говорят о производительности вычислительной системы в целом.

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

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

Да и сам по себе ввод-вывод — важнейший компонент системы. В конце концов, без него Ваш мощнейший процессор будет просто бормотать что-то «внутри себя».

Что же такое подсистема ввода-вывода? Это группа аппаратных и программных компонентов, отвечающих за обработку ввода и доставку вывода на различные устройства, подключенные к системе. Всякий раз, когда Вам нужен некий системный ресурс, — например, требуется прочитать или записать файл, запросить выполнение программы, вызвать другой системный объект, создать или уничтожить объект, поработать с каким-либо устройством — и этого ресурса еще нет в памяти, компьютер должен обратиться к системе ввода-вывода, чтобы считать или записать, создать или удалить ресурс. Как я уже говорил, в компьютере мало что происходит без участия системы ввода-вывода.