Geum.ru

Автоматизация

Вид материалаДокументы

Содержание


Операционная система реального времени с
Рис 7.1 Схема прохождения запросов Рис. 7.2
Подобный материал:
1   ...   12   13   14   15   16   17   18   19   ...   25
ГЛАВА 7

ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ С

РАЗДЕЛЕНИЕМ ФУНКЦИЙ РАФОС


§ 7.1. ОРГАНИЗАЦИЯ ВЫЧИСЛИТЕЛЬНОГО ПРОЦЕССА


Электронные вычислительные машины типа СМ-4 являются мощными и производительными средствами, возможности которых наиболее полно реализуются в режиме одновременного обслужи­вания многих пользователей. Однако специфика ядерно-физического эксперимента — высокие скорости поступления событий, недо­пустимость задержек при обработке возникающих в установке сигналов, большие объемы обрабатываемой информации — застав-ляют часто ограничивать круг обязанностей вычислительного ком­плекса обслуживанием лишь одной экспериментальной установки. Для управления такими измерительно-вычислительными комп­лексами предназначена ОС реального времени РАФОС. Эта систе­ма отличается минимальным временем ответа на внешнее воздейст­вие, занимает незначительный объем оперативной памяти, имеет развитые средства обслуживания внешних устройств. Наличие фоно-оперативного режима позволяет сочетать обслуживание про­цесса реального времени с проведением отладочных или вычисли­тельных работ.

Структура ОС РАФОС традиционна. Она включает в себя прог­рамму связи с оператором, монитор, драйверы ВУ, обслуживающие программы, файловую систему, системные объектные и макро библиотеки и пр. Важнейшими компонентами ОС являются монитор и драйверы ВУ.

Монитор предназначен для решения трех основных групп задач управления работой программ пользователя, управления файлам» и ведения диалога с оператором.

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

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

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

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

Управление работой программ пользователя осуществляется резидентным монитором RMON (resident monitor). Программа RMON представляет собой наиболее важную часть монитора. Она всегда находится в оперативной памяти в фиксированной области (является резидентной), и с ее помощью реализуется значительная часть функций ОС.

Управление файлами осуществляется программой обслуживания пользователя USR (user service routine). В отличие от RMON, USR в процессе работы ВК может выгружаться на диск и снова загружаться с диска в любую свободную область оперативной памяти. Этим обеспечивается более эффективное использование оперативной памяти программами пользователя.

Взаимодействие оператора и системы РАФОС осуществляется интерактивным монитором KMON (keyboard monitor), который так же, как и USR, является выгружаемой программой. Если в оперативной памяти нет ни фоновой, ни оперативной программ, то активна программа KMON, которая ожидает команд с клавиа­туры терминала.

ОС РАФОС имеет четыре разновидности мониторов: однознач­ный SJ-монитор, фоново-оперативный FB-монитор, фоново-опера-тивный ХМ-монитор, обеспечивающий работу с расширенной па­мятью, и TS-монитор разделения времени.

SJ-монитор не позволяет организовать двухзадачный (фоново-оперативный) режим работы, зато занимает меньше места в опе­ративной памяти и отличается более быстрой реакцией на внеш­нее прерывание по сравнению с FB- и ХМ-мониторами; FB- и ХМ-мониторы обеспечивают двухзадачный режим работы и работают в приципе, одинаково. Различие заключается в том, что XM-монитор использует аппаратуру диспетчера памяти и содержит средства управления расширенной до 124К слов памятью. Все три монитора имеют практически совпадающие наборы команд оператора однако FB-монитор реализует более широкий набор системных макрокоманд, включая макрокоманды связи задач, блокировки и разблокировки задач, обслуживания прерываний и т. д. В XМ-монитор включены макрокоманды динамического управления памятью.

Большие удобства предоставляет включенный во вторую версию:системы РАФОС монитор разделения времени (TS-монитор). Он программно совместим с SJ- и FB-мониторами, однако позволяет организовать многопользовательский многотерминальный режим и, таким образом, существенно повышает эффективность использования ВК и ускоряет процесс разработки и отладки программного обеспечения (если оно с самого начала было ориентировано на систему РАФОС, а не на ОС РВ). К сожалению, программное обеспечение эксперимента и вообще любых задач реального времени системно-ориентированно. Программы реального времени, широко используя средства ОС, могут выполняться только в той ОС, на которую они были рассчитаны. Поэтому перевод Измерительно-вычислительного комплекса, по мере развития его аппаратной конфигурации и расширения решаемых задач с однопользовательского на многопользовательский режим работы с заменой операционной системы РАФОС на ОС РВ, требует полной переработки всех программ реального времени. Использование TS-монитора позволяет заметно упростить этот процесс. Следует, однако, иметь в виду, что средства реального времени в TS-мониторе ограниченны.

