Операционные системы реального времени

И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко
Препринт Института системного программирования РАН

Назад Оглавление Вперёд

3.1. ITRON

ITRON (Industrial The Real-time Operating system Nucleus) – это широко распространенная в Японии операционная система для встроенных систем, которая используется в роботах, аппаратах факсимильной связи, цифровых камерах, а также в хостах разнообразных устройств [ITRON]. По сути, ITRON является открытым стандартом ОСРВ для встроенных систем. После создания в Японии спецификации µITRON (micro-ITRON) и быстро возросшей ее популярности корпорация Accelerated Technology (разработчик серии ОСРВ Nucleus с открытым исходным кодом) разработала ядро реального времени Nucleus µiPLUS, которое соответствует стандартам интерфейса µITRON, что позволяет переносить ранее созданные приложения, соответствующие этому стандарту, на широкий ряд процессоров, выполняющих Nucleus µiPLUS.

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

Несмотря на эту популярность, ОС ITRON имеет большой дефект. Широкие возможности по модификации ОС ITRON, данные разработчикам для того, чтобы они могли подогнать спецификации ядра под свои требования, основано на концепции “слабой стандартизации”. Слабая стандартизация приводит к большим трудностям в создании унифицированной среды разработки ОС ITRON.

При проектировании спецификаций ITRON учитывались следующие технические требования к спецификациям ОСРВ для встроенных систем:

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

Чтобы спецификации ITRON удовлетворяли этим требованиям, они проектировались в соответствии со следующими принципами:

• Увеличить адаптируемость к аппаратуре, избегая чрезмерной виртуализации аппаратуры. Адаптация к аппаратуре означает изменение спецификаций ОСРВ и внутренних реализационных методов, приводящее к возрастанию производительности всей системы в целом. Более точно, спецификации ITRON вводят явное разграничение между аспектами, которые следует стандартизовать через аппаратную архитектуру, и вопросами, которые должны быть решены оптимально на основе природы аппаратуры и ее производительности. Среди аспектов, которые стандартизуются, выделяются правила планирования задач; имена и функции системных вызовов; имена, порядок и значение параметров; имена и значения кодов ошибок. Во всех других вопросах стандартизация и виртуализация не проводится, т.к. это может привести к снижению производительности во время выполнения. Это относится к размеру параметра в битах и методам, стартующим обработку прерываний, – такие вопросы решаются отдельно для каждой реализации.
• Учитывать адаптируемость к приложениям. Адаптация к приложению означает изменение спецификаций ядра и внутренних реализационных методов, которые опираются на функции ядра и производительность, требуемую приложением, с целью повышения производительности всей системы в целом. В случае встроенной системы объектный код ОС генерируется отдельно для каждого приложения; таким образом, адаптация к приложению работает особенно хорошо (рис. 13). При проектировании спецификаций ITRON такая адаптация сопровождается обеспечением независимости функций ядра друг от друга, насколько это возможно, тем самым, разрешая каждому приложению выбрать только те функции, которые ему необходимы. На практике это выражается в том, что большинство µITRON-спецификационных ядер поставляются в библиотечном формате. Каждый системный вызов обеспечивается единственной функцией, что позволяет легко встраивать только необходимые функции.
• Обеспечить простоту обучения разработчика программного обеспечения. В спецификациях ITRON стандартизация применяется как способ облегчения приобретения разработчиками необходимых навыков. Согласованность в использовании терминологии, именования системных вызовов и удобная справочная система гарантируют быстрое усвоение основных положений и широкое применение их впоследствии. Возможен и другой способ обучения – на основе изучения текстовых материалов.
• Организация спецификаций в серии и разделение на уровни. Чтобы обеспечить адаптацию к широкому многообразию аппаратуры, спецификации организуются в серии и подразделяются на уровни. Например, спецификация µITRON (версия 2.0) была создана, главным образом, для использования в системах с 8- или 16-битовых MCU, в то время как спецификация ITRON2 предназначена для 32-битовых процессоров. Каждая спецификация далее разбивается на уровни, основанные на степени востребованности каждой функции. При реализации ядра соответствующий уровень выбирается на основе предназначения приложений и требуемых для них функций. Последняя реализованная спецификация µITRON3.0 подразделяет системные вызовы на три уровня, что дает возможность одной этой спецификацией покрывать диапазон от маломасштабных до крупных процессоров. Спецификации для распределенных и многопроцессорных систем также могут быть стандартизованы с помощью серий ITRON-спецификаций.
• Обеспечивать широкий набор функциональных возможностей. Примитивы ядра не ограничиваются малым количеством функций, напротив, они покрывают широкий диапазон разнообразных возможностей. Выбирая примитивы, которые хорошо подходят для данного типа приложения и аппаратуры, системные разработчики смогут быстро и легко создавать программы, обеспечивающие высокую производительность времени выполнения.

