6. Синхронизация задач

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

1. Функции, выполняемые различны­ми задачами, связаны друг с другом. Одна из вариаций в этом случае – это когда задача при определенных условиях порождает одну или не­сколько новых задач.

2. Необходимо упорядочить доступ не­скольких задач к разделяемому ре­сурсу.

3. Необходима синхронизация задачи с внешними событиями. Как правило, для этого используется механизм прерываний.

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

7. Тестирование

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

8. Можно ли обойтись без ос рв?

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

9. Linux реального времени

У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы. Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения – RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему "жесткого" реального времени, а KURT (KU Real Time Linux) относится к системам "мягкого" реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

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

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

– загрузка CPU низка (DPC имеют достаточно времени);

– критическая работа делается на уровне DPC или на уровне ISR.

Но для жесткой СРВ использование Windows NT невозможно – система реального времени никогда не будет предсказуемой. Что следует изменить в Windows NT, чтобы ее можно было использовать в жестких СРВ?

a) Класс процессов реального времени должен иметь больше уровней.

б) Необходимо решить проблему инверсии приоритетов.

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

г) Система прерываний должна быть заменена целиком:

– DPC должны иметь много уровней приоритетов;

– DPC должны быть вытесняемыми более приоритетными DPC.

– драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC) ;

– драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC;

– должно быть известно время маскирования прерываний.