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

Вид материала

Документы

Содержание Директивы активизации задач Директивы работы с флагами событий Директива установки временных интервалов Работа с асинхронными системными прерываниями Блокирование задачи Работа с приоритетом задач Директивы ввода—вывода Директивы передачи данных

Подобный материал:

• В. И. Харитонов > К. И. Меша Одобрено методической > С. С. Драгунов комиссией факультета, 321.05kb.
• Темы курсовых проектов Автоматизация учета налогоплательщиков (НП) физических и юридических, 19.54kb.
• Автоматизация бухгалтерского учета нужна ли она?, 216.55kb.
• Программа вступительного экзамена по приему в магистратуру по специальности 6М070200, 225.94kb.
• Автоматизация работы программ расчета, 29.26kb.
• Автоматизация и моделирование работы предприятий по строительству промышленных объектов, 445.96kb.
• Автоматизация процессов мониторинга объектов железнодорожной инфраструктуры на основе, 315.84kb.
• К рабочей программе учебной дисциплины «Интегрированные системы проектирования и управления»», 31.58kb.
• Автоматизация процесса формирования индивидуальных учебных планов в системе переподготовки, 256.55kb.
• Темы курсовых работ По дисциплине «Бухгалтерские информационные системы» Автоматизация, 14.74kb.

§ 8.3. ДИРЕКТИВЫ ОРГАНИЗАЦИИ ВЫЧИСЛИТЕЛЬНОГО ПРОЦЕССА


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

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

Такие координирующие функции выполняет монитор, который и является связующим звеном между всеми задачами в системе и содержит всю информацию о текущем состоянии системы. Пользователь имеет возможность влиять на организацию вычислительного процесса монитором либо при помощи некоторых команд оператора (RUN, Запустить задачу; ABORT, Снять задачу с выполнения; ALTER, Изменить приоритет задачи и т. д.), либо динамически, по запросам из своей задачи на выполнение системных директив организации вычислительного процесса. Эти директивы обеспечивают возможности запуска одной задачи из дру­гой (директива RQST $), прекращения выполнения другой задачи (ABRT $ ), изменения приоритета одной задачи из другой (ALTP $). Задачи могут коорди­нировать свое выполнение при помощи вызова директив работы с флагами собы­тий, используя глобальные флаги событий. Задача может разблокировать другую задачу (директива RQST $), приостановленную директивой SPND $ .

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


Директивы активизации задач

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

; задача Т1

.MCALL RUN $ С, EXIT $ S

RUN $ С Т2..... 10., 3, 30., 2

.

.

EXIT $ S

. MCALL EXIT $ S

.

.

EXIT $ S


Аргументы директивы RUN $ обозначают, что задача Т2 будет запущена первый раз через 10 мин после выполнения программного запроса (цифра 3 является условным обозначением минут), и затем будет периодически запускаться через каждые 30 с (последний аргумент 2 обозначает секунды). Дополнительные запятые в макровызове после первого аргумента стоят на месте неиспользуемых аргументов (имя раздела, приоритет и проч.). Для того чтобы программный запрос RUN $ мог выполниться, задача Т2 предварительно должна быть установ­лена в системе командой оператора INSTALL.

Надо отметить, что после выполнения запроса RUN $, задачи Т1 и Т2 будут выполняться независимо как две равноправные активные задачи. Периодический перезапуск задачи Т2 обеспечивается монитором. Для отмены дальнейшего перезапуска задачи Т2 задача Е1 или другая активная задача должна выдать программный запрос CSRQ $.

Рассмотрим на приведенном примере два механизма активизации задачи в системе. Задачу Т1 необходимо активизировать в начале работы с установкой. Это можно сделать командой оператора RUN Т1, по которой задача Т1 будет установлена в системном каталоге задач и активизирована. Следует отметить, что активизация еще не означает реального выполнения задачи, поскольку любая активная задача конкурирует с другими активными задачами за место в оперативной памяти и время процессора на основе приоритетов. В процессе выполнения задачи Т1 выполняется программный запрос RUN $ , по которому становится активной ранее установленная в системе задача Т2. Первый механизм активизации задач применим для запуска отдельных (не входящих в состав некоторого про­граммного комплекса) задач или для запуска задачи, организующей программный комплекс. Второй механизм используется в программных комплексах.

