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

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

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

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

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

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

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

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

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

Но попытки объяснить кому-либо из инженеров-аппаратчиков, что мы делаем, давали весьма интересные результаты.

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

Вы хотите сказать, что разрабатываете мультипроцессор?

Нет, — ответил я, — мы строим систему для поддержки множественных процессов, а не множественных процессоров.

В чем же разница?

Процесс — это то же самое, что и задача, — сказал я, а затем повторил, — Мы строим систему для поддержки множественных задач, а не множественных аппаратных процессоров. После краткого молчания Рэй поинтересовался:

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