Из доступных версий спецификаций ITRON самой последней является спецификация µITRON4.0. Рассмотрим ее более подробно.

Под термином “задача” в системе ITRON понимается единица параллельной обработки. Переключение выполнения с одной задачи на другую называется диспетчеризацией. Процесс выбора следующей задачи для выполнения называется планированием.

Рис. 13. Адаптация в спецификации µITRON.

Для описания состояния задач система ITRON оперирует следующими понятиями:

• Выполняющаяся (running),
• Готовая к выполнению (ready),
• Блокированная (bloked)
• Ждущая (waiting) – ожидается выполнение каких-либо условий,
• Приостановленная (suspended) – остановлена другой задачей или самой собой,
• Ждущая-приостановленная (waiting-suspended) – ожидаются условия и приостановлена,
• Спящая (dormant) – еще не выполнялась или уже завершилась,
• Несуществующая (non-existent) – не существует в системе, или не создавалась, или уже уничтожена.

Планирование задач основано на приоритетах, присвоенных задачам, и является вытесняющим (preemptive). Совокупность задач с одинаковым приоритетом обслуживается по принципу – “первый пришел, первым обслужен” (FCFS – first come, first served).

Управление задачами. Функции управления задачами включают создание и уничтожение задачи, активацию и завершение задачи, отмену запросов на активацию и получение информации о состоянии задачи. Задача является объектом с уникальным идентификатором (ID).

Обработка прерываний. В спецификации µITRON4.0 обработка внешних прерываний производится с помощью обработчиков прерываний (interrupt handlers) и программ обслуживания прерываний (interrupt service routines). Обработчики прерываний управляют устройствами IRC (Interrupt Request Controller) и зависят от архитектуры прерываний процессора. Они не могут быть перенесены на другие платформы без изменений. Программы обслуживания прерываний запускаются обработчиками прерываний; они были введены в спецификации µITRON4.0 для улучшения переносимости обработки прерываний.

Спецификация µITRON4.0 определяет интерфейсы приложения для регистрации обработчика прерываний и интерфейсы приложения для программы обслуживания прерываний. Реализация должна обеспечивать либо один набор интерфейсов, либо оба. Если обеспечиваются интерфейсы только для регистрации обработчика прерываний, ядро может обеспечить связующую программу для обработчика прерываний, которая включает процессы, запускающиеся до и после выполнения обработчика прерываний. Если обеспечиваются интерфейсы только для регистрации программы обслуживания прерываний, ядро должно обеспечить для этой программы обработчик прерываний. Поведение системы с использованием обоих интерфейсов определяется реализацией.

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

В спецификации µITRON4.0 существует два способа для указания прерывания – с помощью номера прерывания и через номер обработчика прерывания. К тому же программа обслуживания прерывания идентифицируется уникальным идентификатором объекта (ID).

Управление исключительными ситуациями. Спецификация µITRON4.0 определяет управление исключительными ситуациями центрального процессора (CPU) и функции управления исключительными ситуациями на уровне задач.

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

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

Функции управления исключительными ситуациями задачи используются для остановки нормального выполнения задачи и запуска ее программы обработки исключительной ситуации; эта программа которая выполняется в контексте данной задачи. После возвращения из этой программы будет продолжено прерванное выполнение задачи. Приложение может зарегистрировать для каждой задачи одну программу управления исключительными ситуациями.

Обработчик исключительных ситуаций CPU определяется реализацией, поскольку сильно зависит от архитектуры управления исключительными ситуациями и реализации ядра. Он не переносим на другие платформы.

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

• Читать контекст и системное состояние при возникновении исключительной ситуации CPU. Ядро должно обеспечивать метод ссылки к информации о системном состоянии.
• Читать ID задачи, в которой возникла исключительная ситуация CPU.
• Запросить управление исключительными ситуациями задачи.

Контекст и системное состояние. В спецификации µITRON4.0 ядро управляет выполнением следующих единиц обработки:

• Обработчики прерываний.
• Программы обслуживания прерываний.
• Обработчики временных событий.
• Обработчики исключительных ситуаций CPU.
• Программы расширенных сервисных вызовов.
• Задачи.
• Программы управления исключительными ситуациями задачи.

Обработчики прерываний и программы обслуживания прерываний выполняются в своих собственных независимых контекстах.

Обработчики временных событий запускаются по временному триггеру и выполняются в своих собственных независимых контекстах. Рассматриваются три вида обработчиков временных событий – циклические, аварийные и по переполнению.

Обработчики исключительных ситуаций CPU выполняются в независимом контексте, определяемом исключительной ситуацией CPU и контекстом, в котором возникла исключительная ситуация.

