Конспект лекций по дисциплине «Операционные системы и среды»

Вид материала

Конспект

Содержание 4.1.2.Особенности архитектуры 4.1.3.Объектная модель NT 4.1.4.Унифицированная модель драйвера 4.1.5.Асинхронная обработка 4.1.6.Проекционный файловый ввод-вывод и кэширование файлов 4.1.7.Особенности использования асинхронного ввода-вывода

Подобный материал:

• Конспект лекций по дисциплине " Операционные системы", 1459.26kb.
• Ые системы", "Операционные системы, среды и оболочки" и "Операционные системы и системное, 1294.27kb.
• Рабочая программа по учебной дисциплине Операционные системы, среды и оболочки наименование, 623.3kb.
• В. Ф. Панин Конспект лекций по учебной дисциплине "Теоретические основы защиты окружающей, 1559.17kb.
• Программа предназначена для изучения учебного курса по дисциплине "Операционные системы,, 53.62kb.
• Методические указания для выполнения Курсовой работы по дисциплине «Операционные системы», 72.86kb.
• Программа по дисциплине «Технологии программирования и операционные системы», 42.87kb.
• Вопросы к экзамену по дисциплине «Операционные системы и среды», 34.81kb.
• Экзаменационные билеты по дисциплине «операционные системы и среды», 429.29kb.
• Конспект лекций по дисциплине «Маркетинг», 487.79kb.

4.1.2.Особенности архитектуры

Структура системы ввода-вывода NT сложилась как результат одновременного следования традициям и решения вновь возникающих задач. Обратная совмес­тимость является важным соображением при разработке ОС. За исключением редкого случая создания революционно новой ОС, система должна быть совме­стима или, по крайней мере, способна к взаимодействию с существующими си­стемами. Особенно важна обратная совместимость для системы ввода-вывода. Пользователи компьютеров обычно обновляют программное обеспечение чаще, чем покупают новое оборудование. Хотя новая ОС может потребовать установ­ки дополнительной памяти или увеличения объема дискового пространства, она только в крайнем случае может требовать покупки жесткого диска новой модели или замены дисплея. Это означает, что система ввода-вывода должна непремен­но поддерживать старые и даже "древние" устройства.

Тем не менее, Windows 2000 — это ОС, предназначенная для работы на са­мых современных процессорах, использующих технологии 90-х годов. Учесть разнородные и архаичные требования в рамках целостной, общей модели было одной из самых сложных задач при разработке системы ввода-вывода. Другой задачей было создать систему, которая не была бы простым "наименьшим об­щим кратным" устаревших технологий, но которая отвечала бы требованиям будущего и хорошо стыковалась с остальной частью ОС. В следующих разделах описаны некоторые определяющие характеристики модели ввода-вывода NT.

4.1.3.Объектная модель NT

В свое время ОС UNIX определила новый, упрощенный подход к вводу-выводу. В его рамках все считываемые или записываемые данные рассматриваются про­сто как поток байтов, направляемый в виртуальные файлы, которые представ­ляются файловыми дескрипторами. Виртуальный файл (virtual file) обознача­ет любой источник или приемник ввода-вывода, работа с которым идет., как,. ' как"'если бы он был файлом. ОС определяет, является ли "файл" консольным терминалом, каналом или настоящим файлом на диске, и направляет данные в нужное место.

В Windows 2000 программы также осуществляют ввод-вывод в виртуальные... ,файлы манипулируя ими посредством описателей файла (file handles). Концеп­ция описателя файла не нова, но в исполнительной системе NT описатель файла фактически ссылается на файловый объект (file object) исполнительной систе­мы. Все возможные источники или приемники ввода-вывода представлены фай­ловыми объектами. Потоки пользовательского режима вызывают базовые сер-висы файлового объекта NT для чтения из файла, записи в файл и выполнения других операций. Диспетчер ввода-вывода динамически преобразует эти за­просы к виртуальным файлам в запросы к настоящим файлам, каталогам файлов, физическим устройствам, каналам, сетям, почтовым ящикам и любым дру­гим местам назначения, которые только могут возникнуть в будущем.

