cobegin

х:= 1; х:= 2; х:= 3;

coend;

write (x);

Исполнение команд между ключевыми словами cobegin и coend про­исходит параллельно (рис. 2). Пара операторных скобок cobegin-coend приводит к генерации потоков в рамках многозадачной системы. Оператор cobe-gin не накладывает условий на относительный порядок исполнения отдель­ных процессов, а оператор coend достигается только тогда, когда все процес­сы внутри блока завершены. Если бы исполнение было последовательным, то окончательное значение переменной х было бы равно 3. Для параллельных процессов конечный результат однозначно предсказать нельзя; задачи вы­полняются, по крайней мере, с внешней точки зрения, в случайной последо­вательности. Поэтому окончательное значение х в приведенном примере мо­жет быть как 1, так и 2 или 3.

Рисунок 2. - Граф очередности для операторов cobegin – coend

Иногда в технической литературе термин "параллельное программиро­вание" используется как синоним мультипрограммирования. Однако эти по­нятия несколько различаются по смыслу. Параллельное программирование -это абстрактный процесс разработки программ, который потенциально может исполняться параллельно, вне зависимости от программно-аппаратной сре­ды. Иными словами, предполагается, что каждая задача реализуется на соб­ственном виртуальном процессоре. С другой стороны, мультипрограммиро­вание представляет собой практический способ исполнения нескольких про­грамм на одном центральном процессоре или в распределенной вычисли­тельной системе. Параллельное программирование более трудоемко, чем по­следовательное, поскольку способность человека следить за развитием свя­занных процессов, и исследовать их взаимодействие, ограничена.

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

 

Лекция 4.2. Языки программирования реального времени

1. Требования к языкам программирования реального времени.

2. Языки разработки для систем реального времени.

 

1. Требования к языкам программирования реального времени Основными критериями при выборе языка для разработки приложения реального времени являются:

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

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

3. Возможность вызова процедур, написанных на другом языке, на­пример, на языке ассемблера. Из этого требования вытекает, что последова­тельность вызова подпрограмм (механизм именования объектов, передачи аргументов и получения возвращаемого значения) должна быть документи­рована для выбранного языка.

4. Переносимость приложения, под которой обычно понимают, как

возможность его скомпилировать другим компилятором, имеющимся на той же платформе, так и возможность его скомпилировать на другой платформе и/или другой операционной системе.

5. Поддержка объектно-ориентированного подхода стала в послед­нее время необходимостью, зачастую выходя в списке требований на первое место. Это объясняет использование языка Java в ОСРВ.

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

– описание параллельных процессов;

– переключение процессов на основе динамических приоритетов, ко­торые могут изменяться, в том числе и прикладными процессами;

– синхронизацию процессов;

– обмен данными между процессами;

– функции, связанные с часами и таймером, абсолютное и относитель­ное время ожидания;

– прямой доступ к внешним аппаратным портам;

– обработку прерываний;

– обработку исключений.

Немногие языки обеспечивают все эти возможности. Большинство имеет лишь часть из них, хотя для определенных приложений этого оказы­вается достаточно. Некоторые компании разработали специальные языки для поддержки своих собственных аппаратных средств. Эти языки не пре­тендуют на универсальность и ориентированы скорее на конкретные ЭВМ и их интерфейсы. Обычно они базируются на существующих языках - FOR­TRAN, BASIC - с расширениями, включающими функции реального време­ни, о чем свидетельствуют их названия типа "Process BASIC" и "Real-time FORTRAN". Некоторые языки не поддерживают программирования в реальном времени в строгом смысле, но они легко расширяются, например С и C++.

В 1970-е годы широкую поддержку получила концепция единого пе­реносимого многоцелевого языка программирования. В результате был раз­работан язык ADA. Его главная идея состоит в том, что среда программиро­вания, то есть язык, должна быть полностью отделена от аппаратных средств. Программист не должен сталкиваться с деталями машинного уров­ня, а работать только в терминах абстрактных структур и типов данных.

Опыт показал не реалистичность такого подхода. Универсальные, сильно типизированные языки программирования гарантируют определен­ный уровень надежности программы, но в то же время ограничивают гиб­кость. Быстрое развитие технических средств, предъявляет новые требова­ния, которые не могли быть предусмотрены в существующих языках, и мно­гие программисты чувствуют ограничения, используя, не самые современ­ные языки программирования. Цена надежности языка - сложность и гро­моздкость, а генерируемый при этом компилятором код - избыточен и мало­эффективен. Открытый язык типа С, основанный на ограниченном количе­стве базовых идей, обладает большей гибкостью и предоставляет опытному программисту больше возможностей. Не существует наилучшего языка -для каждого приложения и среды необходимо подбирать свои средства и при этом учитывать квалификацию и предпочтения разработчиков.

