Поскольку объект «файл» — представление разделяемого ресурса в памяти, а не сам ресурс, он отличается от остальных объектов исполнительной системы. Объект «файл» содержит лишь данные, уникальные для описателя объекта, тогда как собственно файл — совместно используемые данные или текст. Всякий раз, когда поток открывает описатель файла, создается новый объект «файл» с новым набором атрибутов, специфичным для этого описателя. Например, атрибут «текущее смещение в байтах» определяет место в файле, где будут записаны или считаны следующие данные по текущему описателю. У каждого описателя одного и того же файла свое значение атрибута «текущее смещение в байтах». Кроме того, объект «файл» уникален для процесса; исключение составляют случаи, когда процесс дублирует описатель файла для передачи другому процессу (через Windows-функцию DuplicateHandle) или когда дочерний процесс наследует описатель файла от родительского. Только в этих двух случаях процессы располагают отдельными описателями, которые ссылаются на один и тот же объект «файл».

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

Имя открываемого файла включает имя объекта «устройство», который представляет устройство, содержащее файл. Например, DeviceFloppyOMyfile.dat ссылается на файл Myfile.dat на дискете в дисководе А. Подстрока «DeviceFloppyO» является внутренним именем объекта «устройство», представляющего данный дисковод. При открытии файла Myfile.dat диспетчер ввода-вывода создает объект «файл», сохраняет в нем указатель на объект «устройство» FloppyO и возвращает описатель файла вызывающему потоку. Впоследствии, когда вызывающий поток воспользуется описателем файла, диспетчер ввода-вывода сможет обращаться непосредственно к объекту FloppyO. Учтите, что внутренние имена устройств неприменимы в Window's-приложениях. Для них имена устройств должны находиться в специальном каталоге пространства имен диспетчера объектов — ?? (в Windows 2000) или Global?? (в Windows XP и Windows Server 2003). B этом каталоге содержатся символьные ссылки на внутренние имена устройств. За создание ссылок в этом каталоге отвечают драйверы устройств. Вы можете просмотреть и даже изменить эти ссылки программным способом, через Windows-функции QueryDosDevice и DefineDosDevice.

ЭКСПЕРИМЕНТ: просмотр сопоставлений Windows-имен устройств внутренним именам устройств

Утилита Winobj (wwwsysinternak.com) позволяет исследовать символьные ссылки, определяющие пространство Windows-имен устройств. Запустите Winobj и выберите каталог ?? в Windows 2000 или Global?? в Windows XP либо Windows Server 2003.

Обратите внимание на символьные ссылки справа. Попробуйте дважды щелкнуть устройство С: — вы должны увидеть нечто вроде того, что показано ниже.

С: представляет собой символьную ссылку на внутреннее устройство с именем DeviceHarddiskVolumel, или на первый том первого жесткого диска в системе. Элемент COMl, показанный Winobj, — символьная ссылка на DeviceSerialO и т. д. Попробуйте создать собственные ссылки командой subst в командной строке.

Обработка ввода-вывода

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

Типы ввода-вывода

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

Синхронный и асинхронный ввод-вывод

Большинство операций ввода-вывода приложений являются синхронными, т. е. приложение ждет, когда устройство выполнит передачу данных и вернет код статуса по завершении операции ввода-вывода. После этого программа продолжает работу и немедленно использует полученные данные. B таком простейшем варианте Windows-функции ReadFile и WriteFile выполняются синхронно. Перед возвратом управления они должны завершить операцию ввода-вывода.

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

Независимо от типа запроса операции ввода-вывода, инициированные драйвером в интересах приложения, выполняются асинхронно, т. е. после выдачи запроса драйвер устройства возвращает управление подсистеме ввода-вывода. A когда она вернет управление приложению, зависит от типа запроса. Схема управления при инициации операции чтения показана на рис. 9–8. Заметьте, что ожидание зависит от состояния флага перекрытия в объекте «файл» и реализуется функцией NtReadFile в режиме ядра.