Другой способ динамического запуска одной задачи из другой — использо­вание системной директивы RQST $. Директива RQST $ обеспечивает однократное выполнение указанной задачи, т. е. является частным случаем директивы RUN $.

Запущенная командой оператора или системными директивами задача остается активной до выполнения программного запроса EXIT $. Выполнение задачи может быть прекращено также системной директивой ABRT $ из другой активной задачи.


Директивы работы с флагами событий

Флаги событий используются как средство для координации выполнения раз­ных частей задачи или различных задач, входящих в состав программного комплекса. Некоторые программные запросы выполняются асинхронно (параллельно) с дальнейшим выполнением издавшей их задачи. Такие запросы используют флаги событий для того, чтобы координировать свое выполнение с выполнением задачи. Например, запрос на ввод—вывод Q10 $ инициирует передачу данных, выполняемую асинхронно с задачей. После постановки запроса на ввод - вывод в очередь запросов к драйверу устройства выполнение задачи продолжается. Обмен инфор­мацией между задачей и ВУ будет теперь обеспечиваться монитором и соответст­вующим драйвером. Вместе с тем для задачи в некоторых случаях важно знать, закончился ли ввод—вывод (предположим, задаче необходимо обрабатывать вве­денную информацию). Монитор, поставив запрос в очередь к драйверу, сбрасывает указанный пользователем флаг события, а после окончания ввода – вывода устанавливает его. Таким образом, установка флага события является для задачи сигналом об окончании ввода - вывода. Задача может также устанавливать или сбрасывать флаги событий для индикации прохождения отдельных участков программы или выполнения некоторых условий.

Для работы с флагами событий имеется ряд системных директив. Эти дирек­тивы позволяют устанавливать флаги (SETF $ ), сбрасывать флаги (CLEF $ ), считывать состояние флагов в задачу пользователя (RDAF $ ), ждать установки определенного флага (WTSE $ ) или любого флага из некоторой группы флагов (WTLO $).

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


.MCALL CLEF $ С, SETF $ С, EXIT $ С, RDAF $ С

BUF: .BLKW 4 ; буфер для флагов

START: .

. ; формирование графического

. ; кадра

FLAG: RDAF $ С BUF ; считывание состояния флага

BIT #—Bl000, BUF+4 ; флаг 36 установлен?

BNE FLAG ; да, ожидание сброса флага

SETF $ С 36. ; нет, индикатор свободен, за-

; хват индикатора

.

. ; вывод кадра на экран

.

CLEF $ С 36. ; кадр больше не нужен, осво-

; бождение индикатора

EXIT $ C


В буфере BUF, куда считываются состояния флагов, под каждый флаг отводится один разряд. Соответственно слово BUF содержит разряды флагов 1 —16, слово BUF+2 — разряды флагов 17—32, слово BUF+4 — разряды флагов 33— 48 и слово BUF+6 — разряды флагов 49—64. Таким образом, для флага 36 отведен разряд 3 слова BUF+4.


Директива установки временных интервалов

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

Следует отметить, что задание временных интервалов с помощью директивы MRKT $ применимо только в тех случаях, когда не требуется высокой точности измерения, так как системный таймер работает с частотой сети (50 Гц). Рассмотрим пример использования директивы MRKT $. Пусть необходимо периодически опрашивать счетчики и выполнять несложную обработку получаемой информации или вывод ее на ВУ после каждого опроса. Всего требуется получить 100 замеров. Для сообщения об окончании временного интервала используем флаги событий:


MCALL MRKT $ С, WTSE $ С, EXIT $ S

COUNT: .WORD 0

Ml: MRKT $ C 4, 10, 3 ; флаг — 4, интервал —

; 10 мин

.

