Архитектура встраиваемой ОС реального времени – CE 6.0

Производительность в реальном времени

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

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

Система реального времени является множеством всех системных элементов, оборудования, операционной системы, и приложений, которые все должны удовлетворять системным требованиям. Операционная система реального времени (ОСРВ) является одним из элементов этой системы.

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

Следующий список показывает возможности ядра, которые поддерживает CE, как ОСРВ:

• Поддержка до 32К процессов и 256 уровней приоритета потоков
• Поддержка обработки инверсии приоритета с наследованием приоритета
• Поддержка вложенных прерываний, чтобы гарантировать, что высокоприоритетные события не задерживаются
• Поддержка одно-миллисекундного тайминга системного импульса
• Дополнительные возможности тайминга и планирования выполнения потоков
• Поддержка семафоров

Ядро CE обеспечивает производительность реального времени за счет следующей конструкции ядра и драйверов:

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

Время ответа, показанное в таблице 6.4, было измерено и опубликовано для CE 5.0, а время для CE 6.0, как утверждается, будет таким же или немного лучше. Тестовая система включала следующие оборудование и программное обеспечение:

• Плата разработки Samsung SMDK2410
• 200 MHz ARM с кэшем 16
• Windows CE 5.0 с полным UI
• Выполнение видео WMV

Время в таблице 6.4 примерно в 10 раз быстрее, чем у Linux, согласно недавнему исследованию . Как видно на рисунке 6.10, эти времена цикла ответа на несколько порядков величины быстрее, чем можно обычно видеть у настольной ОС общего назначения Windows, и вполне укладывается в диапазон времени ответа строго определенную ОС реального времени.

Рис. 6.10. Измерение производительности CE в реальном времени. Категории реального времени Слабо (Soft) и Строго (Hard) основываются на исследовании OMAC, а времена ОС определяются без каких-либо расширений сторонних поставщиков для ОС реального времени

Примитивы синхронизации

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

Критические разделы являются структурами данных, размещенные приложением (часто статически размещенные), которые инициализируются перед использованием. Это означает, что ОС фактически не владеет "экземпляром объекта", и он не может совместно использоваться процессами. Критические разделы являются крайне эффективными, когда код обычно не должен блокироваться. В этом случае нет перехода в ядро, поэтому вовлекаются незначительные реальные накладные расходы. Если он не должен блокироваться, то критический раздел фактически разрешается в эквивалент мьютекса, поэтому не является таким эффективным, если ожидается много блокировок. Профилирование кода с помощью Kernel Tracker поможет увидеть, как ведет себя код в реальных условиях.

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

Состояние объекта семафора подает сигнал, когда его счетчик больше нуля, и не подает сигнал, когда его счетчик равен нулю. Параметр InitialCount функции CreateSemaphore() определяет начальное значение счетчика. Каждый раз, когда освобождается ожидающий поток в связи с сигналом о состоянии семафора, счетчик семафора уменьшается на единицу. Используйте функцию ReleaseSemaphore() для увеличения счетчика семафора на заданное значение. Счетчик никогда не может быть меньше нуля или больше значения, определенного параметром MaximumCount. Несколько процессов могут иметь указатели на один и тот же объект семафора, позволяя использовать объект для межпроцессной синхронизации. Для совместного использования объекта процесс может определить имя объекта семафора в вызове функции CreateSemaphore().

Объекты событий обычно используются для указания, что что-то произошло, в противоположность синхронизации доступа к общедоступному ресурсу. Начальное состояние объекта события определяется параметром InitialState. Используйте функцию SetEvent для задания состояния объекта события для сигнализации. Используйте функцию ResetEvent для сброса состояния объекта события в несигнализируемое. Когда сигнализируется состояние сброшенного вручную объекта события, оно остается сигнализирующим, пока не будет явно сброшено в несигнализируемое с помощью функции ResetEvent. Любое число ожидающих потоков, или потоков, которые в дальнейшем начинают операции ожидания для указанного объекта событий, могут освобождаться во время сигнализации состояния объекта. Когда сигнализируется состояние автоматически сброшенного объекта событий, он остается сигнализирующим, пока не будет освобожден одиночный ожидающий поток; система затем автоматически сбрасывает состояние в несигнализируемое. Если ожидающих потоков нет, то состояние объекта событий остается сигнализирующим. События могут быть также пульсирующими, что всегда будет сбрасывать объект событий снова в несигнализируемое состояние.

Состояние сброшенного вручную объекта событий, сигнализируемое функцией SetEvent,остается сигнализируемым, пока не будет явно задано как несигнализируемое состояние функцией ResetEvent. Все ожидающие потоки, или потоки, которые впоследствии начинают операции ожидания для указанного объекта событий, вызывая функции ожидания, будут освобождаться, пока сигнализируется состояние объекта. Состояние автоматически сбрасываемого объекта события, сигнализируемое функцией SetEvent, будет оставаться заданным, пока не будет освобожден одиночный ожидающий поток, когда он перейдет в несигнализируемый. Сбрасываемые вручную объекты событий, сигнализирующие функцией PulseEvent, освободят все ожидающие потоки и немедленно вернутся в несигнализирующее состояние. Автоматически сбрасываемый объект события, сигнализирующий функцией PulseEvent, освободит максимум один ожидающий поток, и немедленно переходит в несигнализирующий. Если ожидающих потоков нет, событие все равно перейдет в несигнализирующее, ничего не освобождая. Используйте функцию CloseHandle для закрытия указателя. Система закрывает указатель автоматически, когда процесс завершается. Объект события разрушается, когда будет закрыт его последний указатель.

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

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

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

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

Так как несколько процессов могут иметь указатели на один и тот же объект события или мьютекс, эти объекты можно использовать для выполнения межпроцессной синхронизации. Процесс, который создает объект, может использовать указатель, возвращаемый функцией CreateEvent или CreateMutex. Другие процессы могут открывать указатель на объект, используя имя объекта в другом вызове функций CreateEvent или CreateMutex. Именованные объекты предоставляют процессам способ совместного использования указателей объектов. После того как процесс создает именованное событие или объект мьютекса, другие процессы могут использовать это имя для вызова соответствующей функции, CreateEvent или CreateMutex, чтобы открыть указатель на этот объект.