Можно ли обойтись без ОС РВ?

Как любую вычислительную систему можно создать только из элементов 2И-НЕ, так и все, что может делать ОС РВ, реализуемо и без нее. Тем не менее все-таки попробуем разобраться, когда ОС РВ реально нужна, а когда нет.

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

 

void main (void)

{

int i;

for(;; ){

for (i=0; i< 3; i++) {

if (switch_was_changed(i)) change_Pump(i);

}

}

}

 

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

Если требуется опрашивать переключатели ровно 10 раз в секунду, про­грамма может быть изменена:

 

for(;; ){

if(100msec_passed){

for (i=0; i< 3; i++) {

if (switch_was_changed(i) change_Pump(i);

}

100msec_passed=0;

}

}

 

Глобальная переменная 100msec_passed устанавливается в «1» каждые 100 мс с помощью подпрограммы обработки прерываний от таймера. Теперь до­пустим, что нам дополнительно нужно каждые 200 мс измерять давление и от­крывать вентиль, если давление больше 20 атм. Если при открытом вентиле деление падает ниже 15 атм, вентиль необходимо закрыть. Для выполнения этой задачи в тело цикла может быть добавлен следующий фрагмент:

 

if (200msec_passed) {

switch (valve.status) {

case CLOSED:

if (pressure_value()> 20){

open_valve();

valve_status=OPEN;

}

case OPEN:

if(pressure_value()< 15){

close_valve();

valve_status=CLOSED;

}

}

200msec_passed-0;

}

 

Глобальная переменная 200msec_passed устанавливается в 1 каждые 200 мс. Так как тело цикла for (;; ) стало большим, удобно вынести функции в отдельные подпрограммы и переписать основную программу следующим образом:

 

for(;; ){

process_pump_switches();

process_pressure_regulation();

}

 

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

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

 

for(;; ){

process_pump_switches();

process_pressure_regulation();

show_trend();

}

 

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

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

В общем случае решение о применении какого-либо коммерческого ПО реального времени зависит от множества факторов. В том числе и от таких, как время, отпущенное на разработку, наличие и квалификация специалис­тов, объемы финансирования проекта и т. п.

 

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

Бурный рост популярности Linux побуждает разработчиков внимательнее присмотреться к этой операционной системе [11]. У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы: SGI, IBM, Intel, Motorola и т.д. В частности, Motorola активно работает в своей традиционной сфере встраиваемых систем и продвигает на рынок продукт LinuxEmbedded. Вообще говоря, Linux прекрасно подходит для компактных встроенных применений; на рынке уже появились поставщики, предлагающие усеченные варианты этой операционной системы, которые занимают 1-2 Мбайт на жестком диске. В качестве примера можно привести проект Linux Router Project.

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

Проект KURT характеризуется минимальными изменениями ядра Linux и предусматривает два режима работы – нормальный (normal mode) и режим реального времени (real-time mode). Процесс, использующий библиотеку API-интерфейсов KURT, в любые моменты времени может переключаться между этими двумя режимами. Программный пакет KURT оформлен в виде отдельного системного модуля Linux – RTMod, который становится дополнительным планировщиком реального времени. Данный планировщик доступен в нескольких вариантах и может тактироваться от любого системного таймера или от прерываний стандартного параллельного порта. Так как все процессы работают в общем пространстве процессов Linux, программист использует в своих программах стандартные API-интерфейсы Linux и может переключаться из одного режима в другой по событиям либо в определенных местах программы. При переключении в режим реального времени все процессы в системе " засыпают" до момента освобождения ветви процесса реального времени. Это довольно удобно при реализации задач с большим объемом вычислений, по своей сути требующих механизмов реального времени, например в задачах обработки аудио- и видеоинформации.

Стандартно такты планировщика RTMod задаются от системного таймера – время переключения контекста задач реального времени (time slice) равно 10 мс. Используя же KURT совместно с UTIME, можно довести время переключения контекста задач до 1 мс. Прерывания обрабатываются стандартным для ОС Linux образом – через механизм драйверов.

API-интерфейс KURT разделяется на две части – прикладную и системную. Прикладная часть позволяет программисту управлять поведением процессов, а системный API-интерфейс предназначен для манипулирования пользовательскими процессами и программирования собственных планировщиков. Прикладная часть API-интерфейса KURT состоит всего из четырех функций:

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

get_num_rtprocs получает идентификатор " rt_id" процесса из планировщика реального времени RTMod;

rt_suspend позволяет приостановить планировщик реального времени;

get_rt_stats получает статус процесса из таблицы планировщика процессов реального времени.

Простота использования KURT позволяет с максимальным комфортом программировать задачи, требующие как функций реального времени, так и всего многообразия API-интерфейса Unix. Использование " мягкого" реального времени обычно подходит для реализации мультимедийных задач, а также при обработке разного рода потоков информации, где критично время получения результата. Совершенно другой подход применен при реализации в Linux " жесткого" реального времени.

RTLinux – это дополнение к ядру Linux, реализующее режим " жесткого" реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux – это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени – передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

Нельзя выполнять следующие операции: блокировать аппаратные прерывания и предохранять себя от вытеснения другой задачей. Ключ к реализации данной системы – драйвер, эмулирующий систему управления прерываниями, к которому обращается Linux при попытке блокировать прерывания. В этом случае драйвер перехватывает запрос, сохраняет его и возвращает управление Linux-ядру.

Все аппаратные прерывания перехватываются ядром операционной системы реального времени. Когда происходит прерывание, ядро RTLinux решает, что делать. Если это прерывание имеет отношение к задаче реального времени, ядро вызывает соответствующий обработчик. В противном случае, либо если обработчик реального времени говорит, что хочет разделять это прерывание с Linux, обработчику присваивается состояние ожидания (pending). Если Linux потребовала разрешить прерывания, то прерывания, которые находятся в состоянии " pending", эмулируются. Ядро RTLinux спроектировано таким образом, что ядру реального времени никогда не приходится ожидать освобождения ресурса, занятого Linux-процессом (рис.3.1).

 

Рис. 3.1. Механизм работы RTLinux – Linux-расширения

жесткого реального времени

 

Для обмена данными между операционными системами реального времени и Linux могут использоваться следующие механизмы:

– разделяемые области памяти;

– псевдоустройства, предоставляющие возможность обмена данными с приложениями реального времени.

Ключевой принцип построения RTLinux – как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. " На плечи" RTLinux ложится только планирование задач реального времени и обработка прерываний. Для простоты запуска в контексте ядра, сохранения модульности и расширяемости системы процессы реального времени реализованы в виде загружаемых модулей Linux. Как правило, приложение реального времени с RTLinux состоит из двух независимых частей: процесса, исполняемого ядром RTLinux, и обыкновенного Linux-приложения.

Для иллюстрации работы приложения реального времени рассмотрим прикладной модуль, который использует ядро реального времени RTLinux в виде загружаемого модуля Linux:

 

#define MODULE#include < linux/module.h> /* необходимо для задачреального времени */#include < linux/rt_sched.h> #inlcude < linux/rt_fifo.h> RT_TASK mytask;

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

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

 

 

Рис. 3.2. Механизм межпроцессной связи через очереди сообщений FIFO

 

Как и каждый модуль Linux-ядра, процесс реального времени должен выполнить процедуры инициализации и завершения, аналогичные модулям Linux:

int init_module(void){/* определить номерочереди сообщений */ #define RTFIFODESC 1/* взять локальное время */RTIME now = rt_get_time()rt_task_init(& mytask, mainloop, RTFIFODESC, 3000, 4); rt_task_make_periodic(& mytask, now+1000, 25000); return 0; }

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

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

 

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

 

Сегодня становится широко распространенным желание потребителей использовать Windows NT в системах реального времени [9]. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки. Тем не менее, возможно ли использование Windows для разработки системы реального времени?

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

1.ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

2. Диспетчеризация должна осуществляться на базе приоритетов.

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

3. Механизм синхронизации нитей должен быть предсказуемым.

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

4. Должна существовать система наследования приоритетов.

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

5. Временные характеристики ОС должны быть предсказуемы и известны.

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

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

Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

Очевидно, что NT – многонитевая ОС, она позволяет вытеснение и тем самым удовлетворяет требованию 1.

В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 – 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

Казалось бы, второе требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Большинство современных ОС РВ позволяет иметь, по крайней мере, 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Более того, общее число уровней для всех процессов класса только 16 и положение не спасает даже замена нитей процессами, не говоря уже о том, что переключение контекста для процессов снижает производительность.

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

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

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Популярное:

1. F. Дела челобитчиковы. - Условный критерий частноправного отношения. - Безразличие методов процедирования. - Екатерининская эпоха. - Единство в праве. - Судебная волокита
2. F30.1 Мания без психотических симптомов.
3. F33.2 Рекуррентное депрессивное расстройство, текущий эпизод тяжелый степени без психотических симптомов.
4. F70.99 Умственная отсталость легкой степени без указаний на нарушение поведения, обусловленная неуточненными причинами
5. F71.98 Умственная отсталость умеренная без указаний на нарушение поведения, обусловленная другими уточненными причинами
6. I. Безопасность на железной дороге.
7. I. Печенье чайное домашнее (без дрожжей и без соды)
8. III. Спасение без компромисса
9. IV. Особость в сравнении с безгрешием
10. IX.УПРАВЛЕНИЕ ТЕХНОСФЕРНОЙ БЕЗОПАСНОСТЬЮ
11. SWOT-анализ: характеристики при оценке сильных и слабых сторон компании, ее возможностей и угроз ей
12. VII. Последний вопрос, всё еще остающийся без ответа