Правда и вымысел об операционных системах Linux реального времени

Операционные системы реального времени (ОСРВ) — это ОС, гарантирующая выполнение задачи в течение заданного интервала времени. Правильность вычислений в ОСРВ определяется не только логической корректностью результата, но и временем выполнения. Так, при выполнении операции «2+2» система должна не просто выдать «4», а успеть сделать это в течение установленного интервала времени, например 20 мкс. Иначе результат не считается верным, а в системе происходит сбой или отказ.
В качестве аналогии можно привести систему безопасности в автомобиле. В аварийной ситуации должна сработать подушка безопасности, причем в течение, скажем, 0,5 с, иначе она все равно не успеет спасти жизнь пассажиру.
Главная характеристика ОСРВ — задержка. Задержка — это промежуток времени между воздействием и реакцией на него. Существует несколько видов задержек:
1) Задержка прерывания (interrupt latency) — время, которое проходит с момента генерации прерывания до запуска соответствующей подпрограммы обработки прерывания.
2) Задержка планировщика (scheduling latency) — промежуток времени между «пробуждением» (воздействием), возвещающим о том, что событие произошло, и моментом, когда у планировщика появляется возможность запланировать выполнение соответствующего потока, который ожидает это событие. Воздействие может быть вызвано аппаратным прерыванием или другими потоками. Задержку планировщика часто называют задержкой реакции (task-response latency) или задержкой диспетчеризации (dispatch latency). Нередко при планировании происходит перераспределение приоритетов и может возникнуть инверсия приоритетов — ситуация, когда какая-либо задача вытесняется другими, изначально имеющими более низкий приоритет.
3) Задержка для худшего случая (worst-case latency) — это наибольшее время, которое может пройти до наступления ожидаемого события. Этот термин имеет отношение к случаю, когда система загружена. В системах реального времени необходимо предусмотреть не только средние параметры, но и наихудшие сценарии. Вспоминая аналогию с системой безопасности автомобиля, 0,5 с — это как раз наихудший случай. При нормальных условиях подушка срабатывает за 0,2 с. Однако в случае перегрузки системы выброс подушки должен быть произведен по крайней мере через 0,5 с.

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

Как было сказано выше, ОСРВ не всегда имеют высокое быстродействие. И не всегда выбор в сторону ОСРВ обоснован. Правильнее сказать, что в подавляющем большинстве случаев встраиваемые приложения не требуют жесткой ОСРВ. В конечном счете это зависит от наличия специфических требований и скрытых инструкций. Чтобы понять, нужна ли ОСРВ в конкретной системе, необходимо ответить на следующие вопросы:
1) Какие требуются задержки? Какова максимальная задержка, которую может выждать приложение, не вызвав сбой в системе?
2) Выполняет ли приложение жизненно важные задачи? Другими словами, должно ли приложение успеть выполнить задачу в течение определенного срока, по истечении которого эта задача потеряет смысл? Например, подушка безопасности в автомобиле должна успеть сработать в течение 0,5 с, иначе она все равно не спасет жизнь пассажиру.
3) Должна ли система обрабатывать абсолютно все поступающие данные, или же некоторые из них могут остаться необработанными?
4) Зависит ли работа приложения от внешнего устройства, которое должно ответить в течение отведенного интервала, по истечении которого произойдет сбой системы?
В таблице 1 приведены примеры использования мягких и жестких ОСРВ.

Изначально Linux разрабатывалась как ОС общего назначения. Однако впоследствии появились и версии, работающие в реальном времени. Это, например, RTLinux (Wind River), Xenomai, RTAI, RT Preemption Patch и т.д.
Чтобы адаптировать ядро Linux к работе в реальном времени, можно пойти двумя путями:
А) преобразовать схему вытеснений, или приоритетного прерывания обслуживания ядра (kernel preemption);
Б) ввести еще один программный уровень, то есть дополнительное ядро, внутри или параллельно существующему ядру Linux.
Детальное обсуждение различных видов ОСРВ на базе Linux выходит за рамки статьи. Однако следует отметить, что перечисленные выше ОСРВ Linux, за исключением RT Preemption (патч PREEMPT_RT), основаны главным образом на втором подходе. Мы же рассмотрим первый на примере патча PREEMPT_RT.

Одно из самых важных достоинств этого подхода заключается в том, что в нем используются те же интерфейсы API, что и в ядре общего назначения. Разработчики, как и раньше, могут использовать существующие POSIX совместимые API. Во втором подходе — наоборот, переход на новый интерфейс является обязательным условием.
Патч PREEMPT_RT вносит ряд изменений в базовое ядро Linux. Во-первых, он преобразует все ISR (Interrupt Service Routines) в потоки, называемые «Threads Interrupt Service Routines». Во-вторых, заменяет принцип синхронизации spinlock на семафорный механизм (mutex), который поддерживает наследование приоритетов и вытеснение.
Кроме того, он добавляет поддержку режима High Resolution Timer (HRT), что позволяет таймерам работать с разрешением 1 мкс. И последнее, он обеспечивает защиту от возникновения неограниченной инверсии приоритетов.

Вокруг этого вопроса ведется долгая дискуссия. Попробуем разобраться, в чем дело.
Когда ядро Linux скачивается с официального сайта, www.kernel.org, или покупается у посредников, таких как Debian, Fedora, Ubuntu и др., тогда оно не является ядром реального времени в полном смысле. Однако оно может быть настроено так, чтобы удовлетворить требованиям к мягким ОСРВ. Для этого необходимо включить опцию «Preemptible Kernel» (PREEMPT_DESKTOP) в меню настроек.
Если же в приложении требуется жесткая ОСРВ, то можно воспользоваться патчем PREEMPT_RT компании Ingo Molnar (входит в состав группы Red Hat http://www.rhd.ru/), чтобы переконфигурировать ядро на работу в жестком реальном времени. Этот патч наделяет базовое ядро способностью приостанавливать или прекращать выполнение задачи с низким приоритетом, чтобы выполнить более высокоприоритетную задачу. В настоящее время он не включен в набор базовых компонентов, однако этот вопрос рассматривается.
Таким образом, Linux нельзя отнести к жесткой или мягкой ОСРВ в силу ее гибкости. Согласно Building Embedded Linux Systems, «для большинства приложений, где требуется детерминизм, Linux с PREEMPT_RT вполне подходит. Однако в тех случаях, когда требуется больше, чем просто малые задержки, его недостаточно».

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