В системах управления экспериментом чаще других используется FB-монитор. Именно он подразумевается в последующем изложении.

Другим важнейшим компонентом ОС являются драйверы ВУ, обеспечивающие непосредственное управление ВУ и передачу данными между ВУ и программой пользователя. Следует отметить, что между драйвером и программой пользователя нет непосредственной Связи, она осуществляется через программу RMON (рис. 7.1). Если программа пользователя для осуществления ввода — вывода использует системные средства, которыми для программ на МАКРОАССЕМБЛЕРе являются системные макрокоманды, а для программ на ФОРТРАНе — операторы READ и WRITE, то при каждом запросе в программе пользователя на ввод-вывод происходит обращение к RMON, которая на основании заданных в запросе параметров строит специальную таблицу — элемент очереди. При повторении запросов образуется очередь таких элементов. Каждому драйверу образуется своя очередь. Если очередь к драйверу не пуста, монитор помещает адрес первого элемента очереди в заголовок драйвера (специальная таблица в драйвере, к которой может обращаться монитор) и инициирует работу драйвера. Далее драйвер работает независимо от RMON по пре­рываниям от ВУ. Тем самым создается возможность параллель­ного выполнения программы пользователя и затребованного ею ввода — вывода.




Рис 7.1 Схема прохождения запросов Рис. 7.2 Расположение элементов ОС

ввода – вывода из программы пользователя в памяти после загрузки системы


Хотя драйвер представляет собой, в сущности, обычную прог­рамму, ее непосредственный запуск пользователем невозможен. Драйвер начинает работать только по команде RMON. С другой стороны, загрузкой драйверов в оперативную память управляет пользователь. Все драйверы хранятся на системном диске в файлах, имеющих имена XX.SYS, где XX — условное имя ВУ. Загрузка драйвера в память осуществляется командой оператора LOAD XX в процессе настройки ВК или непосредственно по ходу выполняе­мой программы (динамически) с помощью макрокоманды .FETCH. Второй способ позволяет в случае обслуживания большого ко­личества разнородных ВУ экономить память, загружая драйверы соответствующих ВУ поочередно по мере надобности. Поскольку ВК может нормально функционировать только при наличии опера­тивного общения с системным терминалом и системным диском, драйверы этих ВУ никогда не выгружаются из памяти.

Система РАФОС предназначена прежде всего для ВК, имеющих оперативную память сравнительно небольшого объема (от 8 до 32К слов). В этих условиях возрастает роль рационального расп­ределения памяти между, программами пользователя и элементами ОС. РАФОС имеет специальные средства, повышающие эффектив­ность использования оперативной памяти (выгружаемость прог­рамм KMON и USR, возможность динамической загрузки драй­веров ВУ и др.).

Рассмотрим расположение элементов ОС в оперативной памяти (рис7.2). В старшие адреса памяти непосредственно перед страницей ввода — вывода, т. е. перед адресами регистров ВУ, загружается драйвер системного устройства, с которого была загружена система. Обычно это драйвер НМД. Поскольку функционирование ОС предполагает частое обращение к системному устройству его драйвер является резидентным.

Вслед за драйвером НМД размещается резидентный монитор RMON, занимающий приблизительно 4К слов памяти. Еще выше загружаются программы USR и KMON размером 2К и 4К слов соответственно.

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

По мере загрузки драйверов ВУ и задач пользователя осущестся динамическое перераспределение оперативной памяти. При RMON всегда занимает одну и ту же область памяти всегда резидентен, а компоненты KMON и USR могут смещаться в сторону меньших адресов, предоставляя место для драйверов ВУ, которые командой оператора LOAD загружаются в область, смежную с RMON. Задачи пользователя загружаются с дисков командами оператора FRUN для оперативной задачи и RUN (или ft) для фоновой.

Загрузочный файл X.SAV фоновой задачи (здесь X — проивольное имя файла, a SAV — стандартное расширение имени) при Компоновке получает базовый абсолютный адрес 10008. Любая фоновая задача загружается с этого адреса (рис. 7.3). При этом с адреса 1000 начинается собственно текст задачи, т. е. ее прог­раммные строки и поля данных. Кроме этих компонент задачи в её состав также входят стек задачи, системная область связи и смешанная область задачи.

Стек фоновой задачи располагается непосредственно над задачей и занимает область до адреса 5008 (т. е. 96,0слов). Системная область связи располагается, как уже говорилось, ячейках 40—56. Здесь содержится информация о текущей задаче, используемая монитором и самой задачей. Содержание части ячеек устанавливается системой и из задачи может только читаться. В некоторые ячейки возможна и запись по ходу выполнения прог­раммы. Системная область связи содержит следующие данные:

слово 40 — стартовый адрес задачи;

слово 42 — начальное значение указателя стека (1000 для фо­новой задачи);

слово 44 — слово состояния программы; слово 46 — адрес загрузки USR; . слово 50 — максимальный адрес, принадлежащий задаче;

байт 52 — код ошибки при выполнении программных запросов;

байт 53 — статус завершения программы;

слово 54 — начальный адрес RMON;

слово 56 — информация для специальных терминалов

Назначение части ячеек системной области связи (например стартовый адрес задачи, начальное значение указателя стека или начальный адрес RMON) понятно без объяснений. Назначение и использование некоторых других ячеек будет объяснено позже. Смешанная область фоновой задачи располагается в RMON. Здесь монитор хранит всю необходимую ему информацию о задаче в частности:

адрес списка свободных элементов ввода — вывода;

адрес области каналов ввода — вывода и саму эту область;

указатель на канал, по которому происходит ожидание заверше­ния ввода — вывода;

число неудовлетворенных запросов ввода — вывода;

таблица блокировки задачи;

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

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

имя файла задачи и т. д.

Назначение некоторых полей смешанной области задачи объясняется ниже.

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

Загрузочный файл оперативной задачи X.REL имеет формат, отличный от формата файла X.SAV. Для создания файла X.REL надо в строке вызова компоновщика указать ключ/FOREGROUND. В этом случае компоновщик создает перемещаемый файл, не настроеный на определенный начальный адрес. Файл содержит список строк загрузочного модуля, содержимое которых зависит от расположения задачи в оперативной памяти. Кроме того, в нулевом блоке файла содержится информация о длине всей программы.

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





Как и для фоновой задачи, стек оперативной задачи примыкает к ней со стороны младших адресов (рис. 7.4). Размер стека по умолчанию составляет 64 слова, при этом как длину стека, так и его местоположение можно изменять с помощью соответствующих ключей компоновщика.

Таким образом, каждая задача в РАФОС имеет свой стек. Кроме стеков задач пользователя в составе RMON имеется область системного стека (см. рис. 7.4), который используется монитором при выполнении некоторых системных программ.

Выше стека оперативной задачи расположена ее смешанная область, под которую при загрузке система специально выделяет память. Что же касается системной области связи, то для нее всегда .используются ячейки 40 — 56. В зависимости от того, какая задача выполняется в настоящий момент, эти ячейки автоматически заполняются содержимым, относящимся к данной задаче.

Если загружена только одна оперативная задача, то она распо­лагается между RMON и USR (см. рис. 7.4). При этом KMON и USR находятся в памяти и максимальный размер оперативной задачи, составляет 20К слов. Размер фоновой задачи может быть больше. Если размер фоновой задачи таков, что она накладывается на KMON или USR (но не на оперативную задачу), то система выделяет фоновой задаче необходимую память за счет места, занимаемого ранее программами KMON и USR. При загрузке фоновой задачи та ее часть, которая накладывается на KMON или USR, сначала копируется в специально предусмотренный файл SWAP.SYS. Затем RMON считывает содержимое файла SWAP.SYS на место KMON и USR и запускает задачу.

Если в процессе работы фоновой задачи понадобится USR, то произойдет свопинг: часть фоновой задачи выгружается на диск в файл SWAP.SYS и на освободившееся место с диска загру­жается USR. После того как USR отработает, произойдет восста­новление в памяти фоновой задачи. Таким образом, максимальный размер фоновой задачи (если в памяти нет оперативной задачи и нерезидентных драйверов) составляет 24К слов. Заметим, что фоновая задача может сама загружать необходимые ей драйверы макрокомандой .FETCH. Драйверы, которые будут нужны опера­тивной задаче, должны быть предварительно загружены командой оператора LOAD.

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

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

динамическая загрузка драйверов из фоновой задачи — мак­рокоманда .FETCH;

получение информации о различных ВУ и их драйверах — мак­рокоманда .DSTATUS;

создание нового и открытие имеющегося файла — макроко­манды .ENTER, и .LOOKUP;

закрытие канала файла — макрокоманда .CLOSE;

удаление и преименовывание файлов — макрокоманды .RENAME и .DELETE;

образование дополнительных элементов очереди ввода — выво­да — макрокоманда .QSET;

завершение задачи — макрокоманда .EXIT;

работа с интерпретатором командной строки — макрокоманды .CSIGEN и .GTLIN;

управление самой программой USR — макрокоманды .LOCK и TLOCK.

