СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ. Уверенностью можно сказать, что ссылки на красивое словосо
 Скачать 288.74 Kb.
|
|
Смертельный захват (Deadlock). В народе побочные проявления этой си туации называются более прозаично – «зацикливание» или «зависание». А причина этого может быть достаточ но проста – «задачи не поделили ре сурсы». Пусть, например, Задача А за хватила ресурс клавиатуры и ждет, ког да освободится ресурс дисплея, а в это время Задача В также хочет пообщать ся с пользователем и, успев захватить ресурс дисплея, ждет теперь, когда ос вободится клавиатура. Так и будут за дачи ждать друг друга до второго пото па, а пользователь будет в это время смотреть на пустой экран и ругать последними словами яйцеголовых ОБЗОР Программное обеспечение 27 2/97 (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru программистов, которые не смогли сделать нормально работающую сис тему. В таких случаях рекомендуется придерживаться тактики «или все, или ничего». Другими словами, если задача не смогла получить все необходимые для дальнейшей работы ресурсы, она должна освободить всё, что уже захва чено, и, как говорится, «зайти через полчаса». Другим решением, которое уже упоминалось, является использо вание серверов ресурсов. Инверсия приоритетов (Priority inversion). Как уже отмечалось, алго ритмы планирования задач (управле ние доступом к процессорному време ни) должны находиться в соответст вии с методами управления доступом к другим ресурсам, а всё вместе – соот ветствовать критериям оптимального функционирования системы. Эффект инверсии приоритетов является след ствием нарушения гармонии в этой области. Ситуация здесь похожа на «смертельный захват», однако сюжет закручен еще более лихо. Представим, что у нас есть высокоприоритетная Задача А, среднеприоритетная Задача В и низкоприоритетная Задача С. Пусть в начальный момент времени Задачи А и В блокированы в ожидании какоголибо внешнего события. До пустим, получившая в результате этого управление Задача С захватила Сема фор А, но не успела она его отдать, как была прервана Задачей А. В свою оче редь, Задача А при попытке захватить Семафор А будет блокирована, так как этот семафор уже захвачен Задачей С. Если к этому времени Задача В нахо дится в состоянии готовности, то уп равление после этого получит именно она, как имеющая более высокий, чем у Задачи С, приоритет. Теперь Задача В может занимать процессорное время, пока ей не надоест, а мы получаем си туацию, когда высокоприоритетная Задача А не может функционировать изза того, что необходимый ей ресурс занят низкоприоритетной Задачей С. Синхронизация с внешними событиями Известно, что применение аппарат ных прерываний является более эф фективным методом взаимодействия с внешним миром, чем метод опроса. Разработчики систем реального вре мени стараются использовать этот факт в полной мере. При этом можно проследить следующие тенденции: 1. Стремление обеспечить максималь но быструю и детерминированную реакцию системы на внешнее собы тие. 2. Старание добиться минимально возможных периодов времени, ког да в системе запрещены прерывания. 3. Подпрограммы обработки прерыва ний выполняют минимальный объ ем функций за максимально корот кое время. Это обусловлено несколь кими причинами. Вопервых, не все ОС РВ обеспечивают возможность «вытеснения» во время обработки подпрограмм прерывания. Вовто рых, приоритеты аппаратных пре рываний не всегда соответствуют приоритетам задач, с которыми они связаны. Втретьих, задержки с обра боткой прерываний могут привести к потере данных. Как правило, закончив элементарно необходимые действия, подпрограмма обработки прерываний генерирует в той или иной форме сообщение для за дачи, с которой это прерывание связа но, и немедленно возвращает управле ние. Если это сообщение перевело за дачу в разряд готовых к исполнению, планировщик в зависимости от ис пользуемого алгоритма и приоритета задачи принимает решение о том, не обходимо или нет немедленно пере дать управление получившей сообще ние задаче. Разумеется, это всего лишь один из возможных сценариев, так как каждая ОС РВ имеет свои особенности при обработке прерываний. Кроме то го, свою специфику может накладывать используемая аппаратная платформа. Синхронизация по времени Совсем не так давно (лет 20 назад) аппаратные средства, отвечающие в вычислительных системах за службу времени, были совершенно не развиты. В те приснопамятные времена счита лось достаточным, если в системе гене рировалось прерывание с частотой се ти переменного тока. Те же, кто не знал, что частота сети в США 60 Гц, а не 50, как у нас, постоянно удивлялись тому, что системное время в RSX11M никог да не бывает правильным. Програм мисты для получения задержек по вре мени часто использовали программ ные циклы ожидания и, разумеется, пользователи таких программ получа ли массу сюрпризов при попытке их переноса на следующее поколение компьютеров с более высокими такто выми частотами. Слава Богу (или науч нотехническому прогрессу), сейчас любой маломальски приличный компьютер имеет часы/календарь с ба тарейной поддержкой и многофункци ональный таймер (а то и несколько) с разрешением до единиц микросекунд. Как правило, в ОС РВ задается эталон ный интервал (квант) времени, кото рый иногда называют тиком (Tick) и ко торый используется в качестве базовой единицы измерения времени. Размер ОБЗОР Программное обеспечение 2/97 28 ность этой единицы для разных ОС РВ может быть разной, как, впрочем, раз ными могут быть набор функций и ме ханизмы взаимодействия с таймером. Функции по работе с таймером исполь зуют для приостановки выполнения за дачи на какоето время, для запуска за дачи в определенное время, для относи тельной синхронизации нескольких за дач по времени и т. п. Если в программе для ОС РВ вы увидите операнд delay (50), то, скорее всего, это обозначает, что в этом месте задача должна прер ваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовности. Все это время процессор не простаивает, а решает другие задачи, если таковые имеются. Множество задач одновре менно могут запросить сервис таймера, поэтому если для каждого такого запро са используется элемент в таблице вре менных интервалов, то накладные рас ходы системы по обработке прерыва ний от аппаратного таймера растут пропорционально размерности этой таблицы и могут стать недопустимыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм так называемого дифференциального таймера, когда во время каждого тика уменьшается только один счетчик интервала времени. Для точной синхронизации таймера вычислительной системы с астроно мическим временем могут применять ся специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, кото рые позволяют воспользоваться атом ными часами на борту орбитальных космических аппаратов, запущенных по программе Navstar. ТЕСТИРОВАНИЕ Прежде чем устанавливать вашу сис тему реального времени на не менее реальном объекте, рекомендуется про верить ее работоспособность с по мощью интенсивных тестов. Это осо бенно важно для сложных динамичес ких систем. Во время такого тестирова ния желательно смоделировать наибо лее неприятные и «тяжелые» режимы работы, аварийные ситуации и т. п. При умозрительном анализе простых сис тем следует осторожно относиться к рекламной информации разработчи ков ОС РВ, которые из коммерческих соображений показывают, как прави ло, параметры для «лучшего случая». Например, если речь идет о максималь ном времени обработки прерывания, необходимо в первую очередь понять, а что, собственно, подразумевается под этим временем: (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru а)время от возникновения запроса на прерывание до передачи управления по вектору прерывания; б)или включая время сохранения кон текста текущей задачи и передачи уп равления подпрограмме обработки прерывания; в)или дополнительно к этому еще и время до завершения подпрограммы обработки прерывания и передачи сообщения связанной с прерывани ем задаче; г) или дополнительно к этому время до момента, когда эта задача наконец получит управление (в предположе нии, что она является наиболее при оритетной) и начнет реальную обра ботку события. Безотносительно к тому, какой вари ант рассматривается, необходимо пом нить, что 1)если наряду с разработанными вами программами используется программ ное обеспечение третьих фирм, вы не застрахованы от того, что там не встретятся участки кода, где преры вания запрещены; 2)практически любая ОС РВ имеет в своих недрах участки такого кода. Нам остается только надеяться, что разработчики ОС старались делать их как можно меньше; 3)всё ядро ОС РВ или его участки могут быть «невытесняемыми»; 4)интеллектуальные контроллеры ввода/вывода типа SCSI могут ини циировать в системе различные слу жебные операции, которые способ ны отразиться на ее характеристи ках; 5)многое зависит от применяемой сис темы кэширования. Поэтому, если ваше событие про изошло в «неподходящее» время, ре альные показатели быстродействия могут сильно отличаться от реклами руемых. Перефразируя классика, самое время воскликнуть: «Тестировать, тестировать и еще раз тестировать!!!» ЗАКЛЮЧЕНИЕ Хотя, как мы увидели, ОС РВ предо ставляют много полезных и удобных средств для написания программ, ос новной груз ответственности лежит на плечах рядового труженикапрограм миста. Ведь стоит ему переместить пе ременную из категории локальных в категорию глобальных и забыть над лежащим образом оформить крити ческие секции, как станут падать кос мические корабли, взрываться нефте перерабатывающие заводы, источать радиоактивность атомные станции. Так воспоем гимн этому великому тру женику. Крепче держать знамя социа листического соревнования за победу над инверсией приоритетов. ● ОБЗОР Программное обеспечение 29 2/97 МОЖНО ЛИ ОБОЙТИСЬ БЕЗ ОС РВ? Как любую вычислительную систему можно создать только из элементов 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 robin) ме! ханизм выполнения задач, вполне подходящий для многих применений. Од! нако этот же пример показывает, что по мере роста числа и сложности функ! ций, которые необходимо выполнять, наличие стандартных средств органи! зации параллельного выполнения задач, работы с таймером, межзадачного обмена информацией и т. п. могут существенно повысить производитель! ность программистов и уменьшить число ошибок. Именно здесь могут про! явить свои положительные стороны ядра и операционные системы реально! го времени, как раз такие средства и предлагающие. В общем случае решение о применении какого!либо коммерческого ПО реального времени зависит от множества факторов, в том числе и от таких, как время, отпущенное на разработку, наличие и квалификация специалис! тов, объемы финансирования проекта и т. п. (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru |