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

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

В спецификации µ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.