. ; сбор и обработка ин- ; формации


INC COUNT ; счет числа замеров

СМР #100., COUNT

BEQ FIN ; получено 100 замеров

WTSE $ С 4 ; ожидание окончания ин-

; тервала

BR Ml

FIN: EXIT $ S


Директива MRKT $ сбрасывает указанный в ней флаг события и начинает измерение интервала времени. Параллельно с этим продолжается выполнение задачи. После завершения всех запланированных действий (включая отсчет ко­личества выполненных замеров) задача блокируется директивой WTSE $ до тех пор, пока остается сброшенным флаг события. В конце установленного в директиве MRKT $ интервала времени флаг события устанавливается, директива WTSE $ снимает блокировку и команда BR Ml инициирует новый цикл замера и обработки.

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


Работа с асинхронными системными прерываниями

Как уже отмечалось, асинхронные системные прерывания (АСП) позволяют передать управление специальной программе, написанной пользователем (программа обработки АСП) в момент окончания некоторого асинхронного процесса, например ввода - вывода или передачи данных. После завершения этой программы управление передается назад в исходную задачу. Для этого программа обработки АСП должна заканчиваться специальной системной директивой ASTX $. Программы обработки АСП в ОС РВ являются аналогами подпрограмм завершения, используемых в ОС РАФОС.

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


.MCALL MRKT $ C, ASTX $ S, EXIT $ S

START: MRKT $ С 1, 5, 2, ASTS

.

. ; основная программа

.

EXIT $ S

ASTS: MRKT $ С 1, 2, 3, ASTS

.

. ; вывод таблицы

.

TST (SP) +

ASTX $ S

.END START


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

При возникновении АСП в стек задачи заносится информация о состоянии задачи до прерывания, а также некоторая информация, связанная с запросом - источником АСП. Для обеспечения нормального возврата из программы обслужи­вания ДСП с помощью макровызова ASTX $ необходимо предварительно удалить из стека информацию, занесенную туда в процессе перехода на эту программу. Именно это и делает команда TST(SP)+, смещающая указатель на одно слово (куда в данном случае занесен номер флага события, указанный в макровызове MRKT $ ).


Блокирование задачи

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

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

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

Предположим, что задачу реального, времени необходимо приостановить на 30 мин (перерыв между сериями измерений, смена образцов и т. д.). Это можно сделать с помощью директив MRKT $ и SPND $. По окончании указанного в аргументе для MRKT $ временного интервала возникнет АСП и управление будет, передано на программу обработки прерывания. Если в этой программе содержится директива RSUM $ , то блокировка будет снята и задача продолжена:


.MCALL MRKT $ С, SPND $ S, RSUM $ С, EXIT $ S

START:

.

.

MRKT $ С 30., 3, ASTS

SPND $ S ; приостановка задачи


ASTS: RSUM $ C TASK ; разблокировка задачи

TST (SP) +

ASTX $ S ; возврат в задачу


Работа с приоритетом задач

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

при компоновке задачи явно или по умолчанию (в процессе генерации системы указывается значение приоритета, действующего по умолчанию);

заданный при компоновке приоритет задачи можно изменить при ее установке командой оператора INSTALL;

во время выполнения задачи ее приоритет можно изменить командой опертоpa ALTER либо системной директивой ALTP $.

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

Следует различать приоритет задачи (в ОС РВ), приоритет процессора, ус­танавливаемый в слове состояния процессора, приоритет ВУ (уровень прерыва­ния ВУ) и приоритет, с которым работает программа обслуживания ВУ.

Любая задача, независимо от ее приоритета в системе (который, как отмечалось выше, может иметь значение от 1 до 250), выполняется при нулевом значении приоритета процессора, фиксируемого в ССП, т. е. может быть прервана любым из ВУ, приоритет которых устанавливается от 4 до 7. Подпрограмма обслужи­вания внешнего прерывания обычно работает с приоритетом процессора, равным приоритету соответствующего ВУ, т. е. может прерываться ВУ с более высоким приоритетом.

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

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

