Modifydata; end

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

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

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

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

Глагол to await имеет значение не только "ждать", но и "предстоять", то есть конструкцию await (А) можно трактовать, как "предстоит событие А". Глагол to cause означает "быть причиной", побудительным мотивом, "вы­звать что-либо". Конструкция cause (А) интерпретируется как "вызвать собы­тие А" (в литературе и в операционных системах иногда используются и дру­гие названия).

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

var mutex: semaphore; change: event;

Begin

while not condition do await (change); wait (mutex);

(* обработка общих переменных *) signal (mutex); cause (change);

end;

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

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

 

Лекция 3.4. Обмен информацией между процессами

1. Общие области памяти.

2. Почтовые ящики.

3. Каналы.

4. Удаленный вызов процедур.

5. Сравнение методов синхронизации и обмена данными.

 

1. Общие области памяти

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

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

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

2. Почтовые ящики

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

Рисунок 1. - Работа почтового ящика

 

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

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

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

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

put_mailbox (# 1, message)

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

get _mailbox (# 1, message)

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

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

3. Каналы

Канал (pipe) представляет собой средство обмена данными между дву­мя процессами, из которых один записывает, а другой считывает символы. Этот механизм был первоначально разработан для среды UNIX как средство перенаправления входа и выхода процесса. В ОС UNIX физические устрой­ства ввода/вывода рассматривают как файлы, а каждая программа имеет стандартное устройство ввода (вход) и стандартное устройство вывода (выход), клавиатуру и экран монитора - можно переопределить, например, с по­мощью файлов. Когда выход одной программы перенаправляется на вход другой, создается механизм, называемый каналом (в операционных системах для обозначения канала используется символ "|"). Каналы применяются в операционных системах UNIX, OS/9 и Windows NT в качестве средства связи между процессами (программами).

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

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

Благодаря тому, что ввод/вывод в файл и на физические устройства и вход/выход процессов трактуются одинаково, каналы являются естествен­ным средством взаимодействия между процессами в системах "клиент-сервер". Механизм каналов в UNIX может в некоторых случаях зависеть от протокола TCP/IP, а в Windows NT каналы работают с любым транспортным протоколом. Следует иметь в виду, что внешне простой механизм каналов может требовать больших накладных расходов при реализации, особенно в сетевых системах.

4. Удаленный вызов процедур

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

Однако основной процедурой обмена данными и синхронизации в сре­де "клиент-сервер" является удаленный вызов процедур (Remote Procedure Call - RPC). Последний может рассматриваться как вызов подпрограммы, при котором операционная система отвечает за маршрутизацию и доставку вызова к узлу, где находится эта подпрограмма. Нотация обращения к про­цедуре не зависит от того, является ли она локальной или удаленной по от­ношению к вызывающей программе. Это существенно облегчает програм­мирование.

В системе реального времени существенно, является RPC блокирую­щим или нет. Блокирующий RPC не возвращает управление вызывающему процессу, пока не закончит свою работу, например, пока не подготовит дан­ные для ответа. Неблокирующие RPC возвращают управление вызывающей процедуре по истечении некоторого времени (time out) независимо от того, завершила ли работу вызываемая процедура; в любом случае вызывающая программа получает код, идентифицирующий результат выполнения вызова, - код возврата. Таким образом, неблокирующие RPC имеют важное значение, с точки зрения гарантии живучести системы.

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

Например, семафор эквивалентен почтовому ящику, в котором накап­ливаются сообщения нулевой длины, - операции signal и wait эквивалентны операциям put и get почтового ящика, а текущее значение семафора эквива­лентно числу помещенных в почтовый ящик сообщений. Аналогично можно организовать взаимное исключение и защиту ресурсов с помощью почтовых ящиков. В этом случае сообщение выполняет функцию "маркера". Процесс, получивший этот "маркер", приобретает право входить в критическую сек­цию или распоряжаться ресурсами системы. При выходе из секции или осво­бождении ресурса процесс помещает "маркер" в почтовый ящик. Следующий процесс читает из почтового ящика, получает "маркер" и может войти в кри­тическую секцию.

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

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

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

 

Тема 4. Особенности программирования систем реального времени

Лекция 4.1. Методы программирования в реальном времени.

1. Последовательное программирование и программирование задач ре­ального времени

2. Среда программирования.

3. Структура программы реального времени.

4. Параллельное программирование, мультипрограммирование и мно­гозадачность.

 

1. Последовательное программирование и программирование задач ре­ального времени

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

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

Последовательное программирование (sequential programming) явля­ется наиболее распространенным способом написания программ. Понятие "последовательное" подразумевает, что операторы программы выполняются в известной последовательности один за другим. Целью последовательной программы является преобразование входных данных, заданных в опреде­ленной форме, в выходные данные, имеющие другую форму, в соответствии с некоторым алгоритмом - методом решения (рис. 1).

Рисунок 1. - Обработка данных последовательной программой

 

Таким образом, последовательная программа работает как фильтр для исходных данных. Ее результат и характеристики полностью определяются входными данными и алгоритмом их обработки, при этом временные показа­тели играют, как правило, второстепенную роль. На результат не влияют ни инструментальные (язык программирования), ни аппаратные (быстродейст­вие ЦП) средства: от первых зависят усилия и время, затраченные на разра­ботку и характеристики исполняемого кода, а от вторых - скорость выполне­ния программы, но в любом случае выходные данные будут одинаковыми.

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

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

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

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

1. Логика исполнения программы определяется внешними событиями.

2. Программа работает не только с данными, но и с сигналами, посту­пающими из внешнего мира, например, от датчиков.

3. Логика развития программы может явно зависеть от времени.

4. Жесткие временные ограничения. Невозможность вычислить резуль­тат за определенное время может оказаться такой же ошибкой, как и невер­ный результат ("правильный ответ, полученный поздно - это неверный от­вет").

5. Результат выполнения программы зависит от общего состояния сис­темы, и его нельзя предсказать заранее.

6. Программа, как правило, работает в многозадачном режиме. Соот­ветственно, необходимы процедуры синхронизации и обмена данными меж­ду процессами.

7. Исполнение программы не заканчивается по исчерпании входных данных - она всегда ждет поступления новых данных.

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

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

2. Среда программирования

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

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

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

Важно как можно раньше выяснить функции, обеспечиваемые имею­щейся средой, и возможные альтернативы. Например, микропроцессор Mo­torola 68000 имеет в своем наборе команд инструкцию test_and_set, и поэто­му связь между задачами может осуществляться через общие области памя­ти. Операционная система VAX/VMS поддерживает почтовые ящики, и син­хронизировать процессы можно с помощью механизма передачи сообщений.

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

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

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

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

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

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

3. Структура программы реального времени

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

Например, задачи для управления движением манипулятора робота можно организовать следующим образом:

– считать с диска описание траекторий;

– рассчитать следующее положение манипулятора (опорное значение);

– считать с помощью датчиков текущее положение;

– вычислить необходимый сигнал управления;

– выполнить управляющее действие;

– проверить, что опорное значение и текущее положение совпадают в пределах заданной точности;

– получить данные от оператора;

– остановить робота в случае нештатной ситуации (например, сигнал прерывания от аварийной кнопки).

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

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

while true do (*бесконечный цикл*) begin (*процедура обработки*) wait event at #2,28 (*внешнее прерывание*) (*код обработки*) … end; (*процедура обработки*)

end. (*выход из программы; никогда не достигается*)

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

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

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

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

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

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

4. Параллельное программирование, мультипрограммирование и мно­гозадачность

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

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

Для записи параллельных процессов можно использовать следующую нотацию