Что делает ядро/ОС в режиме реального времени?

Проведя небольшое исследование, пообщавшись с людьми (Джейми Ханрахан, Юха Аалтонен @linkedIn Group — эксперты по драйверам устройств) и, конечно же, посоветовавшись с @Jim Garrison, я могу сделать следующий вывод:

По словам Джейми Ханрахана,

Что делает ядро ​​реального времени?
обязательное условие ОС реального времени —

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

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

• Планировщик реального времени предлагает полностью предсказуемое (для разработчика) поведение при планировании потоков — "какой поток запускается следующим".

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

Итак, хорошо иметь гарантированную задержку для прерывания и предсказуемость планирования потоков, тогда почему бы не сделать каждую ОС в режиме реального времени?

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

  Например, планировщик реального времени должен иметь полностью предсказуемое поведение. Это означает, среди прочего, что какие бы приоритеты ни были назначены различным задачам разработчиком, ОС должна оставить их в покое. Это может означать, что некоторые низкоприоритетные задачи в конечном итоге не выполняются в течение длительного периода времени. Но ОС RT должна пожать плечами и сказать: «Это то, чего хотел разработчик». Обратите внимание: чтобы получить правильное поведение, разработчик системы RT должен много беспокоиться о таких вещах, как приоритеты задач и сходство ЦП.

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

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

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

Может ли ядро ​​работать в режиме реального времени только потому, что оно имеет планировщик реального времени?

• Нет, планировщик RT является необходимым компонентом ОС RT, но вам также необходимо предсказуемое поведение в других частях ОС.

Требуется ли какая-либо аппаратная поддержка?

• В общем, чем проще оборудование, тем более предсказуемо его поведение. Таким образом, PCI-E менее предсказуем, чем PCI, а PCI менее предсказуем, чем ISA и т. д. Существуют специальные шины ввода-вывода, которые были разработаны (помимо прочего) для легкой предсказуемости, например. задержка прерывания, но многие требования R-T в наши дни могут быть удовлетворены с помощью стандартного оборудования.

Конкретное описание реального времени состоит в том, что процессы имеют гарантии минимального времени отклика. Этого часто недостаточно для приложения и даже менее важно, чем детерминизм. Этого особенно трудно достичь с современными многофункциональными ОС. Рассмотреть возможность:

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

Серьезная проблема заключается не в том, что время t не равно точно половине секунды, а в том, что нельзя заранее знать, насколько оно больше. Эта неточность не постоянна и не детерминирована.

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