Задача реального времени с именем FAS запускает процесс набора инфор­мации, изменяет свой приоритет на максимальный и блокируется программным запросом SPND $. В подпрограмме обработки внешнего прерывания происходит считывание информации. После окончания подпрограммы обработки прерывания монитор инициирует асинхронное системное прерывание. В подпрограмме обслу­живания АСП запросом RSUM $ задача разблокируется и, поскольку она имеет наивысший приоритет, немедленно начинает выполняться, например, проводя быструю предварительную обработку информации с целью управления экспери­ментом. После завершения предварительной обработки проводится окончательная обработка, которая уже может выполняться на равных условиях с другими зада­чами на более низком уровне приоритета.

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


.MCALL SPND$ S, RSUM $ С, ALTP $ С, EXIT $ S

START: .

. ; запуск набора информации

.

ALTP $ С , 250

SPND$ S

.

. ; срочная предварительная обработка

.

ALTP $ С , 50

.

. ; окончательная обработка

.

EXIT $ S

ISR: .

. ; п/программа обработки прерываний

.

RTS PC

AST: RSUM $ С FAS ; программа обработки АСП

TST (SP) +

ASTX $ S ; выход из АСП


§ 8.4. ДИРЕКТИВЫ ВВОДА- ВЫВОДА

И ПЕРЕДАЧИ ДАННЫХ


Директивы ввода—вывода

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

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

Для организации ввода—вывода используются директивы ALUN $ , QIO $ и QIOW $ .

Директива ALUN $ позволяет связать конкретное физическое устройство ввода - вывода с логическим номером устройства, который используется в программе и является как бы идентификатором реального физического устройства.

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


DK —НМД типа ИЗОТ-1370;

LP-АЦПУ;

РР —ленточный перфоратор;

RR - ленточный перфосчитыватель;

ТТ — алфавитно-цифровой дисплей;

TI — алфавитно-цифровой дисплей пользователя;

МТ—НМЛ.


Программный запрос ALUN $ должен быть выдан для всех устройств, с кото­рыми будет работать данная программа:


ALUN $ С 2, ТТ, 4

ALUN $ C 3, LP, 0

Здесь присваивается логический номер 2 терминалу № 4 и номер 3 единст­венному АЦПУ LP0.

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

Директива QIOW $ полностью равнозначна директиве QIO $ за тем исклю­чением, что она организует синхронный ввод—вывод. Задача, выставив запрос на ввод—вывод, блокируется до полного окончания передачи данных, после чего продолжает свое выполнение.

Ввиду относительной сложности директив QIO $ и QIOW $ рассмотрим более детально формат директив (на примере директивы QIO $ ):

QIO $ фун, логн, флаг, при, стат, am,

Здесь фун — код функции ввода—вывода;

логн — логический номер устройства (определенный в директиве ALUN $ );

флаг — номер флага события. Не обязателен в директиве QIO $ и обязателен в директиве QIOW $ , которая использует его неявным образом;

при — приоритет (игнорируется, но должен присутствовать);

стат — адрес блока статуса из двух слов, куда директива возвращает код завершения и количество переданных байтов;

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

p1, р2, рЗ..... р6 — параметры, специфические для каждого конкретного физи­ческого устройства.

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


QIO $ фун, логн, ... асп

Здесь указаны параметры фун, логн, и асп; параметры флаг, при и стат опущены, но сохранены распределяющие их запятые; параметры р1, р2, ..., р6 опущены вместе с разделяющими их запятыми, поскольку они стоят последними в списке.

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

Рассмотрим наиболее употребительные функции IO.ATT (Закрепить), IO.RLB (Читать логический блок) и IO.WLB (Писать логический блок).

Функция IO.ATT служит для закрепления указанного ВУ за задачей, выдавшей соответствующую директиву. Запросы других задач на связь с тем же ВУ не будут выполняться, пока первая задача не выдаст директиву QIO $ с функцией IO.DET (Открепить) либо не завершится. Функция IO.АТТ используется для организации связи с устройствами коллективного пользования (например, АЦПУ), чтобы вывод информации из каждой задачи шел сплошным потоком и не прерывался другими задачами.

