Cтраница 2
Из предыдущего обсуждения видно, что модель на рис. 7.4 применима для ввода и вывода. Такая асинхронная модель может использоваться в качестве основы для интерфейса еще более высокого уровня, в частности для тех программистов, которые хотели бы рассматривать запросы ввода-вывода как чисто синхронные действия. На самом деле iMAX предоставляет интерфейс синхронного ввода-вывода, который наложен поверх асинхронного интерфейса, проиллюстрированного на рис. 7.4. Синхронный интерфейс описан в разд. [16]
Многопроцессорный вариант ОС РВ поддерживает двухпроцессорный комплекс, имеющий доступ к общей двухвходовой памяти. Все ПУ подключаются к центральному процессору ( ЦП) комплекса, второй процессор выполняет только вычисления. При отсутствии запросов ввода-вывода ЦП выполняет пользовательские задачи. Второй процессор выполняет готовую задачу. [17]
Программы, выполняемые под управлением ДОС РВ, могут быть написаны на языке ФОРТРАН IV, расширенном средствами для работы в реальном масштабе времени. Задачи, написанные на языке ФОРТРАН IV, транслируются в систему. ДОС РВ совместима с ДОС на уровне программных запросов ввода-вывода, форматов загрузочных и объектных модулей, файловой структуры на дисках. [18]
Программы, выполняемые под управлением ДОС РВ, могут быть написаны на языке ФОРТРАН IV, расширенном средствами для работы в реальном времени. Задачи, написанные на языке ФОРТРАН IV, транслируются в ДОС РВ. Система ДОС РВ совместима с ДОС на уровне программных запросов ввода-вывода, форматов загрузочных и объектных модулей, файловой структуры на дисках. В составе ДОС РВ предусмотрены средства для получения версии системы, соответствующей конкретной конфигурации управляющего вычислительного комплекса, а также имеются инструкции по разработке программ-драйверов для дополнительно подключаемых ПУ. [19]
Операция Get asynchronous interface возвращает указатель на запись связи, неявно создаваемую во время создания и инициализации самого синхронного интерфейса. Запись связи - - это тип данных, объявленный в пакете асинхронного интерфейса, который сам по себе является множеством определений и операций, используемых всеми пакетами синхронного интерфейса. Запись связи определяет канал ввода-вывода, использующийся для того, чтобы посылать и получать запросы ввода-вывода и ответные сообщения. [20]
При начальном запуске системы создается системный процесс с нулевым идентификатором 0, который является диспетчером. При нехватке оперативной памяти он осуществляет свопинг выбранных процессов на диск. В системе имеются запросы, позволяющие синхронизировать управление между процессами и создавать так называемые программные каналы, реализующие информационное взаимодействие процессов. Доступ к программному каналу осуществляется при помощи обычных запросов ввода-вывода. [21]
Следует сделать важное замечание: вне зависимости от структуры, использующейся при реализации периферийной подсистемы, ее интерфейс для задач системы i432 может оставаться в точности тем же самым. Стало быть, задача А может реализовать простой ( и неизменный) протокол выполнения операций ввода-вывода. Однако совершенно необязательно, чтобы задача системы i432 ждала такого ответа. В модели, предлагаемой на рис. 7.4, задача А может свободно игнорировать информацию о состоянии в сообщении-ответе. Даже если информация о состоянии не игнорируется, ее распознавание может быть выполнено не сразу же, а по прошествии некоторого заранее определенного числа запросов ввода-вывода. Читатели, знакомые страдицион-ной схемой ввода-вывода с буферизацией, увидят, что использование пула из т объектов типа сообщение имитирует буфер ввода-вывода, размер которого кратен т блокам ввода-вывода, и каждый блок содержит команду, данные и состояние одной операции ввода-вывода. [22]
Как следует возвращать в систему память пассивных объектов. Проектировщики системы 1432 увидели опеределенные практические препятствия, не дающие возможность использовать для эффективного сбора мусора в пассивном пространстве алгоритмы того же типа, которые используются для управления активным пространством. Главная из них - это накладные расходы ввода-вывода. Пассивные объекты могут быть разбросаны по нескольким, возможно отсоединяемым от системы структурам. Для определения, на какие объекты не существует больше ссылок, было бы необходимо просмотреть цепочки пассивных дескрипторов доступа этих объектов, возможно находящихся в разных компонентах системы. Следовательно, в лучшем случае это сведется к долгим поискам, включающим длительные по времени исполнения запросы ввода-вывода. Пассивные дескрипторы доступа имеют тенденцию быть рассеянными по сети пассивных объектов, так же как активные дескрипторы доступа рассеяны по сети активных объектов. Стало быть, следует ожидать не только больших накладных расходов по вводу-выводу, но и значительных затрат времени на освобождение пространства. Недостижимые объекты будут оставаться в системе долгое время, что может привести к неприемлемым оперативным задержкам. [23]