Как и в других ОС, приложение открывает файл, используя стандартную библиотечную функцию какого-либо языка программирования, например Си. В ответ оно получает (в той или иной форме) описатель файлового объекта ис­полнительной системы NT. Например, когда приложение Win32 вызывает функ­цию fopen(), библиотека Си обращается к функции API Win32 CreateFile(), кото­рая, в свою очередь, вызывает объектный сервис ввода-вывода NT. Диспетчер ввода-вывода открывает файловый объект и возвращает описатель объекта биб­лиотеке Си, которая передает его прикладной программе.

Источники и приемники ввода-вывода представлены в виде объектов, так как они удовлетворяют определению объекта Windows 2000: это системные ре­сурсы, которые могут совместно использоваться потоками двух или более про­цессов пользовательского режима. Файловые объекты, как и другие объекты, имеют иерархические имена, охраняются объектной защитой, поддерживают синхронизацию и обрабатываются объектными сервисами.

Р
ис. 8-2. Открытие файлового объекта.

Открывая файл, пользователь задает имя файла и необходимый тип досту­па — обычно чтение, запись, добавление или удаление. Данный запрос переда­ется подсистеме среды (или DLL), которая обращается к системному сервису NT. Это инициирует поиск имени диспетчером объектов. Как уже было описано в гл. 3, диспетчер объектов начинает поиск в своем пространстве имен, после чего передает управление диспетчеру ввода-вывода, который и отыскивает файловый объект.

Как и другие объекты исполнительной системы , файловые объекты защи­щены дескриптором защиты, содержащим список управления доступом (ACL). Когда поток открывает файл, диспетчер ввода-вывода обращается к подсистеме защиты, чтобы определить, разрешает ли ACL файла процессу доступ запрошен­ного типа. Если доступ разрешен, диспетчер объектов предоставляет его и свя­зывает предоставленные права доступа с возвращаемым описателем файла. Если данный или другой поток процесса собирается выполнять дополнительные опе­рации, не указанные в первоначальном запросе, поток должен открыть другой описатель, что вызывает новую проверку прав доступа (более подробно о защите объектов см. гл. 3, "Диспетчер объектов и контроль доступа").

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

4.1.4.Унифицированная модель драйвера

