Файл: А. В. Гордеев А. Ю. Молчанов системное программное обеспечение электронный вариант книги издательства Питер СанктПетербург Челябинск юургу каф. Автоматика и управление 2002 2 Предисловие Настоящий учебник.pdf

166
ляющих никакой ценности. Однако можно каждому вычислительному процессу предоставлять не реальный, а виртуальный принтер и поток выводимых символов
(или управляющих кодов для их печати) сначала направлять в специальный файл
1
на магнитном диске. Затем, по окончании виртуальной печати, в соответствии с принятой дисциплиной обслуживания и приоритетами приложений выводить со- держимое спул-файла на принтер. Системный процесс, который управляет спул- файлом, называется спулером (spool-reader или spool-writer).
Основные системные таблицы
ввода/вывода
Каждая ОС имеет свои таблицы ввода/вывода, их состав (количество и назна- чение каждой таблицы) может сильно отличаться. В некоторых ОС вместо таблиц создаются списки, хотя использование статических структур данных для организа- ции ввода/вывода, как правило, приводит к большему быстродействию. Здесь очень трудно вычленить общие составляющие, тем более что подробной докумен- тации на эту тему крайне мало, только если воспользоваться материалами ныне ус- таревших ОС. Тем не менее, попытаемся это сделать, опираясь на идеи семейства простых, но эффективных ОС реального времени, разработанных фирмой Hewlett–
Packard для своих мини-компьютеров.
Исходя из принципа управления вводом/выводом через супервизор ОС и учи- тывая, что драйверы устройств ввода/вывода используют механизм прерываний для установления обратной связи центральной части с внешними устройствами,
можно сделать вывод о необходимости создания по крайней мере трёх системных таблиц.
Первая таблица (или список) содержит информацию обо всех устройствах ввода/вывода, подключенных к вычислительной системе. Назовем её условно таб-
лицей оборудования (equipment table), а каждый элемент этой таблицы пусть на- зывается UCB (unit control block, блок управления устройством ввода/вывода). Ка- ждый элемент UCB таблицы оборудования, как правило, содержит следующую информацию об устройстве:
1
Такой файл называют спул-файлом (spool-file).

167
| тип устройства, его конкретная модель, символическое имя и характеристи- ки устройства;
| как это устройство подключено (через какой интерфейс, к какому разъёму,
какие порты и линия запроса прерывания используются и т. д.);
| номер и адрес канала (и подканала), если такие используются для управле- ния устройством;
| указание на драйвер, который должен управлять этим устройством, адрес секции запуска и секции продолжения драйвера;
| информация о том, используется или нет буферирование при обмене данны- ми с этим устройством, «имя» (или просто адрес) буфера, если такой выделяется из системной области памяти;
| уставка тайм-аута и ячейки для счетчика тайм-аута;
| состояние устройства;
| поле указателя для связи задач, ожидающих устройство, и, возможно, много ещё каких сведений. Поясним перечисленное. Поскольку во многих ОС драйверы могут обладать свойством реентерабельности (напомним, это означает, что один и тот же экземпляр программного модуля может обеспечить параллельное обслужи- вание сразу нескольких однотипных устройств), то в элементе UCB должна хра- ниться либо непосредственно сама информация о текущем состоянии устройства и сами переменные для реентерабельной обработки, либо указание на место, где та- кая информация может быть найдена. Наконец, важнейшим компонентом элемента таблицы оборудования является указатель на дескриптор той задачи, которая сей- час использует данное устройство. Если устройство свободно, то поле указателя будет иметь нулевое значение. Если же устройство уже занято и рассматриваемый указатель не нулевой, то новые запросы к устройству фиксируются посредством образования списка из дескрипторов тех задач, которые сейчас ожидают данное устройство.

168
Вторая таблица предназначена для реализации ещё одного принципа виртуа- лизации устройств ввода/вывода – независимости от устройства. Желательно, что- бы программист не был озабочен учётом конкретных параметров (и/или возможно- стей) того или иного устройства ввода/вывода, которое установлено (или не уста- новлено) в компьютер. Для него должны быть важны только самые общие возмож- ности, характерные для данного класса устройств ввода/вывода, которыми он же- лает воспользоваться. Например, принтер должен уметь выводить (печатать) сим- волы или графическое изображение. А накопитель на магнитных дисках – считы- вать или записывать по указанному адресу (в координатах C-H-S
1
) порцию данных.
Хотя чаще всего программист и не использует прямую адресацию при работе с магнитными дисками, а работает на уровне файловой системы (см. главу 4). Одна- ко в таком случае уже разработчики файловой системы не должны зависеть от то- го, накопитель какого конкретного типа и модели, а также какого производителя используется в данном конкретном компьютере (например, HDD IBM DTLA
307030, WDAC 450AA или какой-нибудь ещё). Важным должен быть только сам факт существования накопителя, имеющего некоторое количество цилиндров, го- ловок чтения/записи и секторов на дорожке магнитного диска. Упомянутые значе- ния количества цилиндров, головок и секторов должны быть взяты из элемента таблицы оборудования. При этом для программиста также не должно иметь значе- ния, каким образом то или иное устройство подключено к вычислительной систе- ме, а не только какая конкретная модель устройства используется. Поэтому в за- просе на ввод/вывод программист указывает именно логическое имя устройства.
Действительное устройство, которое сопоставляется виртуальному (логическому),
выбирается супервизором с помощью таблицы, о которой мы сейчас говорим.
Итак, способ подключения устройства, его конкретная модель и соответствующий ей драйвер содержатся в уже рассмотренной таблице оборудования. Но для того,
чтобы связать некоторое виртуальное устройство, использованное программистом при создании приложения с системной таблицей, отображающей информацию о том, какое конкретно устройство и каким образом подключено к компьютеру, ис-
1
C-H-S (cylinder-head-sector) – номер цилиндра, номер головки и номер сектора.

169
пользуется вторая системная таблица. Назовем её условно таблицей описания вир-
туальных логических устройств (DRT, device reference table). Назначение этой второй таблицы – установление связи между виртуальными (логическими) устрой- ствами и реальными устройствами, описанными посредством первой таблицы обо- рудования. Другими словами, вторая таблица позволяет супервизору перенапра- вить запрос на ввод/вывод из приложения на те программные модули и структуры данных, которые (или адреса которых) хранятся в соответствующем элементе пер- вой таблицы. Во многих многопользовательских системах такая таблица не одна, а несколько: одна общая и по одной – на каждого пользователя, что позволяет стро- ить необходимые связи между логическими (символьными) именами устройств и реальными физическими устройствами, которые имеются в системе.
Наконец, третья таблица необходима для организации обратной связи между центральной частью и устройствами ввода/вывода. Это таблица прерываний, ко- торая указывает для каждого сигнала запроса на прерывание тот элемент UCB, ко- торый сопоставлен данному устройству, подключенному так, что оно использует настоящую линию (сигнал) прерывания. Как системная таблица ввода/вывода, таб- лица прерываний может в явном виде и не присутствовать. В принципе можно сра- зу из основной таблицы прерываний попадать на программу обработки (драйвер),
имеющей связи с элементом UCB. Важно наличие связи между сигналами преры- ваний и таблицей оборудования.
В современных сложных ОС имеется гораздо больше системных таблиц или списков, используемых для организации процессов управления операциями вво- да/вывода. Например, одной из возможных и часто реализуемых информационных структур, сопровождающих практически каждый запрос на ввод/вывод, является блок управления данными (data control block, DCB). Назначение этого DCB – под- ключение препроцессоров к процессу подготовки данных на ввод/вывод, то есть учет конкретных технических характеристик и используемых преобразований. Это необходимо для того, чтобы имеющееся устройство получало не какие-то непонят- ные ему коды либо форматы данных, которые не соответствуют режиму его рабо-

170
ты, а коды, созданные специально под данное устройство и используемый в на- стоящий момент формат представления данных.
Взаимосвязи между описанными таблицами изображены на рис.4.2.
Рис.4.2. Взаимосвязь системных таблиц ввода/вывода
Теперь нам осталось лишь ещё раз, с учётом изложенных принципов и таблиц,
рассмотреть процесс управления вводом/вывода с помощью рис. 4.3.
Рис.4.3. Процесс управления вводом/выводом
Запрос на операцию ввода/вывода от выполняющейся программы поступает на супервизор (действие 1). Тот проверяет системный вызов на соответствие при- нятым спецификациям и в случае ошибки возвращает задаче соответствующее со-
Таблица
логических имён
1-й элемент
:
i-й элемент
:
j-й элемент
:
Таблица
оборудования
1-й UCB
:
i-й UCB
:
j-й UCB
:
n-й UCB
Таблица
прерываний
1-й элемент
:
h-й элемент
:
g-й элемент
:

171
общение (действие 1–1). Если же запрос корректен, то он перенаправляется в су- первизор ввода/вывода (действие 2). Последний по логическому (виртуальному)
имени с помощью таблицы DRT находит соответствующий элемент UCB в таблице оборудования. Если устройство уже занято, то описатель задачи, запрос которой сейчас обрабатывается супервизором ввода/вывода, помещается в список задач,
ожидающих настоящее устройство. Если же устройство свободно, то супервизор ввода/вывода определяет из UCB тип устройства и при необходимости запускает препроцессор, позволяющий получить последовательность управляющих кодов и данных, которую сможет правильно понять и отработать устройство (действие 3).
Когда «программа» управления операцией ввода/вывода будет готова, супервизор ввода/вывода передаст управление соответствующему драйверу на секцию запуска
(действие 4). Драйвер инициализирует операцию управления, обнуляет счётчик тайм-аута и возвращает управление супервизору (диспетчеру задач) с тем, чтобы он поставил на процессор готовую к исполнению задачу (действие 5). Система ра- ботает своим чередом, но когда устройство ввода/вывода отработает посланную ему команду, оно выставляет сигнал запроса на прерывания, по которому через таблицу прерываний управление передаётся на секцию продолжения (действие 6).
Получив новую команду, устройство вновь начинает её обрабатывать, а управле- ние процессором опять передаётся диспетчеру задач, и процессор продолжает по- лезную работу. Таким образом, получается параллельная обработка задач, на фоне которой процессор осуществляет управление операциями ввода/вывода.
Очевидно, что если имеются специальные аппаратные средства для управле- ния вводом/выводом, снимающие эту работу с центрального процессора (речь идет о каналах прямого доступа к памяти), то в функции центрального процессора будут по-прежнему входить все только что рассмотренные шаги, за исключением по- следнего – непосредственного управления операциями ввода/вывода. В случае ис- пользования каналов прямого доступа к памяти последние исполняют соответст- вующие канальные программы и разгружают центральный процессор, избавляя его от непосредственного управления обменом данными между памятью и внешними устройствами.

172
При описании этой схемы мы не стали затрагивать вопросы распределения ка- налов, контроллеров и собственно самих устройств. Также были опущены детали получения канальных программ. Будем считать, что они выходят за круг вопросов,
рассматриваемых в учебнике по дисциплине «Системное программное обеспече- ние», тем более что в последнем государственном образовательном стандарте для направления 46 – «Информатика и вычислительная техника» имеется отдельная общепрофессиональная дисциплина «Операционные системы» и специальная дис- циплина «Интерфейсы периферийных устройств».
Синхронный и асинхронный ввод/вывод
Задача, выдавшая запрос на операцию ввода/вывода, переводится супервизо- ром в состояние ожидания завершения заказанной операции. Когда супервизор по- лучает от секции завершения сообщение о том, что операция завершилась, он пе- реводит задачу в состояние готовности к выполнению, и она продолжает свою ра- боту. Эта ситуация соответствует синхронному вводу/выводу. Синхронный ввод/вывод является стандартным для большинства ОС. Чтобы увеличить скорость выполнения приложений, было предложено при необходимости использовать асинхронный ввод/вывод.
Простейшим вариантом асинхронного вывода является так называемый буфе- рированный вывод данных на внешнее устройство, при котором данные из прило- жения передаются не непосредственно на устройство ввода/вывода, а в специаль- ный системный буфер. В этом случае логически операция вывода для приложения считается выполненной сразу же, и задача может не ожидать окончания действи- тельного процесса передачи данных на устройство. Процессом реального вывода данных из системного буфера занимается супервизор ввода/ вывода. Естественно,
что выделением буфера из системной области памяти занимается специальный системный процесс по указанию супервизора ввода/вывода. Итак, для рассмотрен- ного случая вывод будет асинхронным, если, во-первых, в запросе на ввод/вывод было указано на необходимость буферирования данных, а во-вторых, если устрой- ство ввода/вывода допускает такие асинхронные операции и это отмечено в UCB.
Можно организовать и асинхронный ввод данных. Однако для этого необходимо

173
не только выделить область памяти для временного хранения считываемых с уст- ройства данных и связать выделенный буфер с задачей, заказавшей операцию, но и сам запрос на операцию ввода/вывода разбить на две части (на два запроса). В пер- вом запросе указывается операция на считывание данных, подобно тому, как это делается при синхронном вводе/выводе. Однако тип (код) запроса используется другой, и в запросе указывается ещё по крайней мере один дополнительный пара- метр – имя (код) того системного объекта, которое получает задача в ответ на за- прос и которое идентифицирует выделенный буфер. Получив имя буфера (будем этот системный объект условно называть таким образом, хотя в различных ОС для его обозначения используются и другие термины, например – класс), задача про- должает свою работу. Здесь очень важно подчеркнуть, что в результате запроса на асинхронный ввод данных задача не переводится супервизором ввода/вывода в со- стояние ожидания завершения операции ввода/ вывода, а остается в состоянии вы- полнения или в состоянии готовности к выполнению. Через некоторое время, вы- полнив необходимый код, который был определен программистом, задача выдаёт второй запрос на завершение операции ввода/вывода. В этом втором запросе к то- му же устройству, который, естественно, имеет другой код (или имя запроса), зада- ча указывает имя системного объекта (буфера для асинхронного ввода данных) и в случае успешного завершения операции считывания данных тут же получает их из системного буфера. Если же данные ещё не успели до конца переписаться с внеш- него устройства в системный буфер, супервизор ввода/вывода переводит задачу в состояние ожидания завершения операции ввода/вывода, и далее всё напоминает обычный синхронный ввод данных.
Обычно асинхронный ввод/вывод предоставляется в большинстве мультипро- граммных ОС, особенно если ОС поддерживает мультизадачность с помощью ме- ханизма тредов. Однако если асинхронный ввод/вывод в явном виде отсутствует,
его идеи можно реализовать самому, организовав для вывода данных самостоя- тельный поток.
Аппаратуру ввода/вывода можно рассматривать как совокупность аппаратур-
ных процессоров, которые способны работать параллельно относительно друг дру-

