Операционная среда

Время как системный ресурс

Главный системный ресурс, разделять который необходимо с наименьшей паразитной нагрузкой, - машинное время. Самый простой способ разделения времени - пакетное выполнение задач. Каждой задаче отводится некоторый промежуток машинного времени, в течение которого она обязана запуститься, отработать и завершиться. Если задача завершилась до истечения отведенного ей времени, запускается следующая. Если не успела завершиться, ее выполнение прерывается (навсегда), о чем пользователь получает уведомление, и опять-таки запускается следующая задача. Затраты на работу самой системы здесь минимальны (запустить, прервать), значит, почти все время будут работать пользовательские задачи. Казалось бы, большей эффективности добиться нельзя. В то же время для организации операционной среды этот способ крайне неудобен.

Во-первых, не все задачи одинаково занимают процессорное время. Многие потребляют временных ресурсов гораздо больше других: например, обмениваясь данными с медленными внешними устройствами. Такие задачи называют обменными, а задачи, загружающие в основном процессор, - счетными. И если бы было в системе средство дать процессору поработать, пока обменная задача ожидает окончания операции ввода/вывода, а также средство грамотно спланировать запуск этих задач, то эффективность системы возросла бы вдвое! Логику и политику планирования реализует планировщик задач (scheduler).

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

В самой упрощенной форме (за более подробными сведениями обращайтесь к [ 35 ] или [ 37 ] , здесь мы стараемся изложить лишь идею алгоритма) псевдопараллелизм выглядит так. Поскольку процессор на самом деле один (даже если не один, это ничего не меняет; другое дело, если бы процессоров было сколько угодно!), то и задача в каждый момент времени выполняется на нем одна. Но выполняется недолго, скажем, десятую долю секунды. После этого состояние задачи записывается куда-нибудь в системную память, а сама задача встает последней в очередь задач, готовых к выполнению. Вместо нее немножко работает первая задача в этой очереди, потом и с ней происходит то же самое, и т. д. Когда очередь опять доходит до исходной задачи, ее состояние восстанавливается и она продолжает работу как ни в чем не бывало. Состоянием (или контекстом ) задачи называется информация, необходимая для того, чтобы задача продолжала работать как ни в чем не бывало: значение регистров процессора, место, где было прервано выполнение, собственные часы, табличка использования оперативной памяти и пр. Практически все компьютерные архитектуры имеют встроенные команды процессора, позволяющие аппаратно сохранять и восстанавливать контекст задачи .

Виртуальная память

Еще один механизм, обычно тоже реализованный аппаратно, связан с распределением памяти между задачами и называется механизмом виртуальной памяти (см. [ 38 ] или [ 6 ] ). Суть его в том, что оперативная память, заказанная любой задачей у системы на разных этапах работы (допустим, 8 Мбайт в сумме), доступна этой задаче по непрерывным адресам, начиная с 0 и заканчивая границей заказанного объема (последним адресом 8 Мбайт, 8388607). Это означает, что каждая задача использует свое адресное пространство, и адрес 0 в памяти одной задачи не соответствует адресу 0 в памяти другой. Если задаче потребуется еще 4 Мб, то этот кусок памяти будет адресоваться с 8388608 до 12582911. При этом, поскольку "настоящая", физическая оперативная память на всех одна, последний кусок в ней может располагаться совсем не рядом с первым. Физические адреса входящих в него ячеек памяти будут, конечно, совсем другими. Предыдущие 8 Мбайт тоже могут состоять из нескольких кусков, разбросанных по физической памяти.

Делается это с помощью таблиц преобразования адресов (они входят в контекст процесса), в которых написано, какого размера страницы памяти выделены этой задаче и где они на самом деле лежат. Механизм виртуальной памяти предполагает, что центральный процессор умеет работать в двух режимах: в режиме пользователя (user mode), когда вся адресация идет через таблицу преобразования, и в режиме супервизора (или режиме ядра, supervisor или kernel mode), когда вся адресация идет напрямую. Кроме того, только в режиме супервизора разрешены команды процессора, работающие с этими табличками, а также некоторые другие. Таким образом, задачи не могут изменить память друг друга, потому что не имеют даже способа выйти за пределы собственного виртуального адресного пространства.