4. Необходимые требования к операционной системе реального времени для обеспечения предсказуемости

Мы определяем ОСРВ как ОС, которая может использоваться для построения жесткой СРВ.

Жесткие или мягкие системы не существуют!

Часто путают понятия СРВ и ОСРВ, а также неправильно используют атрибуты "мягкая" и "жесткая". Иногда говорят, что та или иная ОСРВ мягкая или жесткая. Нет мягких или жестких ОСРВ. ОСРВ может только служить основой для построения мягкой или жесткой СРВ. Сама по себе ОСРВ не препятствует тому, что ваша СРВ будет мягкой. Например, если вы решили создать СРВ, которая должна работать через Ethernet по протоколу TCP/IP. Такая система не может быть жесткой СРВ, поскольку сама сеть Ethernet непредсказуема. Разумеется, если вы решили создать приложение на базе ОС вроде Windows 3.11, ваша система никогда не будет жесткой СРВ, ибо поведение самой "ОС" никоим образом не является предсказуемым.

Требование 1.Операционная система реального времени должна быть много потоковой (multi-threading) и допускать вытеснение (preemtible-прерываемой).

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

Как указывалось выше, ОСРВ должна быть предсказуемой. Это означает не то, что ОСРВ должна быть быстрой, а то, что максимальное время выполнения того или иного действия должно быть известно заранее и должно соответствовать требованиям приложения. ОС Windows 3.11 даже на Pentium PRO 200 MHz бесполезна для ОСРВ, ибо одно приложение может захватить управление и заблокировать систему для остальных. Первое требование состоит в том, что ОС должна быть многонитевой на принципе абсолютного приоритета (прерываемой). То есть, планировщик должен иметь возможность прервать любую нить и предоставить ресурс ните, которой он более необходим. ОС (и аппаратура) должны также обеспечивать прерывания на уровне обработки прерываний

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

Основная сложность диспетчеризации заключается в том, чтобы обнаружить, какая именно поток нуждается в ресурсах в первую очередь. В идеале операционная система реального времени предоставляет ресурсы той нити или драйверу, которым осталось меньше всего времени до установленного срока (алгоритм, известный как EDF – Earliest Deadline First). Чтобы сделать это, ОС должна знать, когда нить обязана завершить свою работу и сколько времени ей понадобится. Поскольку это очень трудно реализовать, таких ОС пока еще не существует. Поэтому механизм диспетчеризации потоков управления в современных ОС базируется на понятии приоритета: ресурсы предоставляются нити с наивысшим приоритетом, при условии поддержки достаточно большого количества уровней приоритетов;

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

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

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

Механизм захвата ресурсов и меж нитевых (потоковых) связей необходим, поскольку нити разделяют общие ресурсы.

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

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

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

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

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

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

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

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

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

Разработчик систем реального времени должен знать, сколько времени затрачивается на ту или иную системную работу. Кроме того, должны быть известны уровни системных прерываний и уровни IRQ (линий запросов прерываний) драйверов устройств, максимальное время, которое они затрачивают и т.п.

Поведение самой ОС после системных вызовов и наступления событий должно быть предсказуемо и известно заранее. Это означает, что разработчики ОС должны специфицировать такие временные характеристики, как «задержка обработки прерывания» (interrupt latency), максимальное время маскировки прерываний а также максимальное время исполнения всех системных вызовов.

Аппаратная архитектура должна поддерживать несколько уровней прерываний (interrupt levels) а ОС должна обеспечивать вытеснение (preemption) обработчиков прерываний;

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

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

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

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

Следующие пункты также должны быть известны разработчику:

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

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

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

механизма межпроцессорных связей (IPC).

21