Пример закрепления за задачей устройства с логическим номером 3:


QIO $ C IO.АТТ, 3


Функция IO.RLB организует чтение логического блока данных с указанного в директиве устройства в буфер, зарезервированный пользователем. Адрес буфера и его размер указываются в списке параметров, специфических для устройства. Размер буфера для клавиатуры терминала должен быть равен 80 байтам. Пример запроса на чтение одной строки текста с клавиатуры терминала:


QIO $ C IO.RLB, 2, 1„ STAT,,


В этой директиве задается устройство с логическим номером 2; указывается номер флага 1, который должен быть установлен после завершения ввода; указываются адрес STAT блока статуса и адрес BUF буфера ввода; определяется размер вводимого блока (80 байт).

Адреса блока статуса и буфера ввода определяются в программе с помощью директив АССЕМБЛЕРа для резервирования памяти;


STAT: .BLKW 2

BUF: .BLKB 80.


Длина строки текста, набираемого на клавиатуре терминала, может быть и меньше 80 символов. В этом случае строка должна заканчиваться нажатием клавиши ВК. Фактическая длинна введенного в буфер текста заносится системой во второе слово блока статуса. В дальнейшем длину введенной строки можно использовать в программе, например, при выводе на печать этого текста.

Функция IO.WLB организует вывод логического блока данных на указанное в директиве устройство. Пример вывода строки теста на АЦПУ:


QIO $ S #IO.WLB,#3,#5, „,<#BUF, STAT+2,#40>


В этой директиве выполняется вывод на устройство с логическим номером 3. При этом определяются: номер флага события 5, который будет установлен после завершения вывода; адрес буфера BUF с выводимым текстом; длина выводимой строки, содержащаяся в слове с адресом STAT+2; код вертикального формата вывода, который определяет число переводов каретки после вывода данной строки. Код, равный восьмеричному числу 40, определяет перевод каретки на следующую строку после завершения вывода. Форма $ S использована для того, чтобы указать число выводимых символов не непосредственно, а через содержимое слова с адресом STAT+2 (при использовании формы $ С это сделать невозможно).

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

IS.SUC (001) — успешное завершение;

IE.ABO (177761) - операция была отменена с помощью функции 10.KIL

(Отменить запрос);

IE.BAD (177777) —неправильный параметр;

1E.DNR (177775) —устройство не готово;

IE.DAA (177770) —устройство уже закреплено за данной задачей;

1E.IFC (177776) —неправильная функция (например, чтение через АЦПУ).


Задача 8.1. Вывести на АЦПУ текст: «??? DATA MISSING ???>


.MCALL ALUN $ C, Q1O $ C, EXIT $ S, WTSE $ C

TEXT: .ASCII /??? DATA MISSING ???/

.EVEN

START: ALUN $ С 1, LP, 0

QIO $ C IO.WLB, 1, 2, ,„

WTSE $ С 2

EXIT $ S

.END START


В вышеприведенной программе макровызов QIO $С должен обязательно сопро­вождаться директивой ожидания флага WTSE $ С, так как в противном случае задача, выставив запрос на вывод, немедленно вышла бы на директиву EXIT $ S и завершилась бы, не успев выполнить вывод (запрос EXIT $ S снимает с выполнения все запросы, выставленные данной задачей). Проще было бы использовать директиву QIOW $ с теми же параметрами.


Задача 8.2. Ввести сообщение с клавиатуры терминала:


MES: .BLKW 80

STAT: BLKW 2

ALUM $ С I, TI

QIOW $ C IO. RLB, 1, 1, ,STAT,,


Задача 8.З. Поставить запрос на ввод с терминала и заблокировать задачу. Если по истечении 30 с ввода нет, снять запрос с выполнения и пустить задачу дальше.


ALUN $ C I, T1

QIOW $ C IO.RLB, 1, 2, „,

