open. Однако, применительно к системному вызову creat мы должны подчеркнуть, что в случае своего естественного применения (для создания файла) этот системный вызов создает новый элемент соответствующего каталога (в соответствии с заданным значением pathname), а также создает и соответствующим образом инициализирует новый i-узел.

     Наконец, системный вызов dup (duplicate - скопировать) приводит к образованию нового дескриптора уже открытого файла. Этот специфический для ОС UNIX системный вызов служит исключительно для целей перенаправления ввода/вывода. Его выполнение состоит в том, что в u-области системного пространства пользовательского процесса образуется новый описатель открытого файла, содержащий вновь образованный дескриптор файла (целое число), но ссылающийся на уже существующую общесистемную структуру file и содержащий те же самые признаки и флаги, которые соответствуют открытому файлу-образцу.

     Другими важными системными вызовами являются системные вызовы read и write. Системный вызов read выполняется следующим образом:

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

Операция записи выполняется аналогичным образом, но меняет содержимое буфера буферного  пула.

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

времени закрытия устройства) устанавливает  общесистемный флаг "драйвер свободен".

     Наконец, для специальных  файлов поддерживается   еще   один "специальный" системный вызов ioctl. Это единственный системный вызов, который обеспечивается для специальных файлов и не обеспечивается для остальных разновидностей файлов. Фактически, системный вызов ioctl позволяет произвольным образом расширить интерфейс любого драйвера. Параметры ioctl включают код операции и указатель на некоторую область памяти пользовательского процесса. Всю интерпретацию кода операции и соответствующих специфических параметров проводит драйвер.

     Естественно, что поскольку драйверы главным  образом предназначены для управления внешними устройствами, программный  код драйвера должен содержать соответствующие  средства для обработки прерываний от устройства. Вызов индивидуальной программы обработки прерываний в драйвере происходит из ядра операционной системы. Подобным же образом в драйвере может быть объявлен вход "timeout", к которому обращается ядро при истечении ранее заказанного драйвером времени (такой временной контроль является необходимым при управлении не слишком интеллектуальными устройствами).

     Общая схема интерфейсной организации  драйверов показана на рисунке 3. Как показывает этот рисунок, с точки зрения интерфейсов и общесистемного управления различаются два вида драйверов - символьные и блочные. С точки зрения внутренней организации выделяется еще один вид драйверов - потоковые (stream) драйверы. Однако по своему внешнему интерфейсу потоковые драйверы не отличаются от символьных. 
 
 
 
 
 
 
 
 

     Рис. 3 Интерфейсы и входные точки драйверов 
 
 
 
 
 
 
 
 
 
 

7. СИНХРОННЫЙ  И АСИНХРОННЫЙ  ВВОД-ВЫВОД

     7.1. Синхронный ввод-вывод

      Синхронный  ввод-вывод является стандартным для большинства операционных систем. Чтобы увеличить скорость выполнения приложений, было предложено при необходимости использовать асинхронный ввод-вывод.

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

      Можно организовать и асинхронный ввод данных. Однако для этого необходимо не только выделять область памяти для временного хранения считываемых с устройства данных и связывать выделенный буфер с задачей, заказавшей операцию, но и сам запрос на операцию ввода-вывода разбивать на две части (на два запроса). В первом запросе указывается операция на считывание данных, подобно тому как это делается при синхронном вводе-выводе, однако тип (код) запроса используется другой, и в запросе указывается еще по крайней мере один дополнительный параметр — имя (код) системного объекта, которое получает задача в ответ на запрос и которое идентифицирует выделенный буфер. Получив имя буфера (будем так условно называть этот системный объект, хотя в различных операционных системах используются и другие термины, например «класс»), задача продолжает свою работу. Здесь очень важно подчеркнуть, что в результате запроса на асинхронный ввод данных задача не переводится супервизором ввода-вывода в состояние ожидания завершения операции ввода-вывода, а остается в состоянии выполнения или в состоянии готовности к выполнению. Через некоторое время, выполнив необходимый код, который был определен программистом, задача выдает второй запрос на завершение операции ввода-вывода. Б этом втором запросе к тому же устройству, который, естественно, имеет другой код (или имя запроса), задача указывает имя системного объекта (буфера для асинхронного ввода данных) и в случае успешного завершения операции считывания данных тут же получает их из системного буфера. Если же данные еще не успели до конца переписаться с внешнего устройства в системный буфер, супервизор ввода-вывода переводит задачу в состояние ожидания завершения операции ввода-вывода, и далее все напоминает обычный синхронный ввод данных.

7.2. Асинхронный ввод-вывод

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

     Еще одна проблема использования концепции IOCS была связана с тем, что полный пакет программ IOCS зачастую занимал  значительную долю основной памяти, оставляя мало места для кода прикладных программ пользователя. Поэтому некоторые  пользователи занимали в памяти место  не нужных им модулей пакета IOCS своими программами. Другие пользователи разрабатывали  свои собственные, более компактные пакеты. Однако в конце концов пользователи поняли, что самое рациональное -- это предоставить системе IOCS возможность выполнять все функции по управлению вводом-выводом, и были просто вынуждены увеличивать объемы (дорогостоящей) основной памяти своих вычислительных машин.  
 
 
 

СПИСОК  ЛИТЕРАТУРЫ

1. Гребенюк  Е.И.  Техническая средства информатизации: Учебник . М.:Издательский центр «Академия», 2003г.
2. Макарова Н.В. Информатика. Учебник. М.:Финансы и статистика, 2004г.
3. Мураховский В.Н. Железо П.К. Новые возможности.- Спб.:Питер, 2005г.
4. Шафрин Ю. и др. Курс компьютерной технологии. Учебное пособие. 1-2 том. Москва АБФ 1998г.