Второй отличительной чертой системы ввода-вывода является унифицирован­ная структура ее драйверов и широкая интерпретация понятия "драйвер". В ис­полнительной системе NT драйвер устройства и файловая система строятся и выглядят для остальной части ОС одинаково. Более того, именованные каналы и сетевые редиректоры (программное обеспечение, направляющее запросы к фай­лам по разным сетям) рассматриваются как "файловые системы" и реализованы в виде соответствующих драйверов.[Каждый драйвер — автономный компонент, который можно добавлять к ОС и динамически из нее удалять.

Диспетчер ввода-вывода определяет модель построения драйверов. Ос­новные характеристики этой модели таковы:

• Драйверы переносимы и написаны на языке высокого уровня. Они раз­работаны так, чтобы при переносе с одной архитектуры процессора на другую изменений не требовалось или они были минимальны. Драйве­ры верхнего уровня, такие как файловые системы, вообще не требуют изменений.
  
• Операции ввода-вывода управляются пакетами и организуются на ос­нове передачи IRP от одного драйвера другому. По мере их прохожде­ния через различные слои системы ввода-вывода IRP могут' использо­ваться повторно.
  
• Система ввода-вывода может динамически назначать драйверы для уп­равления дополнительными или новыми устройствами при изменении конфигурации системы.
  
• Драйверы должны синхронизировать свой доступ к глобальным дан­ным. В ходе работы драйвер может быть вытеснен потоками более вы­сокого приоритета или прерван высокоприоритетными прерывания­ми. Это обстоятельство, как и то, что NT может выполнять код драйвера на нескольких процессорах одновременно, требует особого внимания к синхронизации.
  

• Драйверы должны корректно восстанавливаться после сбоя питания и перезапускать прерванные операции ввода-вывода² (это не предполагается реализовать в первых версиях драйверов NT, но может быть добавлено в будущих).
  

Унифицированный, модульный интерфейс, предоставляемый драйверами, позволяет диспетчеру ввода-вывода "не видеть" их структуру или внутренние детали. Драйверы могут также вызывать друг друга (через диспетчер ввода-вы­вода), что обеспечивает независимую обработку запроса ввода-вывода на не­скольких уровнях. Рассмотрим следующий пример. Файловая система получает запрос на считывание символов из некоторого файла. Она транслирует перво­начальный запрос в запрос на последовательное считывание определенного ко­личества байтов, начиная с некоторого "логического" адреса на диске. Этот за­прос она передает обычному драйверу диска. Последний, в свою очередь, транс­лирует запрос в форму "цилиндр/дорожка/сектор" и позиционирует головки диска для считывания данных. Такая способность располагать драйверы слоями один над другим обеспечивает модульность и повышает степень повторного ис­пользования кода.

Послойная модель ввода-вывода поддерживает произвольное количество драйверов. В случае однослойной модели запрос на ввод-вывод поступает дис­петчеру и затем к драйверу устройства, который непосредственно работает с устройством, как показано на рис. 8-3.





Рис. 8-3. Ввод-вывод с однослойным драйвером.


Р
ис. 8-4. Ввод-вывод с многослойным драйвером.


На рис. 8-4 показан пример многослойного драйвера; здесь запрос прохо­дит через несколько драйверов. В данном примере имеется два уровня: драйвер файловой системы и драйвер устройства. Обратите внимание, что драйвер верх­него уровня не вызывает нижележащий драйвер напрямую. Вместо этого он обра­щается к диспетчеру ввода-вывода, который и вызывает драйвер нижнего уровня.

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

Доступ к запоминающим устройствам большой емкости всегда выполняет­ся при помощи многослойного драйвера. Сначала запрос проходит через драй­вер файловой системы, а потом через драйвер устройства. Могут быть созданы и более сложные наборы послойных драйверов. Например, в системе может быть несколько устройств, таких как диски или ленты, подсоединенных к шине SCSI (произносится "скази", расшифровывается как Small Computer System Inter­face — Системный интерфейс для небольших компьютеров). Запрос ввода-вы­вода к подобному дисковому накопителю проходит через следующие драйверы:

• драйвер файловой системы;
  
• драйвер класса дисков, который выдает запросы SCSI;
  
• драйвер порта SCSI, посылающий запросы диску с использованием протокола шины SCSI.
  

Все эти драйверы модульные, поэтому каждый из них может использовать­ся и в другой конфигурации.

4.1.5.Асинхронная обработка

Третьей особенностью системы ввода-вывода NT является ее асинхронная природа. Асинхронный ввод-вывод (asynchronous I/O) проще всего определить, описав сначала его противоположность: синхронный ввод-вывод (synchronous I/O). Большинство программистов хорошо знакомы с синхронным вводом-выводом. Вы вызываете сервис ввода-вывода; устройство заканчивает передачу данных и возвращает Вашей программе код завершения; программа может сразу же ис­пользовать переданные данные. В простейшем случае функции API ReadFile() и WriteFile() выполняются синхронно. Прежде чем возвратить управление вызываю­щей программе, они заканчивают выполнение операции ввода-вывода (рис. 8-5).

Синхронный ввод-вывод является стандартным для большинства ОС, и во многих случаях этого достаточно. Однако современные процессоры невероят­но быстры — гораздо быстрее большинства устройств ввода-вывода. Пока уст­ройство обрабатывает один запрос, процессор может выполнить тысячи строк кода. В идеале у приложения должна быть возможность использовать процес­сор, пока устройство пересылает данные. По этим соображениям диспетчер вво­да-вывода предоставляет также и средства асинхронного ввода-вывода. Подси­стема самостоятельно выбирает для себя синхронный или асинхронный ввод-вывод и, в зависимости от поведения ее API, может предоставить своим клиент­ским приложениям ввод-вывод обоих типов. Процедуры доступа к файлам API Win32 могут исполняться как синхронно, так и асинхронно.

Асинхронные сервисы позволяют приложению выдать запрос ввода-вы­вода и продолжать свою работу, пока устройство передает данные (рис. 8-6).

Асинхронный ввод-вывод имеет важное преимущество перед синхрон­ным – возможность повышения скорости работы приложений. Пока устрой­ство занято пересылкой данных, приложение продолжает выполнять другую ра­боту. Например, оно может выводить изображение на монитор, пока драйвер устройства заполняет буфер данными из дискового файла. Чтобы использовать асинхронный ввод-вывод, поток должен указать это (в терминологии Win32 "асинхронный" ввод-вывод называется "совмещенным" — "overlapped") при от­крытии описателя. После начала асинхронной операции ввода-вывода поток должен позаботиться о том, чтобы не использовать никаких данных этой опера­ции до тех пор, пока драйвер устройства не завершит ее. Другими словами, по­ток должен синхронизировать свое выполнение с завершением операции ввода-вывода, ожидая у описателя файла, как показано на рис. 8-6. Приблизительно треть базовых сервисов NT, предоставляемых подсисте­мам диспетчером ввода-вывода, асинхронны по умолчанию. Асинхронными сервисами являются те, которые, вероятно, будут выполняться долгое или вообще непредсказуемое время — например, чтение или запись файла или перебор со­держания каталога файлов. Поток, вызывающий эти сервисы, должен синхро­низировать свое выполнение с их завершением. Альтернативно, поток может заставить все сервисы NT "вести себя" синхронно, задав синхронный ввод-вы­вод при открытии описателя файла.

Е
сть различие между тем, как сервис выглядит для вызывающей его про­граммы, и тем, как он фактически реализован системой ввода-вывода NT. Хотя некоторые сервисы ведут себя синхронно, а некоторые — асинхронно, сама си­стема ввода-вывода работает полностью асинхронно — от обработки прерыва­ний до передачи результатов обратно пользовательскому режиму и запуска исполнения запроса на устройстве. Асинхронный режим обеспечивает систе­ме ввода-вывода возможность гибко переключаться на другие задачи, пока относительно медленные устройства пересылают данные. Асинхронные вызовы процедур (АРС) — другое средство NT и асинхронного ввода-вывода Win32 — описаны в разделе 8.2.2.3.


Рис. 8-5. Синхронный ввод-вывод.





Рис. 8-6. Асинхронный ввод-вывод.

4.1.6.Проекционный файловый ввод-вывод и кэширование файлов

Проекционный файловый ввод-вывод (mapped file I/O) — это важное средство системы ввода-вывода, обеспечиваемое совместной работой этой системы и диспетчера виртуальной памяти. Сама ОС использует проекционный ввод-вывод для выполнения важных функций, таких как кэширование файлов или загрузка и выполнение программ. Диспетчер виртуальной памяти также дела­ет проекционный ввод-вывод доступным пользовательскому режиму через базовые сервисы. Подсистемы среды могут использовать эти сервисы для предоставления средств проекционного файлового ввода-вывода своим кли­ентским программам.

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

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

Компонент системы ввода-вывода, называемый диспетчером кэша, при­меняет проекционный ввод-вывод для управления своим кэшем в памяти. Фай­ловые системы и сетевой сервер Windows 2000 используют этот кэш для размеще­ния в памяти часто требуемых данных, чтобы снизить время отклика для про­грамм, выполняющих много операций ввода-вывода. Тогда как большинство систем кэширования выделяют в памяти файловый кэш фиксированного разме­ра, кэш NT растет или уменьшается в зависимости от объема доступной памяти. Когда поток открывает и использует файл, файловая система обращается к дис­петчеру кэша для создания неименованного объекта-секции и отображения в него файла¹. Когда же вызывающая программа использует файл, диспетчер виртуальной памяти переносит страницы, к которым осуществляется доступ, с дис­ка в объект-секцию и обратно на диск в ходе подкачки. Средство подкачки ав­томатически расширяет размер кэша (используя обычные механизмы рабочего набора), если доступно много памяти, и уменьшает его, если необходимы сво­бодные страницы. Используя систему подкачки страниц диспетчера виртуаль­ной памяти, диспетчер кэша избегает дублирования этой работы.

4.1.7.Особенности использования асинхронного ввода-вывода

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

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

Выполняя асинхронный ввод-вывод, код пользовательского режима мо­жет использовать для такой синхронизации один из нескольких объектов ис­полнительной системы. Файловые объекты поддерживают синхронизацию, так что самым простым способом является ожидание у описателя файла в некото­рой точке после выдачи запроса ввода-вывода. Когда передача данных законче­на, диспетчер ввода-вывода устанавливает описатель файла в состояние "свобо­ден", и выполнение ожидающего потока возобновляется.

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