2. Языки разработки для систем реального времени

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

Язык программирования ADA. Первым полным языком программи­рования в реальном времени является ADA. В середине 1970-х годов Мини­стерство обороны США для сокращения расходов на разработку и сопрово­ждение своих систем управления реального времени приняло решение вве­сти единый язык программирования в качестве альтернативы сотням ис­пользовавшихся тогда языков. В 1979 году министерство одобрило предло­жения, выдвинутые французской компанией Honeywell Bull. Язык назван в честь Августы Ады Байрон, графини Лавлейс (Augusta Ada Byron, Countess of Lovelace, 1815-1852), которую можно считать первым программистом в истории - она писала программы для аналитической машины (механическо­го компьютера, который никогда не был построен), спроектированной анг­лийским изобретателем Чарльзом Бэббиджем (Charles Babbage).

Язык ADA является полной средой разработки программ с текстовым редактором, отладочными средствами, системой управлениями библиотека­ми и т.д. Спецификации ADA закреплены американским стандартом ANSI/MIL-STD-1815A и включают средства контроля соответствия этому стандарту. Не допускаются диалекты языка - для сертификации компилятор должен правильно выполнить все эталонные тесты.

Структура языка ADA похожа на структуру языка Pascal, но его воз­можности значительно шире, в особенности применительно к системам ре­ального времени. Процессу в ADA соответствует задача, которая выполня­ется независимо от других задач на выделенном виртуальном процессоре, то есть параллельно с другими задачами. Задачи могут быть связаны с отдель­ными прерываниями и исключениями, и работать как их обработчики.

Новым понятием, введенным в ADA, является пакет - модуль со свои­ми собственными описаниями типов данных, переменных и подпрограмм, в котором явно указано, какие из программ и переменных доступны извне. Па­кеты могут компилироваться отдельно с последующим объединением в один исполняемый модуль. Это средство поддерживает модульную разработку программ и создание прикладных библиотек. В начале 1990-х годов язык ADA был пополнен новыми функциями для объектно-ориентированного программирования и программирования в реальном времени.

Машинно-ориентированное программирование низкого уровня под­держивается ADA не достаточно эффективно - это следствие постулата, что все задачи должны решаться средствами высокого уровня. Например, для операций ввода/вывода в ADA используются прикладные пакеты с заранее определенными функциями для управления аппаратными интерфейсами и доступа к внешним данным.

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

Языки С и C++. Язык программирования С, несмотря на отсутствие в нем многих средств, которые теоретики считают необходимыми для хороше­го языка программирования, пользуется большим успехом, начиная с 1980-х годов и по настоящее время. Этот язык стал популярным для всех приложе­ний, требующих высокой эффективности, в частности для программ реально­го времени. Для обычных микропроцессоров, используемых в системах управления, имеются С-компиляторы и системы разработки многих произво­дителей. В промышленности существует явная тенденция к широкому при­менению языка С и операционной системы UNIX, которая сама написана на С, поскольку приложения, написанные на С, машинно-независимы и требуют не больших усилий для адаптации к работе в различной аппаратной среде.

Философией С является разбиение программ на функции. С - слаботи-пизированный язык и позволяет программисту делать почти все вплоть до манипуляции с регистрами и битами. Такая свобода делает язык небезопасным, поскольку компилятор не может проверить, являются ли подозритель­ные операции умышленными или нет. Небольшое количество заранее опре­деленных функций и типов данных делает программы легко переносимыми между разными системами. С поддерживает как хороший, структурирован­ный, так и плохой стиль программирования, оставляя ответственность за ка­чество разработки на программисте. Стиль программирования приобретает особое значения при сопровождении программ: плохо написанная и отком­ментированная программа на С - такая же загадка, как и ассемблерский код. Язык С регламентирован международным стандартом ISO 9899.

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

C обеспечивает получение высокой производительности за счет хоро­шо разработанных оптимизирующих компиляторов, которые для современ­ных процессоров часто дают код более эффективный, чем написанный на ас­семблере. Язык C дает прямой доступ к оборудованию и возможность вызова процедур на других языках. Приложения получаются переносимыми (осо­бенно, если ОСРВ поддерживают одинаковый стандарт, например POSIX), однако, объектно-ориентированный подход на уровне языковых конструкций отсутствует.

Язык C++ представляет собой значительно более мощный инструмент, чем С, на основе которого он создан. В C++ значительно улучшена абстрак­ция данных с помощью понятия класса, похожего на абстрактный тип дан­ных с четким разделением между данными и операциями. Классы C++ значительно легче использовать на практике, чем аналогичные понятия в других языках, поскольку C++ поддерживает объектно-ориентированное програм­мирование и поэтапное уточнение типов данных.

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

