Мультипрограммность и мультизадачность

Требование 1.Операционная система должна быть мультипрограммной и мульти­задачной (многопоточной — multi-threaded), а также активно использовать преры­вания для диспетчеризации. Как указывалось выше, ОСРВ должна быть предска­зуемой. Это означает не то, что ОСРВ должна быть быстрой, а то, что максимальное время выполнения того или иного действия должно быть известно заранее и соот­ветствовать требованиям приложения. Так, например, система Windows 3.11 даже на Pentium IV с частотой более 3000 МГц не может функционировать в качестве ОСРВ, ибо одно приложение может практически монопольно захватить централь­ный процессор и заблокировать систему для остальных вычислений.

В соответствии с первым требованием операционная система должна быть много­поточной на принципе абсолютного приоритета (прерываемой). То есть плани­ровщик должен иметь возможность прервать любой поток выполнения и предо­ставить ресурс тому потоку, которому он более необходим. Операционная система (и аппаратура) должна также обеспечивать прерывания на уровне обработки пре­рываний.

Приоритеты задач

Требование 2.Должно существовать понятие приоритета потока (задачи). Пробле­ма в том, чтобы определить, какой задаче ресурс требуется более всего. В идеальной ситуации ОСРВ отдает ресурс потоку или драйверу с ближайшим крайним сроком, что называется управлением временным ограничением (DeadLine DrivenOS). Что­бы реализовать это временное ограничение, операционная система должна знать, сколько времени требуется каждому из выполняющихся потоков для завершения. Операционных систем, построенных по этому принципу, практически нет, так как он слишком сложен для реализации. Поэтому разработчики операционных систем принимают иную точку зрения: вводится понятие уровня приоритета для задачи,

Требования к операционным системам реального времени____________________ 295

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

Наследование приоритетов

Требование 3.Должна существовать система наследования приоритетов. На са­мом деле именно этот механизм синхронизации и тот факт, что различные потоки выполнения используют одно и то же пространство памяти, отличают их от про­цессов. Как мы уже знаем, процессы не разделяют одно и то же пространство памя­ти. Так, например, старые версии UNIX не являются многопоточными. «Старая» UNIX — многозадачная ОС, где задачами являются процессы (а не потоки), кото­рые сообщаются через каналы связи (pipes) и разделяемую память. Оба этих меха­низма используют файловую систему, а ее поведение непредсказуемо.

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

Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приори­тета, то есть повышение уровня приоритета потока до уровня потока, который его вызывает. Наследование означает, что блокирующий ресурс поток наследует при­оритет потока, который он блокирует (разумеется, это справедливо лишь в том случае, если блокируемый поток имеет более высокий приоритет).

Иногда можно услышать утверждение, что в грамотно спроектированной системе такая проблема не возникает. В случае сложных систем с этим нельзя согласиться. Единственный способ решения этой проблемы состоит в увеличении приоритета потока «вручную» прежде, чем ресурс окажется заблокированным. Разумеется, это возможно в случае, когда два потока разных приоритетов претендуют на один ре­сурс. В общем случае решения не существует.