Программы расширенных сервисных вызовов регистрируются приложением и запускаются расширенными сервисными вызовами. Программа расширенного сервисного вызова выполняется в независимом контексте, определяемом расширенным сервисным вызовом и контекстом, из которого произошел этот вызов.

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

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

Порядок выполнения каждой единицы обработки специфицируется следующим образом:

1. Обработчики прерываний, обработчики временных событий, обработчики исключительных ситуаций CPU

2. Диспетчер (процесс ядра)

3. Задачи

Порядок предшествования в первой группе определяется реализацией. Относительное предшествование задач определяется с помощью правил планирования.

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

При атомарном выполнении сервисных вызовов их уровень предшествования является самым высоким. При ослаблении атомарности уровень предшествования сервисных вызовов становится реализационно-зависимым до тех пор, пока их он выше приоритета единицы обработки, вызвавшей эти сервисные вызовы.

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

Состояние CPU может быть блокированным или разблокированным. В спецификации µITRON4.0 блокированное состояние CPU рассматривается как состояние, независимое от прерываний и диспетчеризации задач. В блокированном состоянии CPU могут быть вызваны только несколько сервисных вызовов.

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

Состояние CPU после запуска обработчика прерывания является реализационно-зависимым. Однако то, каким образом можно попасть в разблокированное состояние, определяется реализацией обработчиков прерываний. В реализации определяется также и то, как можно корректно вернуться из обработчиков прерываний после того, как система перешла в разблокированное состояние. Поведение считается не определенным, если обработчики прерываний не делают возврат так, как специфицировано в реализации.

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

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

Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния CPU.

После запуска задачи система находится в разблокированном состоянии. После ее окончания система должна быть в разблокированном состоянии. Поведение считается не определенным, если задача закончилась, а система осталась в блокированном состоянии.

Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния CPU. Однако не специфицируется, в каком состоянии были запущены программы управления исключительными состояниями задачи. После возврата из программы состояние CPU остается тем же самым, как установлено программой.

Прерывания обычно (но не всегда) разрешены в разблокированном состоянии CPU.

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

Переход к запрещенному состоянию диспетчеризации называется “отключением диспетчеризации”, переход к разрешенному состоянию диспетчеризации называется “включением диспетчеризации”.

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

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

Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния диспетчеризации.

После запуска задачи систем находится в разрешенном состоянии диспетчеризации. После окончания задачи система должна быть в разрешенном состоянии диспетчеризации. Поведение считается не определенным, если задача заканчивается в запрещенном состоянии диспетчеризации.

Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния диспетчеризации.

Состояние диспетчеризации рассматривается независимо от состояния CPU.

В спецификации µITRON4.0 не существует сервисных вызовов в незадачном контексте, которые изменяют состояние диспетчеризации. Следовательно, невозможно изменить состояние диспетчеризации внутри обработчиков прерываний и временных событий, если это не обеспечивается реализационно-зависимым расширением. Эти правила распространяются и на обработчики исключительных ситуаций CPU, когда они выполняются в незадачном контексте.

Диспетчеризация не производится во время выполнения единицы обработки с более высоким уровнем предшествования, чем у диспетчера, в заблокированном состоянии CPU или в запрещенном состоянии диспетчеризации. Эти три состояния называются состоянием задержки диспетчеризации. Состояние задачи во время задержки диспетчеризации можно изменить только с помощью реализационно-зависимымых расширений. Такие расширения могут делать сервисные вызовы из незадачного контекста, что позволит перевести задачу из состояния “выполняющаяся” в состояние “приостановленная” или “спящая”. Кроме того, расширения могут позволять сервисным вызовам выводить задачу из состояния “приостановленная” в запрещенном состоянии диспетчеризации.

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

Сервисные вызовы классифицируются в следующие три категории:

• Сервисные вызовы для незадачных контекстов.
• Сервисные вызовы, которые могут быть вызваны из любых контекстов.
• Сервисные вызовы для задачных контекстов.

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

В спецификации µITRON4.0 специфицируется процедура инициализации системы, а также процедуры регистрации объектов и их уничтожения. Объект обладает уникальным идентификатором и регистрируется ядром с помощью статического вызова некоторого метода интерфейса приложения или сервисного вызова, которые создают этот объект.

В спецификации µITRON4.0 определяется формат написания на языке C следующих единиц обработки: программ обслуживания прерываний, обработчиков временных событий, программ расширенных сервисных вызовов, задач и программ управления исключительными ситуациями задачи. Однако не специфицируется формат написания единиц обработки на языке ассемблера. Формат для написания обработчиков прерываний, обработчиков исключительных ситуаций CPU и атрибутов объектов, которые используются для их регистрации в ядре, определяются реализацией и не определяется в спецификации µITRON4.0.

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

Назад Оглавление Вперёд