29. Процесс управления вводом/выводом
Управление операциями ввода/вывода в режиме прерываний, требует больших усилий со стороны системных программистов – такие программы создавать сложнее, чем те, что работают в режиме опроса готовности. Примером тому может служить ситуация с драйверами, обеспечивающими печать. Так, в ОС Windows (а именно в Windows 9x) драйвер печати через параллельный порт работает не в режиме с прерываниями, как это сделано в других ОС, а в режиме опроса готовности, что приводит к 100%-й загрузке центрального процессора на всё время печати. При этом, естественно, выполняются и другие задачи, запущенные на исполнение, но исключительно за счёт того, что ОС Windows реализует вытесняющую мультизадачность и время от времени прерывает процесс управления печатью и передаёт центральный процессор остальным задачам.
Для организации использования многими параллельно выполняющимися задачами устройств ввода/вывода, которые не могут быть разделяемыми, введено понятие виртуального устройства (спулинга). Главная задача спулинга – создать видимость параллельного разделения устройства ввода/вывода с последовательным доступом, которое должно быть монопольным и быть закрепленным. Например, каждому вычислительному процессу можно предоставить не реальный, а виртуальный принтер, и поток выводимых символов сначала направить в файл на диске. По окончанию виртуальной печати в соответствии с дисциплиной обслуживания и приоритетами приложений содержимое спул файла выводится на принтер. Системный процесс, управляющий спул файлом, называется спулером.
Рассмотрим синхронный и асинхронный ввод/вывод.
Синхронный ввод/вывод характеризуется тем, что задача, выдавшая запрос на операцию ввода/вывода, переводится супервизором в состояние ожидания завершения указанной операции. Когда супервизор получает от секции завершения сообщение о завершении, он переводит задачу в состоянье готовности к выполнению, и она продолжает свою работу. Синхронный ввод/вывод является стандартным для большинства ОС.
Простейший вариант асинхронного вывода – буферизованный вывод данных на внешнее устройство, при котором данные из приложения передаются не непосредственно на устройство ввода/вывода, а в специальный системный буфер. В этом случае логически операция вывода считается законченной, и задача может не ожидать реального процесса вывода данных на устройство. Процессом реального вывода занимается супервизор ввода/вывода. Асинхронный вывод возможен при наличии двух условий:
в запросе на вывод было указано на необходимость буферизации данных;
устройство вывода допускает асинхронные операции.
Для организации асинхронного ввода необходимо:
выделить область памяти для временного хранения считываемых с устройства данных;
связать выделенный буфер с задачей, заказавшей операцию ввода;
запрос на операцию ввода разбить на две части (два запроса).
В первом запросе указывается операция на ввод данных, как при асинхронном вводе, и имя буфера для вводимых данных. После этого задача продолжает выполнение или переводится в режим ожидания выполнения, но не переводится в ожидания завершения операции ввода/вывода, как при асинхронном вводе. После выполнения некоторого объема программного кода задача выдает второй запрос на завершение операции ввода и, если операция ввода данных завершена к этому времени, то выбирает данные из системного буфера, если операция ввода не завершена, то задача приостанавливается до завершения ввода, как при асинхронном вводе.
Накопители на магнитных дисках обладают крайне низкой скоростью по сравнению с быстродействием центральной части процессора. С учетом того, что операции чтения/записи на диск производятся несколькими большими буферами, средняя скорость работы процессора с оперативной памятью на 2 – 3 порядка выше, чем скорость передачи данных из внешней памяти на магнитных дисках в оперативную память. Чтобы сгладить такое несоответствие в производительности основных подсистем, используется буферирование и/или кэширование данных.
Простейший вариант – использование двойного буферирования: пока в один буфер заносятся данные с магнитного диска, из второго буфера ранее считанные данные могут быть прочитаны запросившей их программой. Аналогичный процесс происходит при записи. Буферирование используется во всех ОС.
Кэширование полезно в том случае, когда программа неоднократно читает с диска одни и те же данные. После того как они один раз будут помещены в кэш, обращение к диску больше не потребуется, и скорость работы программы значительно возрастет. Под КЭШем понимается некий пул буферов, управление которым производится с помощью системного процесса.
Рассмотрим основные системные таблицы ввода/вывода.
Каждая ОС имеет свои таблицы ввода/вывода, их состав (количество и назначение каждой таблицы) может сильно отличаться. В некоторых ОС вместо таблиц создаются списки, хотя использование статических структур данных для организации ввода/вывода, как правило, приводит к большему быстродействию.
Исходя из принципа управления вводом/выводом через супервизор ОС и учитывая, что драйверы устройств ввода/вывода используют механизм прерываний для установления обратной связи центральной части с внешними устройствами, можно сделать вывод о необходимости создания по крайней мере трёх системных таблиц.
Первая таблица (или список) содержит информацию обо всех устройствах ввода/вывода, подключенных к вычислительной системе. Это таблица оборудования (equipment table), а каждый элемент этой таблицы называется UCB (unit control block, блок управления устройством ввода/вывода). Каждый элемент UCB таблицы оборудования, как правило, содержит следующую информацию об устройстве:
тип устройства, его конкретная модель, символическое имя и характеристики устройства;
как это устройство подключено (через какой интерфейс, к какому разъёму, какие порты и линия запроса прерывания используются и т. д.);
номер и адрес канала (и подканала), если такие используются для управления устройством;
указание на драйвер, который должен управлять этим устройством, адрес секции запуска и секции продолжения драйвера;
информация о том, используется или нет буферирование при обмене данными с этим устройством, «имя» (или просто адрес) буфера, если такой выделяется из системной области памяти;
уставка тайм-аута и ячейки для счетчика тайм-аута;
состояние устройства;
поле указателя для связи задач, ожидающих устройство, и, возможно, много ещё каких сведений.
Поскольку во многих ОС драйверы могут обладать свойством реентерабельности (напомним, это означает, что один и тот же экземпляр программного модуля может обеспечить параллельное обслуживание сразу нескольких однотипных устройств), то в элементе UCB должна храниться либо непосредственно сама информация о текущем состоянии устройства и сами переменные для реентерабельной обработки, либо указание на место, где такая информация может быть найдена. Наконец, важнейшим компонентом элемента таблицы оборудования является указатель на дескриптор той задачи, которая сейчас использует данное устройство. Если устройство свободно, то поле указателя будет иметь нулевое значение. Если же устройство уже занято и рассматриваемый указатель не нулевой, то новые запросы к устройству фиксируются посредством образования списка из дескрипторов тех задач, которые сейчас ожидают данное устройство.
Вторая таблица предназначена для реализации ещё одного принципа виртуализации устройств ввода/вывода – независимости от устройства. Желательно, чтобы программист не был озабочен учётом конкретных параметров (и/или возможностей) того или иного устройства ввода/вывода, которое установлено (или не установлено) в компьютер. Для него должны быть важны только самые общие возможности, характерные для данного класса устройств ввода/вывода, которыми он желает воспользоваться. Например, принтер должен уметь выводить (печатать) символы или графическое изображение. А накопитель на магнитных дисках – считывать или записывать по указанному адресу (в координатах C-H-S) порцию данных. Хотя чаще всего программист и не использует прямую адресацию при работе с магнитными дисками, а работает на уровне файловой системы. Однако в таком случае уже разработчики файловой системы не должны зависеть от того, накопитель какого конкретного типа и модели, а также какого производителя используется в данном конкретном компьютере. Важным должен быть только сам факт существования накопителя, имеющего некоторое количество цилиндров, головок чтения/записи и секторов на дорожке магнитного диска. Упомянутые значения количества цилиндров, головок и секторов должны быть взяты из элемента таблицы оборудования. При этом для программиста также не должно иметь значения, каким образом то или иное устройство подключено к вычислительной системе, а не только какая конкретная модель устройства используется. Поэтому в запросе на ввод/вывод программист указывает именно логическое имя устройства. Действительное устройство, которое сопоставляется виртуальному (логическому), выбирается супервизором с помощью таблицы, о которой идет речь. Итак, способ подключения устройства, его конкретная модель и соответствующий ей драйвер содержатся в уже рассмотренной таблице оборудования. Но для того, чтобы связать некоторое виртуальное устройство, использованное программистом при создании приложения с системной таблицей, отображающей информацию о том, какое конкретно устройство и каким образом подключено к компьютеру, используется вторая системная таблица – таблица описания виртуальных логических устройств (DRT, device reference table). Назначение второй таблицы – установление связи между виртуальными (логическими) устройствами и реальными устройствами, описанными посредством первой таблицы оборудования. Другими словами, вторая таблица позволяет супервизору перенаправить запрос на ввод/вывод из приложения на те программные модули и структуры данных, которые (или адреса которых) хранятся в соответствующем элементе первой таблицы. Во многих многопользовательских системах такая таблица не одна, а несколько: одна общая и по одной – на каждого пользователя, что позволяет строить необходимые связи между логическими (символьными) именами устройств и реальными физическими устройствами, которые имеются в системе.
Третья таблица необходима для организации обратной связи между центральной частью и устройствами ввода/вывода. Это таблица прерываний, которая указывает для каждого сигнала запроса на прерывание тот элемент UCB, который сопоставлен данному устройству, подключенному так, что оно использует настоящую линию (сигнал) прерывания. Как системная таблица ввода/вывода, таблица прерываний может в явном виде и не присутствовать. В принципе можно сразу из основной таблицы прерываний попадать на программу обработки (драйвер), имеющей связи с элементом UCB. Важно наличие связи между сигналами прерываний и таблицей оборудования.
В современных сложных ОС имеется гораздо больше системных таблиц или списков, используемых для организации процессов управления операциями ввода/вывода. Например, одной из возможных и часто реализуемых информационных структур, сопровождающих практически каждый запрос на ввод/вывод, является блок управления данными (data control block, DCB). Назначение этого DCB – подключение препроцессоров к процессу подготовки данных на ввод/вывод, то есть учет конкретных технических характеристик и используемых преобразований. Это необходимо для того, чтобы имеющееся устройство получало не какие-то непонятные ему коды либо форматы данных, которые не соответствуют режиму его работы, а коды, созданные специально под данное устройство и используемый в настоящий момент формат представления данных.
Рассмотрим процесс управления вводом/вывода с помощью рис. 12.2.
Запрос на операцию ввода/вывода от выполняющейся программы поступает на супервизор (действие 1). Тот проверяет системный вызов на соответствие принятым спецификациям и в случае ошибки возвращает задаче соответствующее сообщение (действие 1–1). Если же запрос корректен, то он перенаправляется в супервизор ввода/вывода (действие 2).
Рис. 12.2. Процесс управления вводом/выводом
Последний по логическому (виртуальному) имени с помощью таблицы DRT находит соответствующий элемент UCB в таблице оборудования. Если устройство уже занято, то описатель задачи, запрос которой сейчас обрабатывается супервизором ввода/вывода, помещается в список задач, ожидающих настоящее устройство. Если же устройство свободно, то супервизор ввода/вывода определяет из UCB тип устройства и при необходимости запускает препроцессор, позволяющий получить последовательность управляющих кодов и данных, которую сможет правильно понять и отработать устройство (действие 3). Когда «программа» управления операцией ввода/вывода будет готова, супервизор ввода/вывода передаст управление соответствующему драйверу на секцию запуска (действие 4). Драйвер инициализирует операцию управления, обнуляет счётчик тайм-аута и возвращает управление супервизору (диспетчеру задач) с тем, чтобы он поставил на процессор готовую к исполнению задачу (действие 5). Система работает своим чередом, но когда устройство ввода/вывода отработает посланную ему команду, оно выставляет сигнал запроса на прерывания, по которому через таблицу прерываний управление передаётся на секцию продолжения (действие 6). Получив новую команду, устройство вновь начинает её обрабатывать, а управление процессором опять передаётся диспетчеру задач, и процессор продолжает полезную работу. Таким образом, получается параллельная обработка задач, на фоне которой процессор осуществляет управление операциями ввода/вывода.
Если имеются специальные аппаратные средства для управления вводом/выводом, снимающие эту работу с центрального процессора (речь идет о каналах прямого доступа к памяти), то в функции центрального процессора будут по-прежнему входить все только что рассмотренные шаги, за исключением последнего – непосредственного управления операциями ввода/вывода. В случае использования каналов прямого доступа к памяти последние исполняют соответствующие канальные программы и разгружают центральный процессор, избавляя его от непосредственного управления обменом данными между памятью и внешними устройствами.