СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ. Уверенностью можно сказать, что ссылки на красивое словосо
 Скачать 288.74 Kb.
|
|
С уверенностью можно сказать, что ссылки на красивое словосо четание «реальное время» стали общим местом на различных семина рах, конференциях и в специализиро ванной печати. С неменьшей уверен ностью можно сказать, что смысл это го термина трактуется специалистами поразному в зависимости от области их профессиональных интересов, от того, являются они теоретиками или практиками, и даже просто от личного опыта и круга общения. В этой статье мы сконцентрируемся на рассмотрении данного вопроса применительно к цифровой вычисли тельной технике, используемой в сис темах управления и сбора данных. Ос новное внимание будет уделено про граммному обеспечению, так как оно является наиболее слабым звеном в системах реального времени. Много процессорные системы для простоты рассматриваться не будут. Статья не претендует на исчерпывающее изло жение предмета и является скорее за метками на тему основных понятий и терминологии в этой области. ТАК ЧТО ЖЕ ТАКОЕ РЕАЛЬНОЕ ВРЕМЯ Если попытаться дать короткое оп ределение, то 1. Система называется системой ре ального времени, если правильность ее функционирования зависит не только от логической корректности вычислений, но и от времени, за кото рое эти вычисления производятся. То есть для событий, происходящих в та кой системе, то, КОГДА эти события происходят, так же важно, как логичес кая корректность самих событий. 2. Говорят, что система работает в реальном времени, если ее быстродей ствие адекватно скорости протекания физических процессов на объектах контроля или управления. Так как окру жающий нас мир весьма многообра зен, здесь уместно добавить, что име ются в виду именно те процессы, кото рые непосредственно связаны с функ циями, выполняемыми конкретной системой реального времени. То есть система управления должна собрать данные, произвести их обработку в со ответствии с заданными алгоритмами и выдать управляющие воздействия за такой промежуток времени, который обеспечивает успешное решение по ставленных перед системой задач. Из приведенных определений следу ет несколько интересных выводов. Вопервых, практически все системы промышленной автоматизации явля ются системами реального времени. Вовторых, принадлежность системы к классу систем реального времени ни как не связана с ее быстродействием. Например, если ваша система предна значена для контроля уровня грунто вых вод, то даже выполняя измерения с периодичностью один раз за полчаса, она будет работать в реальном времени. Исходные требования к времени ре акции системы и другим временным параметрам определяются или техни ческим заданием на систему, или про сто логикой ее функционирования. На пример, шахматная программа, думаю щая над каждым ходом более года, ра ботает явно не в реальном времени, так как шахматист скорее всего не доживет до конца партии. Однако точное опре деление «приемлемого времени реак ции» не всегда является простой зада чей, а в системах, где одним из звеньев служит человек, подвержено влиянию субъективных факторов. Впрочем, че ловек – это своеобразная вычислитель ная машина, а мы договорились мно гопроцессорных конфигураций не рассматривать. Интуитивно понятно, что быстро действие системы реального времени должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы оценить необходимое быстродейст вие для систем, имеющих дело со ста ционарными процессами, часто ис пользуют теорему Котельникова, из которой следует, что частота дискре тизации сигналов должна быть как ми нимум в 2 раза выше граничной часто ты их спектра. При работе с широкополосными по своей природе переходными процес сами (транзиентанализ) часто приме няют быстродействующие АЦП с бу ферной памятью, куда с необходимой скоростью записывается реализация сигнала, которая затем анализируется и/или регистрируется вычислитель ной системой. При этом требуется за кончить всю необходимую обработку до следующего переходного процесса, иначе информация будет потеряна. Подобные системы иногда называют системами квазиреального времени. Принято различать системы «жест кого» и «мягкого» реального времени. Читатель наверное догадался, что эти различия не связаны с органолепти ческими свойствами систем. Тогда что же это такое? 1. Системой «жесткого» реального времени называется система, где не способность обеспечить реакцию на какиелибо события в заданное время является отказом и ведет к невозмож ности решения поставленной задачи. Последствия таких отказов могут быть разные, от пролива драгоценной влаги на линии по розливу алкоголь ных напитков до более крупных не приятностей, если, например, вовремя не сработала система аварийных бло кировок атомного реактора. Многие теоретики ставят здесь точку, из чего следует, что время реакции в «жестких» системах может составлять и секунды, и часы, и недели. Однако большинство практиков считают, что время реакции в системах «жесткого» реального времени должно быть все таки минимальным. Идя на поводу у практиков, так и будем считать. Разуме ется, однозначного мнения о том, ка кое время реакции свойственно «жест ким» системам, нет. Более того, с увели чением быстродействия микропроцес соров это время имеет тенденцию к уменьшению, и если раньше в качестве границы называлось значение 1 мс, то сейчас, как правило, называется время порядка 100 мкс. 2. Точного определения для «мягко го» реального времени не существует, поэтому будем считать, что сюда отно сятся все системы реального времени, не попадающие в категорию «жестких». Так как система «мягкого» реального времени может не успевать ВСЁ делать ОБЗОР Программное обеспечение 2/97 22 ОПЕРАЦИОННЫЕ СИСТЕМЫ Сергей Сорокин СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ ' (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru ВСЕГДА в заданное время, возникает проблема определения критериев ус пешности (нормальности) ее фун кционирования. Вопрос этот совсем не простой, так как в зависимости от функций системы это может быть мак симальная задержка в выполнении ка кихлибо операций, средняя своевре менность отработки событий и т. п. Бо лее того, эти критерии влияют на то, какой алгоритм планирования задач является оптимальным. Вообще говоря, системы «мягкого» реального времени проработаны теоретически далеко не до конца. ЯДРА И ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ Чтобы быстрее перейти к делу, при мем как очевидные следующие момен ты. 1. Когдато операционных систем со всем не было. 2. Через некоторое время после их появ ления возникло направление ОС РВ. 3. Все ОС РВ являются многозадачны ми операционными системами. Зада чи делят между собой ресурсы вы числительной системы, в том числе и процессорное время. Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие ба зовые функции, как планирование и синхронизация задач, межзадачная коммуникация, управление памятью и т. п. Операционные системы в допол нение к этому имеют файловую систе му, сетевую поддержку, интерфейс с оператором и другие средства высоко го уровня. По своей внутренней архитектуре ОС РВ можно условно разделить на мо нолитные ОС, ОС на основе микроядра и объектноориентированные ОС. Гра фически различия в этих подходах ил люстрируются рисунками 1, 2, 3. Пре имущества и недостатки различных ар хитектур достаточно очевидны, поэто му подробно мы на них останавливать ся не будем. Пользователь, напуганный перспек тивой изучать новую операционную систему, может здесь вполне резонно спросить: «А нельзя ли вооб ще обойтись без всей этой заумной канители?» Если отвечать на этот во прос односложно, то да, МОЖНО. Однако ответ на во прос о том, когда это НУЖНО делать, остается, конечно, за читателем. Материалы во врезке к статье, возможно, дадут некоторую пищу к раз мышлениям на эту тему. Задачи, процессы, потоки Существуют различные оп ределения термина «задача» для многозадачной ОС РВ. Мы будем считать задачей набор операций (машинных инструкций), предназначен ный для выполнения логи чески законченной функции системы. При этом задача конкурирует с другими зада чами за получение контроля над ресурсами вычислитель ной системы. Принято различать две разно видности задач: процессы и пото ки. Процесс представляет собой от дельный загружаемый программный модуль (файл), который, как правило, во время исполнения имеет в памяти свои независимые области для кода и данных. В отличие от этого потоки мо гут пользоваться общими участками кода и данных в рамках единого про граммного модуля. Хорошим примером многопоточ ной программы является редактор текста WORD, где в рамках одного ОБЗОР Программное обеспечение 23 2/97 Рис. 1. ОС РВ с монолитной архитектурой Рис. 2. ОС РВ на основе микроядра Рис. 3. Объектно4ориентированная ОС РВ (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru приложения может одновременно происходить и набор текста, и провер ка правописания. Преимущества потоков 1. Так как множество потоков способ но размещаться внутри одного ЕХЕ модуля, это позволяет экономить ре сурсы как внешней, так и внутрен ней памяти. 2. Использование потоками общей об ласти памяти позволяет эффективно организовать межзадачный обмен сообщениями (достаточно передать указатель на сообщение). Процессы не имеют общей области памяти, по этому ОС должна либо целиком ско пировать сообщение из области па мяти одной задачи в область памяти другой (что для больших сообщений весьма накладно), либо предусмот реть специальные механизмы, кото рые позволили бы одной задаче по лучить доступ к сообщению из об ласти памяти другой задачи. 3. Как правило, контекст потоков меньше, чем контекст процессов, а значит, время переключения между задачамипотоками меньше, чем между задачамипроцессами. 4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ модуле, значительно упрощается ис пользование программотладчиков (debugger). Недостатки потоков 1. Как правило, потоки не могут быть подгружены динамически. Чтобы добавить новый поток, необходимо провести соответствующие измене ния в исходных текстах и переком пилировать приложение. Процессы, в отличие от потоков, подгружаемы, что позволяет динамически изме нять функции системы в процессе ее работы. Кроме того, так как процес сам соответствуют отдельные про граммные модули, они могут быть разработаны различными компани ями, чем достигается дополнитель ная гибкость и возможность исполь зования ранее наработанного ПО. 2. То, что потоки имеют доступ к облас тям данных друг друга, может при вести к ситуации, когда некорректно работающий поток способен испор тить данные другого потока. В отли чие от этого процессы защищены от взаимного влияния, а попытка запи си в «не свою» память приводит, как правило, к возникновению специ ального прерывания по обработке «исключительных ситуаций». Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаи модействия определяются конкрет ным ПО РВ. ОСНОВНЫЕ СВОЙСТВА ЗАДАЧ Как правило, вся важная, с точки зре ния операционной системы, информа ция о задаче хранится в унифициро ванной структуре данных управляю щем блоке (Task Control Block, TCB). В блоке хранятся такие параметры, как имя и номер задачи, верхняя и нижняя границы стека, ссылка на очередь сооб щений, статус задачи, приоритет и т. п. Приоритет – это некое целое число, присваиваемое задаче и характеризую щее ее важность по сравнению с други ми задачами, выполняемыми в системе. Приоритет используется в основном планировщиком задач для определе ния того, какая из готовых к работе за дач должна получить управление. Раз личают системы с динамической и ста тической приоритетностью. В первом случае приоритет задач может менять ся в процессе исполнения, в то время как во втором приоритет задач жестко задается на этапе разработки или во время начального конфигурирования системы. Контекст задачи – это набор дан ных, содержащий всю необходимую информацию для возобновления вы полнения задачи с того места, где она была ранее прервана. Часто контекст хранится в ТСВ и включает в себя такие данные, как счетчик команд, указатель стека, регистры СРU и FPU и т. п. Плани ровщик задач в случае необходимости сохраняет контекст текущей активной задачи и восстанавливает контекст за дачи, назначенной к исполнению. Та кое переключение контекстов и явля ется, по сути, основным механизмом ОС РВ при переходе от выполнения од ной задачи к выполнению другой. Состояние (статус) задачи. С точ ки зрения операционной системы, за дача может находиться в нескольких состояниях. Число и название этих со стояний различаются от одной ОС к другой. Повидимому, наибольшее чис ло состояний задачи определено в язы ке Ada. Тем не менее практически в лю бой ОС РВ загруженная на выполнение задача может находиться, по крайней мере, в трех состояниях. 1. Активная задача – это задача, выпол няемая системой в текущей момент времени. 2. Готовая задача – это задача, готовая к выполнению и ожидающая у плани ровщика своей «очереди». 3. Блокированная задача – это задача, выполнение которой приостановле но до наступления определенных со бытий. Такими событиями могут быть освобождение необходимого задаче ресурса, поступление ожидае мого сообщения, завершение интер вала ожидания и т. п. Пустая задача (Idle Task) – это зада ча, запускаемая самой операционной системой в момент инициализации и выполняемая только тогда, когда в сис теме нет других готовых для выполне ния задач. Пустая задача запускается с самым низким приоритетом и, как пра вило, представляет собой бесконечный цикл «ничего не делать». Наличие пус той задачи предоставляет операцион ной системе удобный механизм отра ботки ситуаций, когда нет ни одной го товой к выполнению задачи. Многократный запуск задач. Как правило, многозадачные ОС позволя ют запускать несколько копий одной и той же задачи. При этом для каждой та кой копии создается свой ТСВ и выде ляется своя область памяти. В целях экономии памяти может быть предус мотрено совместное использование одного и того же исполняемого кода для всех запущенных копий. В этом случае программа должна обеспечи вать повторную входимость (реентера бельность). Кроме того, программа не должна использовать временные фай лы с фиксированными именами и должна корректно осуществлять до ступ к глобальным ресурсам. Реентерабельность (повторная входимость) означает возможность без негативных последствий временно пре рвать выполнение какойлибо функции или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Частным проявлением реентерабель ности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереен терабельной системы является DOS, а типичной причиной нереентерабель ности служит использование глобаль ных переменных. Предположим, что у нас есть функция, реализующая низкоу ровневую запись на диск, и пусть она использует глобальную переменную write_sector, которая устанавливается в соответствии с параметром, передавае мым этой функции при вызове. Пред положим теперь, что Задача А вызывает эту функцию с параметром 3, то есть хо чет записать данные в сектор номер 3. Допустим, что когда переменная write_sector уже равна 3, но сама запись еще не произведена, выполнение Зада чи А прерывается и начинает выпол няться Задача В, которая вызывает ту же функцию, но с аргументом 10. После то го как запись в сектор номер 10 будет произведена, управление рано или поздно вернется к Задаче А, которая продолжит работу с того же места. Од нако, так как переменная write_sector имеет теперь значение 10, данные Зада чи А, предназначавшиеся для сектора номер 3, будут вместо этого записаны в ОБЗОР Программное обеспечение 2/97 24 (C) 1997 CTA Тел.: (095) 2340635 Факс: (095) 3303650 http://www.cta.ru сектор номер 10. Из приведенного при мера видно, что ошибки, связанные с нереентерабельностью, трудно обнару жить, а последствия они могут вызвать самые катастрофические. ПЛАНИРОВАНИЕ ЗАДАЧ Важной частью любой ОС РВ являет ся планировщик задач. Несмотря на то, что в разных источниках он может на зываться поразному (диспетчер задач, супервизор и т. п.), его функции оста ются теми же: определить, какая из за дач должна выполняться в системе в каждый конкретный момент времени. Самым простым методом планирова ния, не требующим никакого специ ального ПО и планировщика как тако вого, является использование цикли ческого алгоритма в стиле round robin: void main (void) { for (;;) { task0(); task1(); task2(); /* и т. д. */ } } Каждая «задача», представляющая со бой отдельную подпрограмму, выпол няется циклически. При этом надо придерживаться следующих правил: 1. Подпрограммы не должны содер жать циклов ожидания в стиле while (TRUE) { if (switch_up()) { lamp_off(); break; } } 2. Подпрограммы должны выполнять свою работу как можно быстрее, что бы дать возможность работать следу ющей подпрограмме. 3. При необходимости подпрограмма может сохранять свое окружение и текущие результаты, чтобы в следую щем цикле возобновить работу с то го же места. Можно отметить следующие преиму щества циклического алгоритма. 1. Простота использования и прозрач ность для понимания. 2. Если исключить из рассмотрения прерывания, система полностью де терминирована. Задачи всегда вызы ваются в одной и той же последова тельности, что позволяет достаточно просто произвести анализ «наихуд шего случая» и вычислить макси мальную задержку. 3. Минимальные размеры кода и дан ных. Кроме того, в отличие от алго ритмов с вытеснением, для всех за дач необходим только один стек. 4. Отсутствуют ошибки, обусловлен ные «гонками». К недостаткам циклического алго ритма можно отнести отсутствие при оритетности и очередей. К тому же за дачи вызываются независимо от того, должны ли они в данный момент что либо делать или нет, а на прикладного программиста ложится максимальная ответственность за работоспособность системы. Перейдем теперь к другому широко используемому алгоритму планирова ния. Речь пойдет о режиме |