ЖУРНАЛ СТА 2/1997

смогли сделать нормально работаю- щую систему. В таких случаях реко- мендуется придерживаться тактики «или все, или ничего». Другими сло- вами, если задача не смогла полу- чить все необходимые для дальней- шей работы ресурсы, она должна ос- вободить всё, что уже захвачено, и, как говорится, «зайти через полчаса». Другим решением, которое уже упо- миналось, является использование серверов ресурсов. Инверсия приоритетов (Priority inversion). Как уже отмечалось, алго- ритмы планирования задач (управле- ние доступом к процессорному вре- мени) должны находиться в соответ- ствии с методами управления досту- пом к другим ресурсам, а всё вместе — соответствовать критериям оптималь- ного функционирования системы. Эффект инверсии приоритетов явля- ется следствием нарушения гармонии в этой области. Ситуация здесь похо- жа на «смертельный захват», однако сюжет закручен еще более лихо. Пред- ставим, что у нас есть высокоприори- тетная Задача А, среднеприоритетная Задача В и низкоприоритетная Задача С. Пусть в начальный момент времени Задачи А и В блокированы в ожидании какоголибо внешнего события. До- пустим, получившая в результате этого управление Задача С захватила Сема- фор А, но не успела она его отдать, как была прервана Задачей А. В свою оче- редь, Задача А при попытке захватить Семафор А будет блокирована, так как этот семафор уже захвачен Задачей С. Если к этому времени Задача В нахо- дится в состоянии готовности, то уп- равление после этого получит именно она, как имеющая более высокий, чем у Задачи С, приоритет. Теперь Задача В может занимать процессорное время, пока ей не надоест, а мы получаем си- туацию, когда высокоприоритетная Задача А не может функционировать изза того, что необходимый ей ресурс занят низкоприоритетной Задачей С. Синхронизация с внешними событиями Известно, что применение аппарат- ных прерываний является более эф- фективным методом взаимодействия с внешним миром, чем метод опроса. Разработчики систем реального вре- мени стараются использовать этот факт в полной мере. При этом можно проследить следующие тенденции: 1. Стремление обеспечить максимально быструю и детерминированную реак- цию системы на внешнее событие. 2. Старание добиться минимально воз- можных периодов времени, когда в системе запрещены прерывания. 3. Подпрограммы обработки прерыва- ний выполняют минимальный объ- ем функций за максимально корот- кое время. Это обусловлено несколь- кими причинами. Вопервых, не все ОС РВ обеспечивают возможность «вытеснения» во время обработки подпрограмм прерывания. Вовто- рых, приоритеты аппаратных пре- рываний не всегда соответствуют приоритетам задач, с которыми они связаны. Втретьих, задержки с обра- боткой прерываний могут привести к потере данных. Как правило, закончив элементарно необходимые действия, подпрограмма обработки прерываний генерирует в той или иной форме сообщение для задачи, с которой это прерывание свя- зано, и немедленно возвращает управ- ление. Если это сообщение перевело задачу в разряд готовых к исполнению, планировщик в зависимости от ис- пользуемого алгоритма и приоритета задачи принимает решение о том, не- обходимо или нет немедленно пере- дать управление получившей сообще- ние задаче. Разумеется, это всего лишь один из возможных сценариев, так как каждая ОС РВ имеет свои особен- ности при обработке прерываний. Кроме того, свою специфику может накладывать используемая аппаратная платформа. Синхронизация по времени Совсем не так давно (лет 20 назад) аппаратные средства, отвечающие в вычислительных системах за службу времени, были совершенно не разви- ты. В те приснопамятные времена считалось достаточным, если в систе- ме генерировалось прерывание с час- тотой сети переменного тока. Те же, кто не знал, что частота сети в США 60 Гц, а не 50, как у нас, постоянно удивлялись тому, что системное время в RSX11M никогда не бывает правильным. Про- граммисты для получения задержек по времени часто использовали про- граммные циклы ожидания и, разуме- ется, пользователи таких программ по- лучали массу сюрпризов при попытке их переноса на следующее поколение компьютеров с более высокими такто- выми частотами. Слава Богу (или на- учнотехническому прогрессу), сейчас любой маломальски приличный компь- ютер имеет часы/календарь с батарей- ной поддержкой и многофункцио- нальный таймер (а то и несколько) с разрешением до единиц микросекунд. Как правило, в ОС РВ задается эталон- ный интервал (квант) времени, который иногда называют тиком (Tick) и кото- рый используется в качестве базовой единицы измерения времени. Размер- ОБЗОР Программное обеспечение 2/97 28 ность этой единицы для разных ОС РВ может быть разной, как, впрочем, раз- ными могут быть набор функций и механизмы взаимодействия с таймером. Функции по работе с таймером исполь- зуют для приостановки выполнения задачи на какоето время, для запуска задачи в определенное время, для отно- сительной синхронизации нескольких задач по времени и т. п. Если в про- грамме для ОС РВ вы увидите операнд delay (50), то, скорее всего, это обозна- чает, что в этом месте задача должна прерваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовнос- ти. Все это время процессор не про- стаивает, а решает другие задачи, если таковые имеются. Множество задач од- новременно могут запросить сервис таймера, поэтому если для каждого та- кого запроса используется элемент в таблице временных интервалов, то на- кладные расходы системы по обработ- ке прерываний от аппаратного таймера растут пропорционально размерности этой таблицы и могут стать недопусти- мыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм так называ- емогодифференциального таймера, ког- да во время каждого тика уменьшается только один счетчик интервала времени. Для точной синхронизации таймера вычислительной системы с астроно- мическим временем могут применя- ться специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, которые позволяют воспользоваться атомными часами на борту орбиталь- ных космических аппаратов, запущен- ных по программе Navstar. ТЕСТИРОВАНИЕ Прежде чем устанавливать вашу сис- тему реального времени на не менее реальном объекте, рекомендуется про- верить ее работоспособность с по- мощью интенсивных тестов. Это осо- бенно важно для сложных динами- ческих систем. Во время такого тести- рования желательно смоделировать наиболее неприятные и «тяжелые» ре- жимы работы, аварийные ситуации и т. п. При умозрительном анализе про- стых систем следует осторожно отно- ситься к рекламной информации раз- работчиков ОС РВ, которые из ком- мерческих соображений показывают, как правило, параметры для «лучшего случая». Например, если речь идет о максимальном времени обработки прерывания, необходимо в первую очередь понять, а что, собственно, подразумевается под этим временем: