Деревянко А.С., Солощук М.Н. Операционные системы.Часть I. Построение и функционирование операционных систем
Подождите немного. Документ загружается.
191
Потоки прозрачны для пользовательских процессов, но последним
предоставляется возможность вставлять в потоки собственные модули.
Поток может быть однонаправленным или дуплексным, то есть
содержать две параллельные цепочки очередей – вводную и выводную, как
и показано на рисунке 6.6.
Развитием идеи потоков является многоуровневая структура
драйверов, которая применяется в ряде современных ОС. Обработка
данных проходит в этом случае через цепочку отдельных драйверов. Места
драйверов в цепочке распределяются таким образом, чтобы каждый
драйвер более низкого уровня осуществлял обработку, более привязанную
к конкретному устройству. Драйверы высоких уровней могут обслуживать
несколько устройств одного типа, но разных моделей. Непосредственно
аппаратно-зависимым является только драйвер самого нижнего уровня
(аппаратный драйвер). В некоторых ОС даже аппаратный драйвер не
осуществляет прямого взаимодействия с устройством, а использует для
этого сервис ОС. В многоуровневой структуре драйверов может быть
оставлено место и для пользовательских драйверов, выполняющих
специфическую обработку данных.
6.6. Интерфейс процесса
Как мы уже отметили выше, ОС конструирует для процессов
виртуальные устройства высокого уровня. Характерным примером таких
устройств являются файлы. Процесс может работать с каждым файлом, как
с отдельным устройством, хотя на самом деле файл представляет собой
лишь часть дискового пространства. В ОС Unix концепция файла была
впервые введена как универсальная метафора устройства. Это позволяет
свести все многообразие управления вводом-выводом к единой форме
192
системных вызовов. Ниже приведен набор системных вызовов для работы
с устройствами, являющийся практически общепринятым.
Открыть устройство:
devHandle = open(devNname, mode)
Этот вызов сообщает драйверу, что процесс будет работать с данным
устройством. Вызов является частным случаем вызова getResource, и
при его выполнении могут производиться действия по предупреждению
или обнаружению тупиков. Процесс может быть заблокирован, если
требуемое устройство занято. Могут проверяться права доступа данного
процесса к данному устройству. На устройстве могут выполняться какие-
то специфические для устройства действия – начальные установки.
Параметр mode определяет направление обмена данными с устройством:
чтение, запись, чтение/запись, запись в конец. Никакие другие операции с
устройством невозможны, если для него не выполнена операция открытия.
Манипулятор (handle), возвращаемый системным вызовом open, служит
идентификатором открытого устройства во всех последующих операциях с
ним.
Закрыть устройство:
close(devHandle)
Вызов сообщает драйверу, что процесс закончил работу с устройством.
Ресурс-устройство открепляется от процесса, разблокируются другие
процессы, ожидающие освобождения этого устройства. На устройстве
могут выполняться специфические заключительные операции.
Читать данные из устройства в память:
read(devHandle, vAddr, counter)
Это запрос на передачу данных из устройства, идентифицируемого
манипулятором devHandle в задаваемую виртуальным адресом vAddr
область адресного пространства процесса. Если на устройстве нет того
объема информации, который задан счетчиком counter, может быть
193
передан меньший объем. Вызов обычно возвращает действительный объем
переданной информации.
Писать данные из памяти в устройство:
write(devHandle, vAddr, counter)
Запрос на передачу данных из заданной области виртуального адресного
пространства процесса на устройство.
Позиционировать устройство:
seek(devHandle, position)
Запрос на установку устройства в заданную позицию. Применяется для
устройств, имеющих внутреннюю адресацию. По умолчанию вызовы
read и write устанавливают устройство в позицию, следующую за
прочитанными или записанными данными.
Управление вводом-выводом:
ioctl(devHandle, command, parameters)
Запрос на выполнение специфических для устройства операций, не
вписывающихся в перечисленные выше системные вызовы. Операция
определяется командой command, например: чтение, запись, управление и
т.п. Третий параметр задает дополнительные параметры, специфичные для
каждой операции.
При реализации системных вызовов read и write перед
разработчиком ОС возникает вопрос: блокировать или не блокировать
процесс, выдавший системный вызов? Возможна синхронная и
асинхронная организация ввода-вывода. При синхронной организации
процесс, выдавший запрос на чтение/запись данных, требующий
физического обмена данными с устройством, безусловно блокируется.
Когда процесс возобновляется, он может быть уверен, что данные, которые
он запросил (read), уже находятся в его рабочей области, и он может их
использовать, а данные, которые он передал (write), уже пересланы, и он
может записывать в область, в которой они находились, другую
194
информацию. Альтернативной является асинхронная организация ввода-
вывода, при которой системный вызов read/write только инициирует
операцию, далее процесс продолжает выполняться параллельно со вводом-
выводом. Параллельное выполнение позволяет повысить эффективность
работы как самого процесса, так и всей системы, так как снимает
необходимость в переключении процессов, но синхронизация все равно
необходима. Если, например, процесс запросил ввод данных, то прежде,
чем он начнет их использовать, он должен убедиться, что ввод завершился.
Ответственность за такую синхронизацию перекладывается на процесс.
Для предоставления процессу возможности синхронизировать свои
действия с выполнением операций ввода-вывода ОС обеспечивает
процессу виртуальные прерывания, поддерживаемые системными
вызовами, описываемыми далее.
Ждать завершения операции на устройстве:
wait(devHandle, delay)
Вызов блокирует процесс – переводит его в состояние ожидания до тех
пор, пока не поступит виртуальное прерывание, сигнализирующее о
завершении операции на устройстве, определяемом devHandle. Если
операция к моменту вызова уже завершилась, процесс не блокируется.
Параметр delay задает максимально допустимое время, которое процесс
может ожидать. Если это время выходит, системный вызов wait
заканчивается, возвращая признак ошибки. Это время может быть
установлено и бесконечно большим.
Установить обработчик виртуального прерывания от устройства:
setHandler(devHandle, procAddr)
Возможность, предоставляемая этим вызовом, обеспечивает полное
сходство виртуального прерывания с реальным. При поступлении
виртуального прерывания от устройства выполнение процесса
прерывается и управление передается на процедуру с адресом procAddr,
195
которую процесс назначил обработчиком виртуального прерывания. Все
обработчики виртуальных прерываний должны соответствовать
несложным системным спецификациям. Обычно обработчик имеет
параметры, через которые ему передается дополнительная информация о
виртуальном прерывании. Еще раз подчеркнем, что речь здесь идет именно
о виртуальных, а не о реальных прерываниях. Виртуальное прерывание
обеспечивается не аппаратными средствами, а моделируется для процесса
операционной системой.
Асинхронная организация ввода-вывода предоставляет пользователю
больше возможностей для повышения эффективности выполнения
процесса, но вместе с тем и больший простор для ошибок. Характерной,
например, может быть такая ошибка, появление которой должно быть
предусмотрено в ОС. При записи данных, например, правильной является
такая последовательность системных вызовов:
write...wait...write...wait... ,
то есть следующий блок информации не выводится, пока не будет
закончен вывод предыдущего. Что произойдет, если последовательность
вызовов будет такой:
write...write...wait...wait... ?
Если ОС связывает с операцией ввода-вывода двоичный флаг, то
первый вызов write установит этот флаг в состояние "занято", второй –
не изменит значение флага. Окончание первой операции вывода сбросит
флаг в "свободно", что будет обработано первым вызовом wait,
окончание второй операции вывода не повлияет на состояние флага, и
второй вызов wait в любом случае найдет флаг в состоянии "свободно".
Момент окончания второй операции, таким образом, будет "утерян". ОС
должна либо расценивать подобную последовательность вызовов как
ошибку процесса, либо поддерживать ее, создавая для каждой операции
свой флаг.
196
6.7. Буферизация
Хотя блокировки и не влияют на результат выполнения процесса и не
отражаются на его виртуальном времени, они сказываются на реальном
времени его выполнения. Для интерактивных процессов они могут стать
основным фактором, определяющим время реакции процесса. Невыгодны
блокировки и для ОС, так как каждая блокировка – это переключение
процессов, а, следовательно, накладные расходы. Одним из способов,
позволяющим избежать блокировок (или, по крайней мере, уменьшить их
количество) является буферизация данных. Для устройства ввода-вывода
назначается буферная область в оперативной памяти. Обмен данными
происходит между процессом и буферной областью, а обмен между
буферной областью и устройством выполняет ОС независимо от
выполнения процесса. Если, например, выполнение системного вызова
write будет включать в себя только пересылку данных в оперативной
памяти, то блокировка процесса на время выполнения этого вызова не
нужна. Буферизация, таким образом, сглаживает различия в скоростях
работы производителя и потребителя информации и позволяет избежать
излишних блокировок.
Особенно существенный эффект буферизация может дать при
последовательном вводе-выводе, так как при вводе ОС может предсказать,
какой блок информации понадобится следующим и произвести его
упреждающее чтение в буфер. Еще один полезный эффект буферизации –
ОС имеет возможность сгруппировать данные в буфере и производить
обмен с внешним устройством большими блоками.
Богатые вариантами средства организации ввода-вывода с
использованием буферизации были впервые реализованы в OS/360 [21] и
унаследованы следующими поколениями ОС мейнфреймов. При
197
синхронной организации ввода-вывода (в OS/360 – "методы доступа с
очередями") буферизация прозрачна для процесса, она полностью
обеспечивается ОС. При асинхронной организации ("базисные методы
доступа") процесс сам может организовать буферизацию. Устройству
назначается буферная область, которая форматируется как буферный пул.
В методах с очередями это назначение происходит автоматически,
программист может только изменить размер пула, если его не устраивает
принятый по умолчанию. В базисных методах есть специальные
системные вызовы для выделения, освобождения, форматирования
буферного пула и связывания пула с устройством. Буферизация не
обязательно означает дополнительную пересылку данных в оперативной
памяти. Методы с очередями предоставляют три альтернативных режима
управления буферизацией:
• режим пересылки – данные пересылаются в оперативной памяти
между рабочей областью процесса и буфером;
• режим указания – данные не пересылаются; при вводе процесс
получает от ОС адрес буфера, содержащего введенные данные, и
может использовать его как рабочую область, при выводе процесс
получает от ОС адрес свободного выводного буфера и использует
его как свою рабочую область, формируя в ней данные для
вывода;
• режим подстановки – данные не пересылаются; при вводе процесс
получает от ОС адрес заполненного вводного буфера, а свою
рабочую область "передает" во вводной буферный пул; при
выводе процесс "передает" в выводной пул свою рабочую область,
заполненную выводными данными, а взамен получает свободный
буфер из пула.
Два интересных примера буферизации мы возьмем из ОС Unix.
198
В Unix буферизация обмена с дисковыми накопителями
(кеширование) является тотальной, через кеш проходят все данные,
которыми ОС и процессы обмениваются с дисками, и под кеш отводится
значительная часть оперативной памяти. Кеширование дает значительный
эффект и при случайном (непоследовательном) обмене, характерном для
многозадачной многопользовательской ОС. В дескрипторе каждого буфера
в кеше имеются поля:
• состояние буфера (свободен / содержит правильную информацию
/ грязный / заблокирован / занят в операции
ввода/вывода/ожидается каким-либо процессом);
• адрес на внешней памяти блока информации, содержащегося в
буфере;
• указатели, связывающие буфера в хеш-очереди (см.дальше) и в
список свободных буферов.
Список свободных буферов организован как простая FIFO-очередь:
ядро ОС выбирает буфер из головы списка, освобождающийся буфер
включает в конец списка. Таким образом, буфер, попавший в список
свободных, еще некоторое время находится в этом списке, сохраняя свое
содержимое, и может быть выбран из списка, если к нему будет
обращение. При обращении к дисковому вводу-выводу основным
параметром является адрес блока на внешней памяти. ОС сначала ищет в
кеше соответствующий блоку буфер и только при неудачном поиске в
кеше назначает свободный буфер и производит физическое обращение к
диску. Для ускорения поиска в кеше все буфера распределяются по
нескольким спискам, именуемым хеш-очередями. Номер списка
определяется как результат весьма простой функции хеширования,
аргументом которой является адрес на внешней памяти. Применение
хеширования позволяет равномерно распределить буфера по хеш-
очередям. Каждый буфер может входить только в одну хеш-очередь, но
199
также может быть включен и в список свободных. Процесс, выдавший
запрос на ввод-вывод, блокируется в случаях:
• если буфера нет в хеш-очереди и список свободных блоков пуст;
• если буфер есть в хеш-очереди, но занят.
При освобождении блока разблокируются все процессы, ждущие
освобождения этого или любого блока.
Все современные ОС (OS/2, Windows 95, Windows NT) в той или
иной степени применяют тотальное кеширование при обмене с дисками.
Второй пример – буферизация ввода в драйвере терминала. Задача
такой буферизации – обеспечить накопление данных и возможность
упреждающего ввода с терминала. Для этой буферизации характерны:
последовательный ввод, сравнительно небольшие объемы данных в
буфере, непостоянство длины информации, содержащейся в буфере. Буфер
представляет цепочку блоков, каждый из которых имеет постоянную
длину. В каждом блоке имеются следующие поля:
• указатель на следующий блок в цепочке;
• смещение первого символа в поле данных;
• смещение последнего символа в поле данных;
• поле данных для хранения N символов.
Пример буфера при N=8 показан на рисунке 6.7. Ядро ОС хранит
указатели на первый и последний блоки цепочки и ведет список свободных
блоков (очередь LIFO). Ядро обеспечивает:
• назначение драйверу свободного блока;
• возвращение блока в список свободных;
• выбор первого символа из буфера (при этом возможно
освобождение блока);
• добавление символа в конец буфера (при этом возможно
выделение нового блока).
200
Рисунок 6.7 Буфер терминала для Unix
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Охарактеризуйте методы виртуализации устройств в ОС.
Приведите примеры их применения.
2. Почему даже при закреплении устройства за процессом
устройство все равно остается виртуальным?
3. Чем вы объясните столь долгое и успешное существование
концепции каналов ввода-вывода?
4. Чем объясняется двухуровневая (как минимум) структура
драйвера устройства?
5. В некоторых современных ОС драйверами называются также и
модули ОС, не имеющие отношения к управлению устройствами. Чем
может быть объяснен такой подход?
6. Назовите те функции, которые вы считаете целесообразным
добавить в драйвер клавиатуры для обеспечения большего удобства
пользователю.
7. Каким образом можно обеспечить выдачу процессу "сигнала
тревоги" через заданный интервал времени, если в системе нет
программируемого интервального таймера?