C++ включает язык C как подмножество и наследует все его положи­тельные качества. C++ добавляет поддержку объектно-ориентированного подхода на уровне языковых конструкций.

Java. Как язык интерпретируемого типа, имеет очень низкую эффек­тивность получаемого кода. Доступ к оборудованию и вызовы процедур на других языках - только посредством библиотечных функций (обычно напи­санных на C). Java обеспечивает наивысшую переносимость приложения на уровне двоичного кода и является объектно-ориентированным языком.

BASIC. Язык BASIC является простейшим среди языков программи­рования высокого уровня. Этот язык был создан в 1964 году для поддержки интерактивной разработки программ с удаленных терминалов. Из-за своей простоты BASIC часто критикуется опытными программистами, и несо­мненно, что этот язык не является хорошим средством для создания боль­ших структурированных систем. С другой стороны, небольшие приложения на BASIC можно разработать значительно быстрее, чем на других языках. Кроме того, BASIC имеется почти на всех мини- и микрокомпьютерах.

Программа на BASIC может компилироваться, но чаще она интерпре­тируется, то есть каждая команда транслируется в машинные коды только в момент ее выполнения. BASIC удобен для разработки небольших приклад­ных задач в составе крупных систем, но его не следует использовать для приложений порядка 500-1000 строк или более. Тем не менее, BASIC является наилучшим средством для непрофессиональных программистов, кото­рым требуется быстро решить частную задачу. Командные языки, основан­ные на BASIC, имеются во многих системах промышленной автоматики. Они применяются для написания простых программ управления без обра­щения к более сложным средствам программирования, требующим компи­ляции и загрузки.

FORTRAN. FORTRAN - это первый язык программирования высокого уровня, который, по-видимому, способствовал, более чем какой-либо другой язык, распространению и практическому применению ЭВМ. Выпущенный в 1957 году, он до сих пор широко используется, в особенности для математи­ческих вычислений. В целом FORTRAN имеет ограниченные возможности определения типа, весьма сложный способ работы с нечисловыми данными и не содержит многих важных функций языков реального времени, чтобы его серьезно рассматривать для этой цели. Новые версии FORTRAN заимствова­ли некоторые возможности из других языков и поддерживают более разви­тые структуры данных. В этом смысле различия между FORTRAN и другими языками сглаживаются.

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

Pascal и Modula-2. Pascal был разработан швейцарцем Николасом Вир-том (Niklaus Wirth) в 1971 году как дидактический язык для обучения хоро­шей технике программирования. Он быстро перерос свои первоначальные рамки и в настоящее время используется во множестве разнообразных при­ложений. Успех Pascal, как в случае BASIC, основан на распространении микро- и персональных компьютеров, на которых он широко используется. Язык Modula-2 был разработан тем же автором в 1975 году специально для программирования встроенных промышленных и научных вычислительных систем реального времени. Pascal и Modula-2 весьма похожи по стилю и структуре, хотя Modula-2 обладает большим количеством функций и синтак­сических конструкций.

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

Языки четвертого поколения (CASE средства). Средства CASE (Computer Aided Software Engenering) получили широкое распространение при разработке приложений реального времени в силу большой сложности последних. Языки «четвертого поколения» представляют собой формализо­ванный способ описания объектов, их свойств и взаимоотношений между со­бой. По этому формальному описанию «компилятор» строит текст приложе­ния на языке более низкого уровня (обычно предоставляется выбор между C/C++/Java). Затем этот текст можно скомпилировать уже «обычным» ком­пилятором. Поскольку можно добавлять фрагменты на языке более низкого уровня, то CASE средства наследуют все положительные свойства последне­го.

 

Лекция 4.3. Программирование асинхронной и синхронной обработки дан­ных

1. Обработка прерываний и исключений.

2. Программирование операций ожидания.

3. Внутренние подпрограммы операционной системы.

4. Приоритеты процессов и производительность системы.

5. Тестирование и отладка.

 

1. Обработка прерываний и исключений

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

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

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

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

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

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

Реакция на исключения (exceptions) похожа на обработку прерываний. Исключениями называются нештатные ситуации, когда процессор не может правильно выполнить команду. Примером исключения является деление на ноль или обращение по несуществующему адресу. В англоязычной литерату­ре для разных видов исключений применяются термины trap, fault, abort (не путать с "взаимным исключением" - mutual exclusion).