174
га, а также относительно центрального процессора (процессоров). На таких «про- цессорах» выполняются так называемые внешние процессы. Например, для внеш- него устройства (устройства ввода/вывода) внешний процесс может представлять собой совокупность операций, обеспечивающих перевод печатающей головки,
продвижение бумаги на одну позицию, смену цвета чернил или печать каких-то символов. Внешние процессы, используя аппаратуру ввода/вывода, взаимодейст- вуют как между собой, так и с обычными «программными» процессами, выпол- няющимися на центральном процессоре. Важным при этом является то обстоятель- ство, что скорости выполнения внешних процессов будут существенно (порой, на порядок или больше) отличаться от скорости выполнения обычных («внутренних»)
процессов. Для своей нормальной работы внешние и внутренние процессы обяза- тельно должны синхронизироваться. Для сглаживания эффекта сильного несоот- ветствия скоростей между внутренними и внешними процессами используют упо- мянутое выше буферирование. Таким образом, можно говорить о системе парал- лельных взаимодействующих процессов (см. главу 6).
Буферы являются критическим ресурсом в отношении внутренних (программ- ных) и внешних процессов, которые при параллельном своем развитии информа- ционно взаимодействуют. Через буфер (буферы) данные либо посылаются от неко- торого процесса к адресуемому внешнему (операция вывода данных на внешнее устройство), либо от внешнего процесса передаются некоторому программному процессу (операция считывания данных). Введение буферирования как средства информационного взаимодействия выдвигает проблему управления этими систем- ными буферами, которая решается средствами супервизорной части ОС. При этом на супервизор возлагаются задачи не только по выделению и освобождению буфе- ров в системной области памяти, но и синхронизации процессов в соответствии с состоянием операций по заполнению или освобождению буферов, а также их ожи- дания, если свободных буферов в наличии нет, а запрос на ввод/вывод требует бу- ферирования. Обычно супервизор ввода/вывода для решения перечисленных задач использует стандартные средства синхронизации, принятые в данной ОС. Поэтому если ОС имеет развитые средства для решения проблем параллельного выполнения

175
взаимодействующих приложений и задач, то, как правило, она реализует и асин- хронный ввод/вывод.
Кэширование операций ввода/вывода при
работе с накопителями на магнитных
дисках
Как известно, накопители на магнитных дисках обладают крайне низкой ско- ростью по сравнению с быстродействием центральной части компьютера. Разница в быстродействии отличается на несколько порядков. Например, современные про- цессоры за один такт работы, а они работают уже с частотами в 1 ГГц и более, мо- гут выполнять по две операции. Таким образом, время выполнения операции (с по- зиции внешнего наблюдателя, не видящего конвейеризации при выполнении ма- шинных команд, благодаря которой производительность возрастает в несколько раз) может составлять 0,5 нс (!). В то же время переход магнитной головки с до- рожки на дорожку составляет несколько миллисекунд. Такие же временные интер- валы имеют место и при ожидании, пока под головкой чтения/ записи не окажется нужный сектор данных. Как известно, в современных приводах средняя длитель- ность на чтение случайным образом выбранного сектора данных составляет около
20 мс, что существенно медленнее, чем выборка команды или операнда из опера- тивной памяти и уж, тем более, из кэша. Правда, после этого данные читаются большим пакетом (сектор, как мы уже говорили, имеет размер в 512 байтов, а при операциях с диском часто читается или записывается сразу несколько секторов).
Таким образом, средняя скорость работы процессора с оперативной памятью на 2-3
порядка выше, чем средняя скорость передачи данных из внешней памяти на маг- нитных дисках в оперативную память. Для того чтобы сгладить такое сильное не- соответствие в производительности основных подсистем, используется буфериро- вание и/или кэширование
1
данных. Простейшим вариантом ускорения дисковых операций чтения данных можно считать использование двойного буферирования.
Его суть заключается в том, что пока в один буфер заносятся данные с магнитного диска, из второго буфера ранее считанные данные могут быть прочитаны и переда-
1
Disk cache – кэш диска.