3.4.4. Синхронизация по времени
Совсем не так давно (лет 20 назад) аппаратные средства, отвечающие в вычислительных системах за службу времени, были совершенно не развиты. В те приснопамятные времена считалось достаточным, если в системе генерировалось прерывание с частотой сети переменного тока. Те же, кто не знал, что частота сети в США 60 Гц, а не 50, как у нас, постоянно удивлялись тому, что системное время в RSX-11M никогда не бывает правильным. Программисты для получения задержек по времени часто использовали программные циклы ожидания и, разумеется, пользователи таких программ получали массу сюрпризов при попытке их переноса на следующее поколение компьютеров с более высокими тактовыми частотами. Слава Богу (или научно-техническому прогрессу), сейчас любой мало-мальски приличный компьютер имеет часы/календарь с батарейной поддержкой и многофункциональный таймер(а то и несколько) с разрешением до единиц микросекунд.
Как правило, в ОС РВ задается эталонный интервал (квант) времени, который иногда называют тиком (Tick) и который используется в качестве базовой единицы измерения времени. Размерность этой единицы для разных ОС РВ может быть разной, как, впрочем, разными могут быть набор функций и механизмы взаимодействия с таймером. Функции по работе с таймером используют для приостановки выполнения задачи на какое-то время, для запуска задачи в определенное время, для относительной синхронизации нескольких задач по времени и т. п. Если в программе для ОС РВ вы увидите операнд delay (50), то, скорее всего, это обозначает, что в этом месте задача должна прерваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовности. Все это время процессор не простаивает, а решает другие задачи, если таковые имеются. Множество задач одновременно могут запросить сервис таймера, поэтому если для каждого такого запроса используется элемент в таблице временных интервалов, то накладные расходы системы по обработке прерываний от аппаратного таймера растут пропорционально размерности этой таблицы и могут стать недопустимыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм так называемого дифференциального таймера, когда во время каждого тика уменьшается только один счетчик интервала времени.
Для точной синхронизации таймера вычислительной системы с астрономическим временем могут применяться специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, которые позволяют воспользоваться атомными часами на борту орбитальных космических аппаратов, запущенных по программе Navstar.
Прежде чем устанавливать вашу систему реального времени на не менее реальном объекте, рекомендуется проверить ее работоспособность с помощью интенсивных тестов. Это особенно важно для сложных динамических систем. Во время такого тестирования желательно смоделировать наиболее неприятные и «тяжелые» режимы работы, аварийные ситуации и т. п. При умозрительном анализе простых систем следует осторожно относиться к рекламной информации разработчиков ОС РВ, которые из коммерческих соображений показывают, как правило, параметры для «лучшего случая». Например, если речь идет о максимальном времени обработки прерывания, необходимо в первую очередь понять, а что, собственно, подразумевается под этим временем:
а) время от возникновения запроса на прерывание до передачи управления по вектору прерывания;
б) или включая время сохранения контекста текущей задачи и передачи управления подпрограмме обработки прерывания;
в) или дополнительно к этому еще и время до завершения подпрограммы обработки прерывания и передачи сообщения связанной с прерыванием задаче;
г) или дополнительно к этому время до момента, когда эта задача наконец получит управление (в предположении, что она является наиболее приоритетной) и начнет реальную обработку события.
Безотносительно к тому, какой вариант рассматривается, необходимо помнить, что
1) если наряду с разработанными вами программами используется программное обеспечение третьих фирм, вы не застрахованы от того, что там не встретятся участки кода, где прерывания запрещены;
2) практически любая ОС РВ имеет в своих недрах участки такого кода. Нам остается только надеяться, что разработчики ОС старались делать их как можно меньше;
3) всё ядро ОС РВ или его участки могут быть «невытесняемыми»;
4)интеллектуальные контроллеры ввода/вывода типа SCSI могут инициировать в системе различные служебные операции, которые способны отразиться на ее характеристиках;
5)многое зависит от применяемой системы кэширования. Поэтому, если ваше событие произошло в «неподходящее» время, реальные показатели быстродействия могут сильно отличаться от рекламируемых.
5. Можно ли обойтись без ОС РВ?
Как любую вычислительную систему можно создать только из элементов 2И!НЕ, так и все, что может делать ОС РВ, реализуемо и без нее. Тем не менее, давайте все-таки попробуем разобраться, когда ОС РВ реально нужна, а когда нет. Предположим, нам надо не реже 10 раз в секунду опросить три переключателя и в зависимости от их положения включить или выключить соответствующий насос.
Программа может выглядеть следующим образом:
voidmain (void)
{
inti;
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) механизм выполнения задач, вполне подходящий для многих применений. Однако этот же пример показывает, что по мере роста числа и сложности функций, которые необходимо выполнять, наличие стандартных средств организации параллельного выполнения задач, работы с таймером, межзадачного обмена информацией и т. п. могут существенно повысить производительность программистов и уменьшить число ошибок. Именно здесь могут проявить свои положительные стороны ядра и операционные системы реального времени, как раз такие средства и предлагающие.
В общем случае решение о применении какого-либо коммерческого ПО реального времени зависит от множества факторов, в том числе и от таких, как время, отпущенное на разработку, наличие и квалификация специалистов, объемы финансирования проекта и т. п.
Хотя, как мы увидели, ОС РВ предоставляют много полезных и удобных средств для написания программ, основной груз ответственности лежит на плечах рядового труженика-программиста. Ведь стоит ему переместить переменную из категории локальных в категорию глобальных и забыть надлежащим образом оформить критические секции, как станут падать космические корабли, взрываться нефтеперерабатывающие заводы, источать радиоактивность атомные станции.
Список использованной литературы
1. Алан Джок «ОС реального времени».
2. http://www.tepcom.ru/produkts/real/Report_Notations_A .asp.
3. http://www.asutp.ru/?p=600591.
4. Замечания о выборе операционных систем при построении систем реального времени (А. Жданов, А. Латыев., ЗАО "РТСофт", PCWeek, 1/2001).