Программно-технический комплекс Учебное пособие Новочеркасск юргту (нпи) 2010. Удк 519. 23 (075. 8) Ббк 22. 17я73
| Вид материала | Учебное пособие |
- Практикум Новочеркасск юргту (нпи) 2010 удк 330 (075. 8) Ббк 65. 012. 1я73, 2097.42kb.
- Учебно-методическое пособие Новочеркасск юргту (нпи) 2011 г. Удк 004 : 012 (076) ббк, 1329.07kb.
- Учебно-методическое пособие Новочеркасск юргту (нпи) 2011 г. Удк 004 : 012 (076) ббк, 994.64kb.
- Пособие предназначено для студентов, изучающих курсы «Экономики» и«Экономической теории», 4766.75kb.
- Учебно-методическое пособие Новочеркасск 2006 удк 004. 4 (07), 341.54kb.
- Учебное пособие к практическим занятиям по дисциплине «Физическая культура» Новочеркасск, 1055.75kb.
- Конспект лекций москва 2004 удк 519. 713(075)+519. 76(075) ббк 22. 18я7, 1805.53kb.
- Данное пособие предназначено для кураторов академических групп младших курсов, а также, 1695.39kb.
- Пособие предназначено для студентов специальности «Прикладная информатика (в экономике)», 1911.82kb.
- Учебное пособие тверь 2008 удк 519. 876 (075. 8 + 338 (075. 8) Ббк 3817я731-1 + 450., 2962.9kb.
2.2.6. Особенности системы ввода/вывода системы NT
Ввод/вывод считается сложной областью ОС, в которой сложно применить общий подход и где изобилуют частные методы. Система ввода/вывода исполнительной системы NT – это часть кода ОС, получающая запросы от процессов пользовательского режима и режима ядра и передающая их, в преобразованном виде, устройствам ввода/вывода. Система ввода/вывода имеет три особенности:
– объектная модель – управление пакетами;
– унифицированная модель драйвера;
– асинхронная обработка.
Система ввода/вывода управляется пакетами. Каждый запрос ввода/вывода представляется в виде пакета запроса ввода–вывода. Диспетчер не управляет вводом-выводом, он создает пакет запроса ввода/вывода, передает пакет соответствующему драйверу и удаляет его. Диспетчер предоставляет общие для драйверов устройств процедуры. Драйверы обращаются к этим процедурам во время ввода/вывода. Благодаря объединению общих задач в диспетчере драйверы устройств становятся компактными.
В Windows NT как и в ОС UNIX программы осуществляют ввод-вывод в виртуальные файлы, манипулируя ими посредством файлового объекта. Все источники или приемники ввода/вывода представлены файловыми объектами. Потоки пользовательского режима вызывают базовые сервисы файлового объекта NT для чтения из файла, записи в файл. Диспетчер ввода/вывода преобразует эти запросы к виртуальным файлам в запросы к настоящим файлам, физическим устройствам.
Унифицированная модель. Каждый драйвер – это автономный компонент, который может добавляться к ОС и удаляться из нее. Диспетчер определяет модель драйверов ввода/вывода:
- драйверы переносимы и написаны на языках высокого уровня;
- операции ввода/вывода управляются пакетами запросов ввода/вывода;
- драйверы должны синхронизировать свой доступ к глобальным данным;
- драйверы должны корректно восстанавливаться после сбоя питания и запускать процедуру сбора.
Унифицированная модель драйверов позволяет Диспетчеру ввода/вывода не видеть их структуру. Драйверы также могут вызывать друг друга через Диспетчер. Запрос может проходить через много драйверов – Послойная структура.
Асинхронная обработка. Синхронный ввод-вывод – это запрос сервиса, устройство читает данные и передает их программе (ReadFile(), WriteFile()). Прежде чем передать управление вызывающей программе, заканчивается выполнение операций ввода/вывода.
Чтобы использовать асинхронный ввод-вывод, поток должен указать это (overlapped) при открытии описателя. Один из параметров функции CreateFile определяет атрибуты файлов, среди которых есть флаг FILE_FLAG_OVERLAPPED. После начала асинхронного ввода/вывода поток должен позаботиться о том, чтобы не использовать данные этой операции, пока драйвер устройства не завершит ее. Чтобы процессор не простаивал во время операций ввода/вывода, Диспетчер ввода/вывода предоставляет средства асинхронного ввода/вывода. Асинхронные сервисы позволяют приложению выдавать запрос ввода/вывода и продолжать выполнение, пока устройство передает данные. Треть базовых сервисов NT асинхронно.
Чтение и запись в файл. Поток, вызывающий эти сервисы должен синхронизировать свое выполнение с их завершением.
Запрос ввода/вывода к однослойному драйверу. Обработка синхронного запроса проходит три этапа:
- диспетчер ввода/вывода посылает запрос в форме IPR (пакет запроса) драйверу устройства, который запускает операцию ввода/вывода;
- устройство завершает выполнение операции и генерирует прерывание, которое обслуживается драйвером;
- диспетчер ввода/вывода завершает обработку запроса.
Обработка асинхронного запроса отличается тем, что между п.1. и п.2 добавляется новый пункт – диспетчер ввода – вывода возвращает управление вызывающей программе. Программа работает до тех пор, пока не выполнится шаг 2 и 3. Но должна синхронизировать свою работу с завершением шага 3.
Посыл запроса. В Windows Nt запрос к принтеру – через подсистему среды, которая вызывает сервис NtWriteFile диспетчера ввода/вывода. Пункт назначения – параллельный порт – указан первым параметром. Подсистема открывает описатель порта и задает синхронный ввод/вывод. Диспетчер ввода/вывода создает IPR, в котором сохраняет указатель на файловый объект и код функции. Далее диспетчер ввода/вывода отыскивает драйвер, вызывает его и передает IPR.
Асинхронный запрос обрабатывается несколько иначе. Новый запрос должен ждать, если принтер занят другими запросами. Драйвер помещает IPR в очередь устройства и возвращает код состояния "ввод/вывод выполняется" вызывающей программе. Приложение выполняет свою работу, пока принтер занят. Так как ввод/вывод выполняется асинхронно, поток приложения не должен изменять содержимое буфера печати, пока принтер не завершит обработку запроса.
Обслуживание прерываний. После завершения передачи данных устройство ввода/вывода генерирует прерывание, и в дело вступает драйвер устройств, ядро NT и диспетчер ввода/вывода.
Когда происходит прерывание от устройства, процессор передает управление ядру, ядро обращается к своей таблице распределения прерываний, чтобы найти процедуру обслуживания прерываний (ISR) для данного устройства. ISR обрабатывает прерывание от устройства в два этапа. Прерывания от устройства имеют высокий уровень IRQL, но ISR остается на этом уровне только на время, необходимое, чтобы запретить новые прерывания от устройства. Затем поток понижает IRQL процессора и завершает обработку прерывания. Когда процессор понижается до уровня DPC , происходит вызов DPC из очереди, закончив работу DPC вызывает диспетчер ввода/вывода для завершения обработки запроса и удаления IPR.
Преимуществом использования DPC является то, что все блокированные прерывания, чей приоритет лежит между IRQL устройства и диспетчерским/DPC, снова разрешаются, прежде чем произойдет более низкое приоритетное прерывание.
Завершение обработки запроса. Завершение ввода/вывода после возврата из DPC и зависит от типа запроса. Все сервисы ввода/вывода записывают результат операции в блок состояния ввода/вывода. Подсистема ввода/вывода копирует данные из системной памяти в виртуальное адресное пространство вызывающего процесса. Это достигается путем посылки потоку APC режима ядра. При возникновении прерывания APC ядро передает управление процедуре APC диспетчера ввода/вывода, которая копирует данные, удаляет IPR запроса и устанавливает описатель файла в состояние "свободен".
Запросы ввода/вывода к многослойным драйверам. К модели добавляются несколько уровней обработки. Диспетчер ввода/вывода получает запрос и создает пакет запроса ввода/вывода. Передает пакет драйверу файловой системы. Драйвер файловой системы может послать драйверу устройства либо то же самое IRP, либо сгенерировать несколько новых и направить их драйверу.
Для поддержки использования пакета несколькими драйверами, расположенными друг над другом, IRP содержит набор областей стека IRP. Каждый драйвер реализует свою часть запроса, используя одну область в стеке. Эти области заполняются по мере передачи IPR от одного драйвера другому. Вместо повторного использования одного IPR, файловая система может создать группу ассоциированных IPR, которые будут работать над одним запросом параллельно.
Особенности использования асинхронного ввода/вывода. При вызове сервисов ввода/вывода NT разработчик определяет, вызывать ли их синхронно или асинхронно. Для операций, которые выполняются быстро за определенный интервал времени предпочтителен синхронный ввод-вывод. Асинхронный ввод-вывод дает наибольшее преимущество тогда, когда выполнение операций велико и очень непостоянно.
Асинхронный ввод-вывод требует большого внимания при разработке, но может дать повышение производительности. Поток, использующий асинхронным ввод-вывод, не задерживается на время пересылки данных. Однако он должен синхронизировать использование передаваемых данных с момента завершения передачи устройством.
Выполняя асинхронный ввод-вывод, код пользовательского режима может использовать для такой синхронизации один из нескольких объектов исполнительной системы. Файловые объекты поддерживают синхронизацию, так что самым простым способом является ожидание у описателя файла в некоторой точке после выдачи запроса ввода/вывода. Когда передача данных закончена, диспетчер ввода/вывода устанавливает описатель файла в состояние "свободен", и выполнение ожидающего потока возобновляется.
Послойная модель драйвера. Структура драйвера. Дисковод гибких дисков, жесткий диск, подключенный к шине SCSI, графический дисплей, файловая система FAT и сетевая плата – это радикально отличающиеся друг от друга "устройства", но для диспетчера ввода – вывода между ним практически нет разницы. Каждый драйвер NT содержит следующий стандартный набор компонентов (или его часть):
- Процедура инициализации. Диспетчер ввода/вывода исполняет ее при загрузке драйвера в ОС. Эта процедура создает системные объекты, используемые диспетчером для распознавания драйвера и доступа к нему.
- Набор процедур распределения. Процедуры распределения – это главные функции, предоставляемые драйверами устройств: чтения, записи и другие, поддерживаемые устройством, файловой системой или сетью. Когда диспетчер ввода – вывода получает запрос на выполнение некоторой операции, он генерирует IRP и обращается к драйверу через одну из процедур распределения драйвера.
- Процедура запуска ввода – вывода. Драйвер использует эту процедуру для начала передачи данных на устройство или от него.
- ISR. Диспетчер прерывании ядра передает управление этой процедуре при получении прерывания от устройства. В модели ввода/вывода NT процедуры обслуживания прерываний выполняются на высоком IRQL и выполняют как можно меньший объем работы, чтобы избежать излишнего блокирования низкоуровневых прерываний. Для выполнения оставшейся части обработки прерывания ISR генерирует DРС, который выполняется при меньшем IRQL.
- Процедура DРС для обслуживания прерывания. После выполнения ISR эта процедура выполняет большую часть работы по обслуживанию прерывания. Она исполняется на более низком IRQL, чем ISR, чтобы избежать ненужного блокирования других прерываний. Процедура DРС инициирует завершение ввода – вывода и запускает следующий запрос из очереди на обработку устройством.
- Процедура завершения. Драйвер верхнего уровня может определить процедуру завершения, вызов которой будет уведомлять его о завершении обработки IRP драйвером нижнего уровня. Например, диспетчер ввода/вывода вызывает процедуру завершения файловой системы после того, как драйвер устройства закончит выполнение чтения или записи файла. Процедура завершения информирует файловую систему об успешном окончании, сбое или отмене операции и позволяет последней выполнить необходимую очистку.
- Процедура отмены ввода/вывода. Если имеется возможность отмены операции ввода/вывода, то драйвер может определить одну или несколько процедур отмены. Используемая процедура может изменяться в зависимости от того, насколько далеко продвинулось выполнение операции ввода/вывода. Информация о процедуре отмены, активной в данный момент времени, хранится в IRP.
- Процедура выгрузки. Эта процедура освобождает системные ресурсы, которыми пользовался драйвер, чтобы диспетчер ввода/вывода мог удалить его из памяти. Драйвер может загружаться и выгружаться в процессе работы системы.
- Процедуры протоколирования ошибок. Когда возникает неожиданная ошибка, процедура протоколирования ошибок отмечает этот факт и уведомляет о нем диспетчера ввода/вывода, который записывает соответствующую информацию в файл журнала ошибок.
Объект – драйвер и объект – устройство. Когда поток открывает описатель файлового объекта, диспетчер ввода/вывода по имени этого объекта определяет к какому драйверу он должен обратиться для обработки запроса. Для этого используют следующие объекты:
- Объект-драйвер, представляющий в системе некоторый драйвер и хранящий для диспетчера ввода/вывода адреса всех процедур распределения драйвера (точек входа).
- Объект-устройство, представляющее физическое, логическое или виртуальное устройство, имеющееся в системе.
Объект-драйвер создается диспетчером при загрузке драйвера в систему. После чего диспетчер вызывает процедуру инициализации драйвера, которая заполняет объект точками входа драйвера. Процедура инициализации создает по одному объекту-устройству для каждого устройства, управляемого данным драйвером. Она связывает объекты-устройства с объектом-драйвером. Объект-устройство содержит обратный указатель на объект-драйвер. Часто с объектом – драйвером связано несколько объектов-устройств.
Использование объектов для хранения информации о драйверах избавляет диспетчера ввода/вывода от необходимости знать детали отдельных драйверов.
Особенности NT требуют дополнительной информации при создании драйверов – мультипроцессорная обработка и восстановление после сбоев питания. В многопроцессорной среде прерывание может возникнуть на любом из процессоров, что может вызвать выполнение драйвера на нескольких процессорах. Также восстановить работу после сбоя питания необходимо и в операциях ввода/вывода.
Мультипроцессорная обработка. Основное требование, предъявляемое к коду для многопроцессорной среды, – предотвращать совместное использование ресурса двумя потоками одновременно. Драйвер выполняется одновременно на двух процессорах и синхронизирует доступ к своим данным при помощи спин-блокировки.
Большая часть кода драйвера выполняется на том же IRQL, который был установлен в момент запуска операции ввода/вывода вызывающей программой. Для нормальных потоков пользовательского режима это будет самый низкий IRQL. С другой стороны, прерывания устройств имеют более высокий приоритет. Т.о., устройство может сгенерировать прерывание и вызвать выполнение ISR во время исполнения кода его собственного драйвера. Если драйвер устройства изменял данные, которые изменяет и ISR , то во время выполнения ISR эти данные могут быть разрушены.
Это возможно не только на многопроцессорной системе, но для однопроцессорной можно запретить все прерывания. Запрещение прерываний на одном процессоре не ведет к запрещению прерываний на других. Чтобы избежать таких сложных ситуаций, драйвер NT должен синхронизировать свой доступ к любым данным, которые совместно используются им и ISR. Перед изменением этих данных, драйвер – устройство блокирует доступ к ним всем остальным потокам. Используемая им блокировка должна находиться в памяти, глобальной для всех процессов.