Лекции по дисциплине системы реального времени тема аппаратнопрограммные средства и комплексы реального времени
 Скачать 1.67 Mb.
|
|
Лекция 3.4. Обмен информацией между процессами 1. Общие области памяти. 2. Почтовые ящики. 3. Каналы. 4. Удаленный вызов процедур. 5. Сравнение методов синхронизации и обмена данными. 1. Общие области памяти Взаимодействующие процессы нуждаются в обмене информацией. Поэтому многозадачная операционная система должна обеспечивать необходимые для этого средства. Обмен данными должен быть прозрачным 91 для процессов, т.е. передаваемые данные не должны изменяться, а сама процедура должна быть легко доступна для каждого процесса. Простейший метод - использование общих областей памяти, к которым разные процессы имеют доступ для чтения/записи. Очевидно, что такая область представляет собой разделяемый ресурс, доступ к которому должен быть защищен, например, семафором. Главное преимущество общих областей памяти заключается в том, что к ним можно организовать прямой и мгновенный доступ, например один процесс может последовательно записы- вать поля, а другой затем считывать целые блоки данных. При программировании на машинном уровне общие области размеща- ются в оперативной памяти по известным адресам. В языках высокого уровня вместо этого используются глобальные переменные, доступные нескольким дочерним процессам. Так, например, происходит при порождении потоков, для которых переменные родительского процесса являются глобальными и работают как общие области памяти. В случае возможных конфликтов дос- тупа к общим областям они должны быть защищены семафорами. 2. Почтовые ящики Другой метод, позволяющий одновременно осуществлять обмен дан- ными и синхронизацию процессов, - это почтовые ящики. Почтовый ящик представляет собой структуру данных, предназначенную для приема и хра- нения сообщений (рис. 1). Для обмена сообщениями различного типа можно определить несколько почтовых ящиков. Рисунок 1. - Работа почтового ящика Во многих операционных системах почтовые ящики реализованы в виде логических файлов, доступ к которым аналогичен доступу к физическим файлам. С почтовыми ящиками разрешены следующие операции: создание, открытие, запись/чтение сообщения, закрытие, удаление. В некоторых системах поддерживаются дополнительные служебные функции, например счетчик сообщений в почтовом ящике или чтение сообщения без удаления его из ящика. Почтовые ящики размещаются в оперативной памяти или на диске и существуют лишь до выключения питания или перезагрузки. Если они физи- чески расположены на диске, то считаются временными файлами, уничто- жаемыми после выключения системы. Почтовые ящики не имеют имен по- добно реальным файлам - при создании им присваиваются логические иден- тификаторы, которые используются процессами при обращении. Для создания почтового ящика операционная система определяет ука- затели на область памяти для операций чтения/записи и соответствующие переменные для защиты доступа. Основными методами реализации являются 92 либо буфер, размер которого задается при создании ящика, либо связанный список, который, в принципе, не накладывает никаких ограничений на число сообщений в почтовом ящике. В наиболее распространенных реализациях процесс, посылающий со- общение, записывает его в почтовый ящик с помощью оператора, похожего на оператор записи в файл put_mailbox ( # 1, message) Аналогично, для получения сообщения процесс считывает его из поч- тового ящика с помощью оператора вида get _mailbox (# 1, message) Запись сообщения в почтовый ящик означает, что оно просто копиру- ется в указанный почтовый ящик. Может случиться, что в почтовом ящике не хватает места для хранения нового сообщения, то есть почтовый ящик либо слишком мал, либо хранящиеся в нем сообщения еще не прочитаны. При чтении из почтового ящика самое старое сообщение пересылается в принимающую структуру данных и удаляется из ящика. Почтовый ящик -это пример классической очереди, организованной по принципу FIFO. Операция чтения из пустого ящика приводит к различным результатам в зависимости от способа реализации — либо возвращается пустая строка (нулевой длины), либо операция чтения блокируется до получения сообщения. В последнем случае, чтобы избежать нежелательной остановки процесса, необходимо предварительно проверить число сообщений, имеющихся в данный момент в ящике. 3. Каналы Канал (pipe) представляет собой средство обмена данными между дву- мя процессами, из которых один записывает, а другой считывает символы. Этот механизм был первоначально разработан для среды UNIX как средство перенаправления входа и выхода процесса. В ОС UNIX физические устрой- ства ввода/вывода рассматривают как файлы, а каждая программа имеет стандартное устройство ввода (вход) и стандартное устройство вывода (выход), клавиатуру и экран монитора - можно переопределить, например, с помощью файлов. Когда выход одной программы перенаправляется на вход другой, создается механизм, называемый каналом (в операционных системах для обозначения канала используется символ "|"). Каналы применяются в операционных системах UNIX, OS/9 и Windows NT в качестве средства связи между процессами (программами). Каналы можно рассматривать как частный случай почтового ящика. Различие между ними заключается в организации потока данных - почтовые ящики работают с сообщениями, то есть данными, для которых известны формат и длина, а каналы принципиально ориентированы на неструктуриро- ванные потоки символов. В некоторых операционных системах, однако, воз- можно определить структуру передаваемых по каналу данных. Обычно про- цесс, выполняющий операцию чтения из канала, ждет, пока в нем не появят- ся данные. В настоящее время операционные системы включают методы, по- 93 зволяющие избежать блокировки программы, если это нежелательно с точки зрения ее логики. Операции над каналами эквивалентны чтению/записи физических файлов. Они включают функции, как определить, открыть, читать, записать, закрыть, удалить. Дополнительные операции могут устанавливать флаги ре- жима доступа, определять размер буфера и т.д. Благодаря тому, что ввод/вывод в файл и на физические устройства и вход/выход процессов трактуются одинаково, каналы являются естественным средством взаимодействия между процессами в системах "клиент-сервер". Механизм каналов в UNIX может в некоторых случаях зависеть от протокола TCP/IP, а в Windows NT каналы работают с любым транспортным протоколом. Следует иметь в виду, что внешне простой механизм каналов может требовать больших накладных расходов при реализации, особенно в сетевых системах. 4. Удаленный вызов процедур Модель "клиент-сервер" построена на обмене сообщениями "регуляр- ной" структуры, которые можно передавать, например, через механизм ка- налов. Однако основной процедурой обмена данными и синхронизации в среде "клиент-сервер" является удаленный вызов процедур (Remote Procedure Call - RPC). Последний может рассматриваться как вызов подпрограммы, при котором операционная система отвечает за маршрутизацию и доставку вызова к узлу, где находится эта подпрограмма. Нотация обращения к про- цедуре не зависит от того, является ли она локальной или удаленной по от- ношению к вызывающей программе. Это существенно облегчает програм- мирование. В системе реального времени существенно, является RPC блокирую- щим или нет. Блокирующий RPC не возвращает управление вызывающему процессу, пока не закончит свою работу, например, пока не подготовит дан- ные для ответа. Неблокирующие RPC возвращают управление вызывающей процедуре по истечении некоторого времени (time out) независимо от того, завершила ли работу вызываемая процедура; в любом случае вызывающая программа получает код, идентифицирующий результат выполнения вызова, - код возврата. Таким образом, неблокирующие RPC имеют важное значение, с точки зрения гарантии живучести системы. 5. Сравнение методов синхронизации и обмена данными Может показаться, что основные задачи, связанные с параллельным программированием, взаимным исключением, синхронизацией и коммуни- кациями между процессами, имеют мало общего, но, в сути - это просто раз- ные способы достижения одной цели. Методы синхронизации можно ис- пользовать для организации взаимного исключения и коммуникаций. Анало- гично, с помощью техники коммуникаций между процессами можно реали- зовать функции синхронизации и взаимного исключения процессов. Например, семафор эквивалентен почтовому ящику, в котором накап- ливаются сообщения нулевой длины, - операции signal и wait эквивалентны 94 операциям put и get почтового ящика, а текущее значение семафора эквива- лентно числу помещенных в почтовый ящик сообщений. Аналогично можно организовать взаимное исключение и защиту ресурсов с помощью почтовых ящиков. В этом случае сообщение выполняет функцию "маркера". Процесс, получивший этот "маркер", приобретает право входить в критическую сек- цию или распоряжаться ресурсами системы. При выходе из секции или осво- бождении ресурса процесс помещает "маркер" в почтовый ящик. Следующий процесс читает из почтового ящика, получает "маркер" и может войти в кри- тическую секцию. Связь между разными подходами имеет практическое значение в том случае, если в системе применяется только один из них, а все остальные нужно строить на его основе. Современные операционные системы, поддер- живающие многозадачный режим и операции в реальном времени, применя- ют все упомянутые методы. Передача сообщений и доступ к общим областям памяти медленнее, чем проверка и обновление семафора и переменной собы- тия, и требует дополнительных накладных расходов. Если есть выбор между различными методами синхронизации и взаимодействия, следует использо- вать тот из них, который лучше решает конкретную проблему - результи- рующая программа будет понятнее и, возможно, быстрее работать. Кроме то- го, весьма важно оценить, насколько эффективно в имеющейся программной среде реализуются конкретные решения. Следует избегать незнакомых и не- естественных конструкций. В распределенных системах всегда существует риск потерять сообще- ние в сети. Если сетевая система сконфигурирована так, что она контролиру- ет правильность передачи сообщения, и имеются средства для повторной пе- редачи утраченных сообщений, то прикладная программа не должна осуще- ствлять дополнительные проверки. Обычно нижний уровень операционной системы и процедуры сетевого интерфейса передают на более высокий уровень код возврата, который прикладная программа должна проверить, чтобы убедиться, была ли попытка успешной или нет, и при необходимости повторить ее. Если контроль не предусмотрен, например, используется служба IP без транспортного протокола TCP, то прикладная программа несет ответственность за проверку результата передачи. Эта операция сложнее, чем это кажется. Можно использовать сообщение, подтверждающее прием, но нет гарантии, что оно само, в свою очередь, не будет потеряно и отправитель не начнет новую передачу. Эта проблема не имеет общего решения - стратегии передачи сообщений должны в каждом случае рассматриваться индивидуально. Возможным решением является помечать и нумеровать каждое сообщение таким образом, чтобы отправитель и получатель могли следить за порядком передачи. Этот метод используется в некоторых типах коммуникационных протоколов. Лекция. 3.5. Операционные системы реального времени для интеллектуальных информационных систем 95 1. Обзор основных направлений развития операционных систем реального времени. 2. Операционная система Spox. 3. Операционная система Multiprox. 4. Операционная система VCOS. 5. Операционная система DEASY. 6. Операционная система UNIX. 7. Операционная система OSF/1 и DСЕ. 8. Операционная система VAX/VMS. 1. Обзор основных направлений развития операционных систем реального времени Операционные системы реального времени (ОСРВ) используются в тех случаях, когда работоспособность обслуживаемой ими цифровой системы определяется не только результатом обработки поступившей информации, но и длительностью времени получения результата. Области практического применения ОСРВ очень широки. Это системы автоматизации производства, контрольно-измерительные системы, телекоммуникационная аппаратура, авиационно-космическая и военная техника, транспорт, системы обеспечения безопасности и ряд других приложений. В этих приложениях ОСРВ должна обеспечить не только получение необходимого логического результата — отклика на внешние события, но и реализовать требуемые интервалы времени между событиями и откликом или заданную частоту приема внешних данных и выдачи результатов. Современные ОСРВ должны удовлетворять ряду противоречивых тре- бований: малый объем, достаточный для размещения в резидентной памяти системы; малое время отклика; реализация многозадачного режима с гибким механизмом приоритетов, наличие сервисных функций и средств поддержки для разработки прикладных программ и ряд других. В настоящее время раз- работчику систем предлагается ряд ОСРВ, имеющих различные харак- теристики и прошедших апробацию в многочисленных областях применения, что позволяет ему найти компромиссное решение для выполнения постав- ленной задачи. Наиболее часто в системах на базе микропроцессоров и мик- роконтроллеров фирмы Motorola используются следующие ОСРВ: OS-9 фирмы Microware Systems; VxWorks фирмы WindRiver Systems; LynxOS фирмы Lynx Real-Time Systems; pSOS+ фирмы Integrated Systems; QNX фир- мы Quantum Software Systems; VRTX/OS 3.0 фирмы Ready Systems; Nucleus фирмы Accelerated Technology; RTXC фирмы Embedded System Products; OSE фирмы Enea Data, Precise/MQX фирмы Intermetrics Microsystems Software; VMEexec фирмы Motorola. Подразделяют ОСРВ на два класса - системы "жесткого" и "мягкого" реального времени (РВ). Системы "жесткого" РВ имеют минимальные объем и время отклика, но обладают ограниченными сервисными средствами. Ти- пичным примером ОСРВ этого класса служит VMEexec. Системы "мягкого" РВ требуют большего объема памяти, имеют более длительное время откли- 96 ка, но удовлетворяют широкому спектру требований пользователя по режиму обслуживания задач, уровню предоставляемого сервиса. Примером такой ОСРВ может служить OS-9/9000. Однако для современных ОСРВ данная классификация является весьма условной. Ряд ОСРВ, относящихся к классу "жестких", имеют средства интерфейса, которые позволяют, в случае необходимости, использовать высокоэффективные отладчики или интегрированные среды разработки, обеспечивая, таким образом, пользователя набором средств поддержки программирования-отладки систем. Например, VMEexec может использоваться совместно с интегрированной средой MULTI фирмы GreenHills Software, VxWorks с интегрированной средой Tornado, в составе которой поставляются отладчик CrossWind и GNU-компиляторы фирмы Cygnus Support, VRTX и pSOS с отладчиком XRAY и компиляторами фирмы Microtec Research. С другой стороны, системы "мягкого" РВ реализуются по модульному принципу, что позволяет использовать только те средства, которые необходимы в данном приложении. В результате для конкретного применения достигается существенное сокращение объема необходимой памяти и времени отклика. Например, для ядра OS9/9000 время отклика не превышает 20 мкс (для VMEexec, VxWorks, pSOS - менее 10 мкс), что является вполне достаточным для многих приложений. Для создания многопроцессорных систем, работающих в режиме ре- ального времени (РВ), необходимо базовое программное обеспечение, а именно операционная система. ПО этого направления делится на две боль- шие группы. К первой группе можно отнести небольшие модули, загружае- мые на ЦОС-процессоре, а также библиотеки подпрограмм для основного процессора, позволяющие реализовать обмен данными. ЦОС-процессор в та- кой системе является подчиненным процессором, управляемым основным (host-процессором). Организация функций систем РВ основана на обработке прерываний и механизме обмена сообщениями. Главное достоинство этих систем – небольшая цена. К системам этого типа можно отнести VCOS и DEASY. Вторая группа операционных систем – это операционные системы ре- ального времени типа Spox или Multiprox. Цена этих систем составляет по- рядка 20-40 тыс. долларов, но возможности их значительно выше. Операци- онная система Spox фирмы Spectron Microsystems – одна из ведущих систем, используемых в системах РВ для различных применений, в том числе на платформах с модулями ЦОС. Spox – это специализированная операционная система реального времени, создающая операционное окружение для прило- жений по обработке данных в реальном режиме. Другая система – Multiprox фирмы Comdisco. Multiprox – это система разработки, которая позволяет инженерам графически формировать прило- жения и разделять ЦОС-задачи для нескольких ЦОС-процессоров. 2. Операционная система Spox Spox (создана фирмой Spectron в 1987 г.) является операционной сис- темой, которая структурирована для обработки сигналов и приложений с ин- 97 тенсивной математикой. Это высокоуровневое окружение для приложений имеет простые в использовании свойства, включая независимый от устройств ввод-вывод, удобные установки процессора и интерфейс с основной маши- ной (имеется в виду основная ОС). Spox обеспечивает объектно- ориентированную модель для ЦОС и математической обработки. В последние годы фирма Spectron ввела OSPA (открытая архитектура обработки сигналов) – расширение к Spox для ЦОС-приложений на основной машине. Запускаясь под MS Windows, OSPA обеспечивает интерфейс на уровне основной машины. Используя этот интерфейс, host-приложения могут планировать и контролировать работу многочисленных программ на ЦОС- сопроцессорах (но это не параллельная обработка). OSPA является своего рода интерфейсом API (интерфейсом прикладных программ), который облег- чает интеграцию ЦОС-обработки в интерактивное приложение. Spectron изначально развивал Spox для TMS320C30, но сейчас опера- ционная система запускается также и на Motorola 96002, TI C40 и Analog Device 21020. Spectron также выпускает версию Spox для параллельной обра- ботки. Используемая модель обработки сообщений поддерживает многоза- дачность. Многозадачное расширение построено вокруг примитивов, осно- ванных на сообщениях, и может обеспечить высокоскоростную передачу данных через каналы ввода-вывода. Spox позволяет совместно использовать память, установленную на отдельном модуле. SPOX поставляется в следую- щих четырех основных конфигурациях. |