Термин «операционная система реального времени» в последние годы стал употребляемым с такой лёгкостью, что уже приобретает некоторый оттенок неприличия. Свою операционную систему как «реал-тайм» не пропагандирует только крайне ленивый. При подготовке этого материала я «ради смеха» задал для поиска «операционная система реального времени» поисковой системе www.yandex.ru: 7867 страниц на «не менее чем» на 233 серверах.
Тем не менее, технические требования к системам реального времени «в строгом смысле» достаточно хорошо исследованы. Вот некоторые формулировки, которые я позаимствовал из разных источников:
«Система должна обеспечивать гарантированный отклик в гарантированное время» [1].
«Система должна обладать способностью к параллельной обработке нескольких событий. Если несколько событий наступают одновременно, система должна успеть обработать все события в соответствующих каждому событию временных рамках, независимо от количества событий, порядка их поступления и соотношения их временных рамок» [1].
«ОС должна поддерживать вытесняющую многопоточность (preemptive multi-threading) и мультипроцессорные архитектуры» [4].
«Поведение самой ОС после системных вызовов и наступления событий должно быть предсказуемо и известно заранее. Это означает, что разработчики ОС должны специфицировать такие временные характеристики, как «задержка обработки прерывания» (interrupt latency), максимальное время маскировки прерываний а также максимальное время исполнения всех системных вызовов» [4].
Показатели и требования систем реального времени — это сама по себе огромная и неисчерпаемая тема для рассмотрения, и мы не станем сейчас ею заниматься. Я привёл эти формулировки для того, чтобы стало понятнее: само понятие «реального времени» и его критерии оценки — как на фундаменте зиждется на службах времени операционной системы: измерении и задании временных интервалов системы в шкале текущего времени. Ведь нельзя рассуждать о сущностях, которые с необходимой достоверностью не умеешь измерять!
Собственно в этих заметках мы и займёмся изучением того, какие способы программного задания, измерения и контроля временных интервалов доступны в операционной системе QNX, и какие точности и дискретности измерения временных параметров можно ожидать в QNX.
Фиксация временных интервалов (тайм-ауты, тайм-ауты ядра, интервальные таймеры и др.) и хронометраж выполнения участков кода для OS «жёсткого реального времени» QNX RTP на порядок более критичны, чем для универсальных OS общего применения (например, все системы семейства Windows, а все рассуждения об Windows NT и производных от неё как системе реального времени, я бы склонен был рассматривать как не очень удачный каламбур).
Для детальное понимание функционирования служб времени в QNX требуется тщательно рассмотреть:
Задание любых временных интервалов с использованием функций sleep(), usleep(), nanosleep(), delay(), alarm(), select(), nanospin(), sigaction() — я сознательно привожу максимально полный перечень «временных» функций, как подсказку по их использованию;
Все механизмы и функции, связанные с созданием и использованием интервальных таймеров: все функции группы timer_*();
Измерение временных характеристик выполнения (хронометрирование) критических участков программного кода — clock(), time(), times() и др.;