Когда эта подпрограмма завершает свою работу, она вызывает С-процедуру, которая делает всю остальную работу для данного конкретного типа прерывания. (Мы предполагаем, что операционная система написана на языке С, который обычно и выбирается для всех настоящих операционных систем.) Возможно, когда работа этой процедуры будет завершена, какой-нибудь процесс переходит в состояние готовности к работе, и вызывается планировщик, чтобы определить, какой процесс будет выполняться следующим. После этого управление передается обратно коду, написанному на языке ассемблера, чтобы он загрузил для нового текущего процесса регистры и карту памяти и запустил выполнение этого процесса.
Режим многозадачности позволяет использовать центральный процессор более рационально. При грубой прикидке, если для среднестатистического процесса вычисления занимают лишь 20% времени его пребывания в памяти, то при пяти одновременно находящихся в памяти процессах центральный процессор будет загружен постоянно. Но в этой модели заложен абсолютно нереальный оптимизм, поскольку в ней заведомо предполагается, что все пять процессов никогда не будут одновременно находиться в ожидании окончания какого-нибудь процесса ввода-вывода.
Зачем нам нужна какая-то разновидность процесса внутри самого процесса? Необходимость в подобных мини-процессах, называемых потоками, обусловливается целым рядом причин. Рассмотрим некоторые из них. Основная причина использования потоков заключается в том, что во многих приложениях одновременно происходит несколько действий, часть которых может периодически быть заблокированной. Модель программирования упрощается за счет разделения такого приложения на несколько последовательных потоков, выполняемых в квазипараллельном режиме.
Если бы программа была рассчитана на работу только одного потока, то с начала создания резервной копии на диске и до его завершения игнорировались бы команды с клавиатуры или мыши. Пользователь ощущал бы это как слабую производительность. Можно было бы сделать так, чтобы события клавиатуры или мыши прерывали создание резервной копии на диске, позволяя достичь более высокой производительности, но это привело бы к сложной модели программирования, основанной на применении прерываний. Программная модель, использующая три потока, гораздо проще. Первый поток занят только взаимодействием с пользователем. Второй поток по необходимости занимается переформатированием документа. А третий поток периодически сбрасывает содержимое ОЗУ на диск.
До сих пор мы видели две возможные конструкции: многопоточныи веб-сервер и однопоточный веб-сервер. Представьте, что потоки недоступны, а системные программисты считают, что потери производительности при использовании одного потока недопустимы. Если доступна неблокирующая версия системного вызова ready то возможен и третий подход. При поступлении запроса его анализирует один-единственный поток. Если запрос может быть удовлетворен из кэша, то все в порядке, но если нет, то стартует неблокирующая дисковая операция.