Программа USR — не реентерабельная (повторно-входимая). Если одна из задач затребовала USR для выполнения какой-либо изперечисленных операций, а после этого USR понадобилась дру­гой задаче, она не сможет выполняться, пока первая задача не ос­вободит USR: Это может привести к неоправданным задержкам в выполнении задач реального времени, особенно если используют­ся сравнительно медленные устройства типа НМЛ. Если, например, фоновая задача производит с помощью USR последовательный поиск на магнитной ленте, а оперативной задаче потребовался USR для какой-либо операции с файлом на магнитном диске, то оперативная задача, несмотря на то что она более приоритетна, может оказаться заблокированной на очень значительное время. Для повышения эффективности выполнения задач реального 1 можно предложить несколько путей.

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

Если начальную (или конечную) фазу оперативной программы также надо выполнить без задержек, можно воспользоваться макрокомандой .LOCK, которая закрепляет за задачей право (Вольного владения USR. После выполнения всех запланированных операций задача запросом .UNLOCK освобождает USR. Такая методика эффективна, когда скорость выполнения фоновой задачи не имеет особенного значения. Если, однако, и оперативная и фоновая задачи обслуживают процессы реального времени, закреплние USR за оперативной задачей может заблокировать фоновую (если ей понадобится USR), что нежелательно. В этом случае можно воспользоваться тем обстоятельством, что блокировка фоновой задачи ожиданием освобождения USR не запрещает выполняться программам обработки прерываний и подпрограммам завершения (подробнее о подпрограммах завершения рассказано в 7.3). Выделив операции реального времени в программы обработки прерываний или подпрограммы завершения, можно избежать »ржек в выполнении этих операций, даже если сама фоновая задача и заблокирована. Другая проблема возникает из-за того, что USR — выгружаемая программа. Как уже отмечалось, если размер фоновой программы таков, что она перекрывает полностью или частично ,область отведенную для KMON и USR, последние выгружаются на диск, а на их место загружается конец фоновой программы. Если в этих условиях оперативной или даже фоновой задаче понадобится USR, то часть фоновой программы выгружается на диск и на это место загружается USR. Режим свопинга позволяет эффективно использовать память, но замедляет выполнение задач, так как на загрузку USR с диска требуется время. Повышению эффективности выполнения задач реального времени в условиях свопинга способствует использование программных запросов .LOCK и. UNLOCK. Если собрать в одно место програм­мы группу программных запросов, требующих USR (например, .ENTER, .LOOKUP и др.), а перед ними предусмотреть запрос .LOCK, то при выполнении этого запроса USR будет скопирована в намять и закреплена за задачей. После завершения работы с USR следует выполнить запрос .UNLOCK. Повышению мобильности USR способствует возможност] загружать ее на любое место в программе пользователя. Адрес загрузки USR помещается (программно, с помощью команды MOV) в ячейку 46 системной области связи. USR можно загрузить например, на место уже отработанных и ненужных в дальнейшел кодов. Это повышает эффективность использования оперативной памяти. Если ячейка 46 специально не загружается, в ней содер жится нулевое значение, которое говорит о том, что место загрузи определяет RMON.

Свопинг полезен в условиях нехватки оперативной памяти. Если ЭВМ оснащена максимальным для FB-монитора РАФОС объемом оперативной памяти (28К слов) и вопрос экономии оперативной памяти не стоит очень остро, можно с помощью команды оператора SET USR NOSWAP сделать USR резидентной (невыгружаемой) что снимет проблемы, связанные со свопингом. Наконец, отказ от оперативно-фонового режима и компоновка всех модулей программного комплекса в один файл X.SAV или X.REL, уменьшая эффективность использования процессора ЭВМ, устраняет в то же время возможность задержек при выполнении задачи из-за захвата USR другой задачей.

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

происходит ожидание завершения ввода — вывода или передачи данных;

программа USR, потребовавшаяся задаче, занята другой зада­чей;

по запросу из программы должен построиться новый элемент очереди, а свободный элемент отсутствует (количество элементов очереди ограничено, хотя и может быть увеличено программным запр.осом .QSET);

завершение фоновой или оперативной задачи; задача блокирована «умышленно» программными запросами .SPND или .TWAIT либо командой оператора SUSPEND.

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

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

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

При переключении задач сохраняется следующая информация:

слово состояния процессора;

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

системная область связи (ячейки 42—52).

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

блокировка задачи;

запуск и прекращение операций ввода — вывода;

обслуживание запросов системного таймера;

выполнение программных запросов .PROTECT и .CHCOPY;

изменение состояния USR;

Обслуживание прерываний;

выполнение программ драйверов ВУ.

Все эти операции так или иначе связаны с прерываниями внешними или внутренними), поэтому причиной перехода в системный режим являются прерывания.

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