Вы можете проверить статус незавершенной операции асинхронного ввода-вывода вызовом Windows-функции HasOverlappedIoCompleted. При использовании портов завершения ввода-вывода с той же целью можно вызывать GetQueuedCompletionStatus.

Быстрый ввод-вывод

Быстрый ввод-вывод (fast I/O) — специальный механизм, который позволяет подсистеме ввода-вывода напрямую, не генерируя IRP, обращаться к драйверу файловой системы или диспетчеру кэша (быстрый ввод-вывод описывается в главах 11 и 12). Драйвер регистрирует свои точки входа для быстрого ввода-вывода, записывая их адреса в структуру, на которую ссылается указатель PFASTIODISPATCH его объекта «драйвер».

ЭКСПЕРИМЕНТ: просмотр процедур быстрого ввода-вывода, зарегистрированных драйвером

Список процедур быстрого ввода-вывода, зарегистрированных драйвером в своем объекте «драйвер», выводит команда !drvobj отладчика ядра. Ho такие процедуры обычно имеют смысл только для драйверов файловой системы. Ниже показан список процедур быстрого ввода-вывода для объекта драйвера файловой системы NTFS.

Как показывает вывод, NTFS зарегистрировала свою процедуру NtfsFastIoCheckIfPossible как элемент FastIoCheckIfPossible списка процедур быстрого ввода-вывода. По имени этого элемента можно догадаться, что диспетчер ввода-вывода вызывает эту функцию перед выдачей запроса на быстрый ввод-вывод и в ответ драйвер сообщает, возможны ли операции быстрого ввода-вывода применительно к данному файлу.

Ввод-вывод в проецируемые файлы и кэширование файлов

Ввод-вывод в проецируемые файлы (mapped file I/O) — важная функция подсистемы ввода-вывода, поддерживаемая ею совместно с диспетчером памяти (о проецируемых файлах см. главу 7). Термин «ввод-вывод в проецируемые файлы» относится к возможности интерпретировать файл на диске как часть виртуальной памяти процесса. Программа может обращаться к такому файлу как к большому массиву, не прибегая к буферизации или дисковому вводу-выводу. При доступе программы к памяти диспетчер памяти использует свой механизм подкачки для загрузки нужной страницы из дискового файла. Если программа изменяет какие-то данные в своем виртуальном адресном пространстве, диспетчер памяти записывает эти данные обратно в дисковый файл в ходе обычной операции подкачки страниц.

1 ... 13 14 15 16 17 18 19 20 21 ... 45

На этой странице вы можете бесплатно читать книгу 3.Внутреннее устройство Windows (гл. 8-11) - Марк Руссинович бесплатно.

Похожие на 3.Внутреннее устройство Windows (гл. 8-11) - Марк Руссинович книги

2.Внутреннее устройство Windows (гл. 5-7) - Марк Руссинович - Прочая околокомпюьтерная литература
Windows XP - Виталий Леонтьев - Прочая околокомпюьтерная литература
Журнал PC Magazine/RE №01/2009 - PC Magazine/RE - Прочая околокомпюьтерная литература
Журнал "Компьютерра" N749 - Журнал Компьютерра - Прочая околокомпюьтерная литература
Основы программирования на JavaScript - Марк Кан - Прочая околокомпюьтерная литература
Цифровой журнал «Компьютерра» № 164 - Коллектив Авторов - Прочая околокомпюьтерная литература
Компьютерра PDA 13.03.2010-19.03.2010 - Компьютерра - Прочая околокомпюьтерная литература
Больше денег: что такое Ethereum и как блокчейн меняет мир - Виталий Дмитриевич Бутерин - Прочая околокомпюьтерная литература / Публицистика
Журнал PC Magazine/RE №03/2009 - PC Magazine/RE - Прочая околокомпюьтерная литература
Компьютерра PDA N78 (11.12.2010-17.12.2010) - Компьютерра - Прочая околокомпюьтерная литература

Оставить комментарий