Управление процессами

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

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

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

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

Лучшая в мире структура задач

Конкурентоспособность вычислительной системы часто достигается лишь благодаря нескольким базовым идеям. Идеи, принесшие заслуженную славу AS/400 — это независимость от технологии, обеспечиваемая MI, и высокая производительность, поддерживаемая одноуровневой памятью. Но есть столь же важные, хотя намного менее известные находки разработчиков. Одна из них — структура задач AS/400, которая пока еще так широко не обсуждалась.

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

Наиболее важным был Патент США № 4 177 513, защищавший структуру задач System/38 и AS/400^{1Ни одноуровневая память, ни независимость от технологии запатентованы не были. — Прим. консультанта.}.

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

Технологии микроядра

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

Чтобы лучше понять схему взаимодействия на основе передачи сообщений, рассмотрим кратко, как традиционно осуществлялось взаимодействие в ОС. Отличным примером может служить ОС Unix.

И первоначальная версия Unix, и большинство современных ее вариантов используют слоеную архитектуру. Группы функций ОС, такие как файловая подсистема, подсистема управления процессами и подсистема ввода-вывода, разделены в ней на слои. Само по себе подобное деление не так уж необычно: большинство ОС, включая ОС AS/400, состоят из слоев ПО. Различия между ОС заключаются в способах обмена информацией и взаимодействия между слоями. В системах Unix каждый слой взаимодействует только со слоями, расположенными непосредственно под и над ним. Преимущество такой структуры, на первый взгляд, очевидно: каждый слой "знает" только непосредственных "соседей" снизу и сверху; запросы и отклики передаются от слоя к слою вверх и вниз, как по лестнице. Именно таким образом приложения и сама ОС взаимодействуют с различными компонентами. Такой подход хорошо работает. Лучшее доказательство тому — число Unix-подобных ОС, доживших до сегодняшних дней.

Однако такое решение усложняет введение новых или изменение существующих элементов структуры — мешает монолитность конструкции. Иерархия слоев объединяет систему в единое целое. Нелегко вынуть один слой и заменить его новым, так как интерфейсов между слоями много, и они разные. Так что изменения требуют глубокого знания ОС и массы времени. Кроме того, многие API между слоями не документированы, что ставит под вопрос корректность работы кода после внесения изменений. То есть добавить новые функции или перенести их с одного уровня на другой становится настоящей проблемой.

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

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

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

История микроядра началась в середине 80х в Университете Карнеги-Меллон с разработки микроядра Mach. Технологию микроядра используют многие ОС, созданные в последние годы, например, Windows NT, но впервые она появилась в System/38, а затем — в AS/400.

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

Начинаем снизу

Ранее мы определили процесс как единицу работы в системе. То же самое можно сказать и о задаче. Но по сравнению с задачей, процесс в SLIC — понятие более высокого уровня, он построен над задачей. Имеется и третья, еще более значимая единица работы в OS/400, называемая заданием. Мы увидим далее, как связаны между собой эти три единицы работы в AS/400.

Термины "задача" и "процесс" появились в двух разных проектных группах System/38. Инженеры говорили о задачах, а программисты — о процессах. Многие полагали, что поскольку имена разные, то ими обозначают фундаментально разные понятия, но это не так.

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

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

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

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

В 70-х годах, работая над новым микропрограммируемым процессором для System/38, мы надеялись, что, построив структуру процессов непосредственно над аппаратурой и устранив некоторые накладные расходы прерываний, сможем достичь высокой эффективности системы. Такая структура процессов могла бы использовать ся даже вводомвыводом без отдельного механизма прерываний. Это также сократило бы число схем процессора — цель, близкая и дорогая сердцу каждого разработчика. Фактически, нужно было создать структуру процессов системы и написать для ее поддержки микрокод.