MRKT $ С , 30., 2, AST

WTSE $ С 2

.

. ; продолжение задачи

.

AST: QIO $ C IO.KIL, 1

SETF $ C 2

TST (SP) +

ASTX $ S


Директивы передачи данных

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

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

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

Для передачи коротких сообщений и небольших информационных массивов между задачами используются системы директивы передачи данных SDAT $ и RCVD $, которые позволяют задачам обмениваться 13 - словными блоками данных.

Пусть, например, некоторая управляющая задача Т! динамически запускает задачу Т2, которая работает с файлом на магнитном диске. Из задачи Т1 нужно передать имя конкретного файла.

Передача буфера с данными производится программным запросом SDAT $ . В ходе его выполнения монитор формирует элемент очереди передаваемых данных и устанавливает его в очередь запросов на передачу данных задаче Т2. Очередь хранит поступившее требование "до востребования" задачей Т2. Очередь запроса в очередь монитор объявляет важное событие. Это позволяет принимающей задаче синхронизовать свой запрос на прием данных с запросом на передачу передающей программы.

Структура передающей программы Т1 будет выглядеть следующим образом:


.MCALL SDAT $ С, EXIT $ S, ROST $ С


BUFOUT: .BLKW 13. ; буфер для имени файла

START:

; формирование имени файла


RQST $ С T2 ; запуск задачи Т2

SDAT $ С Т2, BUFOUT ; запрос на передачу данных

.

.

.

EXIT $ S


Задача Т2, которая к моменту выдачи запроса RQST $ должна быть установлена в системе, для приема данных выдает программный запрос RCVD $:


.MCALL RCVD $ С, EXIT $ S

BUFIN: .BLKW 15.

START: RCVD $ С Tl.BUFIN

.

.

.

EXIT $ S


При успешном выполнении запроса RCVD $ в задачу Т2 будет передан 15-словный блок информации. Первые два слова будут содержать имя передающей за­дачи в коде RADIX-50; оставшиеся 13 слов будут содержать .передаваемую ин­формацию.

В реальной обстановке может получиться, что принимающая задача выдаст запрос на прием данных раньше, чем передающая успеет сформировать буфер данных и выдать запрос на передачу. Один из способов синхронизации задач заключается в использовании слова состояния директивы. Если в рассматриваемом примере к моменту выполнения запроса RCVD $ очередь данных, передаваемых задаче Т2, пуста, т. е. задача Т1 еще не успела выдать запрос SDAT $ , в слове состояния директивы будет установлен код ошибки IE.ITS (нет данных в очереди сообщений).

Задача Т2, в которой контролируется правильность выполнения запроса RCVD $ , выглядит следующим образом:


.MCALL RCVD $ С, WSIG $ S,EXIT $ S

BUFIN: .BLKW 15.

START: RCVD $ С Т1, BUFIN

BCC GO ; переход на продолжение

; (успешный прием)

CMP #IE. ITS, $ DSW ; нет данных?

BEQ WAIT ; переход на ожидание

.

.

WAIT: WSIG $ S

BR START ; переход на повторную

; попытку приема

EXIT $ S

В приведенном примере отсутствие очереди данных к моменту выполнения программного запроса RCVD $ приведет к переходу на метку WAIT и выдаче запроса WSIG $. Задача Т2 заблокируется до наступления важного события (которым может быть выполнение задачей Т1 запроса SDAT $ ), а после его объявления вновь выдает запрос RCVD $ с проверкой слова состояния директи­вы после выполнения запроса. Этот цикл будет повторяться до удовлетворения запроса на прием данных, после чего задача Т2 продолжит свое выполнение. Следует отметить, что при использовании системных директив SDAT $ и RCVD $ про­исходит непосредственная пересылка данных из буфера одной задачи в буфер другой. В состав монитора входят также системные директивы SREF $ и RREF $, обеспечивающие передачу данных путем передачи друг другу адресов участков памяти, содержащих данные. В этом случае размер данных уже не ограничивается 13 словами.