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

Требование 1. ОС должна быть многопоточной (multi-threaded) и прерываемой.

Как указывалось выше, ОСРВ должна быть предсказуемой, что означает максимальное время выполнения того или иного действия, которое должно быть известно заранее и должно соответствовать требованиям приложения.

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

Требование 2. Должно существовать понятие приоритета потока.

Проблема в том, чтобы определить, какой задаче требуется ресурс. В идеальной ситуации ОСРВ отдаёт ресурс потоку или драйверу с ближайшим крайним сроком (так называемые ОС, управляемые временным ограничением (deadline driven OS)).

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

Требование 3. ОС должна обеспечивать предсказуемые механизмы синхронизации задач.

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

Требование 4. Должна существовать система наследования приоритетов.

На самом деле, именно этот механизм синхронизации и тот факт, что различные потоки используют одно и то же пространство памяти, отличают потоки от процессов. Процессы не разделяют одно и то же пространство памяти. Так, например, старые версии UNIX не являются многопоточными. Старый UNIX –многозадачная ОС, где задачами являются процессы, которые сообщаются через потоки (PIPEZ) и разделяемую память. Оба эти механизма используют файловую систему, а её поведение непредсказуемо.

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

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

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

Требование 5. Поведение ОС должно быть известно.

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

• Латентную задержку прерывания (т.е. время от момента прерывания до момента запуска задачи): она должна быть предсказуема и согласована с требованиями приложения. Эта величина зависит от числа одновременно «висящих» прерываний.

• Максимальное время выполнения каждого системного вызова (должно быть предсказуемым и независимым от числа объектов в системе).

• Максимальное время маскирования прерываний драйверами и ОС.

• Системные уровни прерываний.

• Уровни прерываний драйверов устройств, их временные характеристики и так далее.

Когда все указанные характеристики ОС известны, можно представить разработку СРВ на её базе с учётом возможностей выбранной ОСРВ и аппаратуры.