Обычно операционная система обрабатывает исключения, прекращая текущий процесс, и выводит сообщение, четко описывающее ситуацию, на устройство отображения, обычно монитор или принтер. Приемлемая при по­следовательной интерактивной многопользовательской обработке, внезапная остановка процесса в системах реального времени должна быть абсолютно исключена. Нельзя допустить, чтобы управляемые микропроцессором авто­пилот самолета или автоматическая тормозная система автомобиля (Auto­matic Braking System - ABS), внезапно прекратили работу из-за деления на ноль. В системах реального времени все возможные исключения должны анализироваться заранее с определением соответствующих процедур обра­ботки.

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

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

2. Программирование операций ожидания

Процесс реального времени может явным образом ждать истечения не­которого интервала (относительное время) или наступления заданного мо­мента (абсолютное время). Соответствующие функции обычно имеют сле­дующий формат:

wait (n)

и

wait until (время)

где n - интервал в секундах или миллисекундах, а переменная "время" имеет формат часы, минуты, секунды, миллисекунды.

Когда выполняется одна из этих функций, операционная система по­мещает процесс в очередь ожидания. После истечения/наступления заданно­го времени процесс переводится в очередь готовых процессов.

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

repeat (*холостой ход*)

until (time = 12:00:00);

Как правило, подобные активные циклы ожидания представляют собой бесполезную трату процессорного времени, и их следует избегать. Однако имеются исключения. В системе, где аналого-цифровое преобразование за­нимает 20 мкс, а операция переключения процессов - 10 мкс, более экономно организовать ожидание на 20 мкс перед тем, как считать новые данные, чем начинать процедуру переключения процессов, неявно подразумеваемую "хо­рошей" операцией ожидания. Каждый случай требует индивидуального под­хода - для этого обычно нужно хорошее знание системы и развитое чутье.

Важной особенностью процессов, запускаемых периодически, - напри­мер, фильтрация и алгоритмы регулирования, - является накопленная ошибка времени. Это связано с тем, что процесс из очереди ожидания события опять попадает в очередь, но уже готовых процессов и должен ждать некоторый случайный интервал времени прежде, чем получит управление (рис. 1а). Требуемое и фактическое время пробуждения процесса не совпадают. Ошибки ожидания накапливаются, если это время рассчитывается так новое время пробуждения = время начала ожидания + интервал По такому алгоритму работает холостой цикл "ждать 10 секунд". Нако­пленная временная ошибка представляет собой сумму времени, проведенно­го в очереди, и времени, необходимого для непосредственного исполнения. Правильное решение получается, если отсчет ведется от момента предыду­щего пробуждения

новое время пробуждения = время предыдущего пробуждения + интервал

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

wait until (ref_time);

ref_time:= ref_time + 10 seconds;

Этот принцип проиллюстрирован на рис. 1б, где номинальное время отложено по горизонтальной оси. Когда абсолютное время принимается в ка­честве опорного, накопления ошибок времени удается избежать.

Рисунок 1. - (а) Неправильный способ определения момента очередно­го запуска периодических задач - ошибка времени накапливается; (б) пра­вильное решение - ошибка времени не накапливается

 

3. Внутренние подпрограммы операционной системы

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

Многие языки программирования высокого уровня, например С, обес­печивают интерфейс с операционной системой для непосредственного вызо­ва ее модулей из исполняемых процессов. Существуют различные виды про­граммных интерфейсов с операционной системой непосредственные вызо­вы, примитивы и доступ через библиотечные модули.

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

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

В некоторых случаях для доступа к внутренним ресурсам операцион­ной системы можно использовать библиотечные модули. Эти модули уже предварительно откомпилированы, и их остается только связать с основной программой. Необходимо проверить по документации системы требуемые параметры, а также механизмы их передачи и редактирования связей в языке высокого уровня.

4. Приоритеты процессов и производительность системы

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

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

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

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

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

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

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

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

5. Тестирование и отладка

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

Выявлять ошибки трудно - многие из них проявляются спорадически и их нельзя воспроизвести по желанию. Никакое доказательство не может га­рантировать, что программа полностью свободна от ошибок, и никакие тесты не могут убедить, что выявлены все ошибки. Цель тестирования - найти как можно большее число ошибок и гарантировать, что программа работает с ра­зумной надежностью. Один из создателей теории операционных систем, Эдс-гер Дейкстра (Edsger Dijkstra), заметил: "Тестирование может доказать толь­ко наличие ошибок, но не их отсутствие".

Тщательный тест требует соответствующей разработки и подготовки; необходимо сочетание практических и аналитических тестов. Сначала тесто­вые процедуры и данные, ожидаемые результаты описываются в специаль­ном документе. В процессе тестирования ведется журнал испытаний, кото­рый затем сравнивается со спецификацией тестов. Желательно, чтобы кол­лектив разработчиков системы отличался от того, который будет определять процедуры испытаний и проводить их.

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