Основы AS/400
Шрифт:
Однако такое решение усложняет введение новых или изменение существующих элементов структуры — мешает монолитность конструкции. Иерархия слоев объединяет систему в единое целое. Нелегко вынуть один слой и заменить его новым, так как интерфейсов между слоями много, и они разные. Так что изменения требуют глубокого знания ОС и массы времени. Кроме того, многие 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 мы пытались определить механизм, с помощью которого ОС смогла бы выполнять свою основную обязанность — распределять работы и ресурсы
Развитие процессоров в течение 60-х годов шло довольно бурно. И все же в те дни процессоры ничего не «знали» о процессах, а «понимали» только прерывания. Прерывание — это изменение нормальной последовательности исполнения команд, вызванное либо ошибкой команды, либо чем-то за пределами исполняющейся программы, обычно вводом-выводом. Процессор запускал операцию ввода-вывода, которая затем выполнялась без его участия. Когда ввод-вывод завершался, нужно было как-то сообщить эту информацию процессору, и в качестве такого механизма использовались прерывания.
Прерывание останавливает исполняющуюся программу и передает управление обработчику прерываний, который предпринимает нужные действия. После этого управление возвращается прерванной программе. Обработчик прерываний обязан возобновить исполнение прерванной программы в точности с того же момента, на котором оно было прервано. Это означает возвращение всех внутренних регистров в состояние, предшествовавшее прерыванию. Некоторые процессоры имеют несколько наборов регистров, и при возникновении прерывания обработчик использует другой набор. Возвращение управления прерванной программе подразумевает переключение обратно на старый набор регистров.
Большинство схем обработки прерываний используют идею приоритета. Приоритет располагает прерывания в порядке их важности, от наиболее к наименее важным. При возникновении прерывания процессор переключается на другую программу только в том случае, если эта программа приоритетней той, что исполняется в данный момент. Большинство процессоров поддерживают ограниченное число приоритетов прерываний. Для поддержки процессов ПО ОС использует механизм прерываний и надстраивает над ним процессы.
В 70-х годах, работая над новым микропрограммируемым процессором для System/38, мы надеялись, что, построив структуру процессов непосредственно над аппаратурой и устранив некоторые накладные расходы прерываний, сможем достичь высокой эффективности системы. Такая структура процессов могла бы использоваться даже вводом-выводом без отдельного механизма прерываний. Это также сократило бы число схем процессора — цель, близкая и дорогая сердцу каждого разработчика. Фактически, нужно было создать структуру процессов системы и написать для ее поддержки микрокод.
Но попытки объяснить кому-либо из инженеров-аппаратчиков, что мы делаем, давали весьма интересные результаты.
Я очень хорошо помню одну такую дискуссию с техническим менеджером Реем Клотцем и его подчиненными. Я объяснял, что благодаря новой структуре мы не будем ограничены лишь несколькими уровнями прерываний. Мы сможем поддерживать сотни процессов, каждый из которых будет иметь свой уровень приоритета. При желании, даже каждое устройство ввода-вывода может иметь свой собственный приоритет, так как наша система будет поддерживать множественные процессы. Рэй прервал меня вопросом: