Главная Учебники - Разные Лекции (разные) - часть 34
|
Содержание 1.1. Предмет и задачи курса. 5
1.2. Рекомендации по литературе. 5
1.3. Краткий очерк истории ОС.. 6
1.6. Основные функции и структура ОС.. 14
1.7. ОС, используемые в дальнейшем изложении. 14
2. Управление устройствами. 14
2.1. Основные задачи управления устройствами. 14
2.2. Классификация периферийных устройств и их архитектура. 14
2.4. Архитектура подсистемы ввода/вывода. 14
2.5. Способы организации ввода/вывода. 14
2.6. Буферизация и кэширование. 14
2.8. Управление устройствами в MS-DOS. 14
2.9. Управление устройствами в Windows. 14
2.10. Управление устройствами в UNIX.. 14
3.1. Основные задачи управления данными. 14
3.2. Характеристики файлов и архитектура файловых систем.. 14
3.5. Разделение файлов между процессами. 14
3.6. Файловая система FAT и управление данными в MS-DOS. 14
3.7. Файловые системы и управление данными в UNIX.. 14
3.8. Файловая система NTFS и управление данными в Windows. 14
4.1. Основные задачи управления процессами. 14
4.2. Реализация многозадачного режима. 14
4.3. Проблемы взаимодействия процессов. 14
4.4. Управление процессами в MS-DOS. 14
4.5. Управление процессами в Windows. 14
4.6. Управление процессами в UNIX.. 14
5.1. Основные задачи управления памятью.. 14
5.2. Виртуальные и физические адреса. 14
5.3. Распределение памяти без использования виртуальных адресов. 14
5.4. Сегментная организация памяти. 14
5.5. Страничная организация памяти. 14
5.6. Сравнение сегментной и страничной организации. 14
5.7. Управление памятью в MS-DOS. 14
5.8. Управление памятью в Windows. 14
5.9. Управление памятью в UNIX.. 14
Предметом изучения в данном курсе являются операционные системы
(ОС) современных компьютеров. В первом приближении ОС можно определить как комплекс программ, обеспечивающих интерфейс между аппаратурой компьютера, прикладными программами и пользователем компьютера. Соответственно этому определению, все функции, выполняемые ОС, подчинены решению двух основных задач: · организации эффективной работы аппаратуры компьютера; · обеспечению удобного использования ресурсов компьютера как прикладными программами, так и пользователем, работающим с компьютером. Основной целью курса является изучение устройства и функционирования современных ОС. При этом будут рассматриваться два круга вопросов: · основные принципы построения ОС, наиболее распространенные алгоритмы выполнения различных функций ОС, типовые структуры данных, используемые для обеспечения работы ОС; · практическое воплощение этих принципов, алгоритмов, структур в наиболее распространенных современных ОС. В задачи курса не входит обучение практическим приемам работы с конкретными ОС. Это гораздо лучше делать самостоятельно. С другой стороны, не ставится и задача научить слушателей разрабатывать новые ОС. Операционные системы не являются массовыми изделиями, и участвовать в их разработке доводится лишь меньшей части программистов. Уровень знаний, которого хотелось бы достичь при изучении данного предмета, можно сравнить с тем уровнем знаний об устройстве автомобиля, который полезен хорошему водителю. Он не обязательно должен быть автомехаником, однако должен в основных чертах понимать, что находится под капотом и как оно там крутится. Содержание лекционного курса не обязательно на 100% совпадет с данным конспектом, поэтому надежнее всего ходить на лекции и иметь к экзамену собственный конспект. Из книг общего характера учебник /1/ более всего соответствует данному курсу, как по содержанию, так и в еще большей степени по общему взгляду на предмет. Эту книгу можно найти и в Сети, а также в локальной сети кафедры. Похвалы и уважения заслуживает книга /2/ - огромный по объему и достаточно простой по изложению обзор всего важного об ОС. Достаточно хороша также книга /3/, используемая как основной учебник по ОС во многих американских университетах. Лентяям пригодится книга /4/, в которой, наряду с другими вопросами системного программирования, кратко и довольно толково изложены основные проблемы ОС. Правда, книга старовата. Книги /5/ и /6/ содержат много полезного по практическим вопросам проектирования ОС, а /7/ остается хорошим источником по теоретическим и алгоритмическим вопросам. Из литературы по Windows следует прежде всего рекомендовать классическую книгу /8/, которая делает понятными многие вопросы, трудно перевариваемые по официальной документации. Более глубокий разбор того, «как это сделано в Windows», можно найти в книге /9/. К сожалению, эта книга заметно уступает замечательной, но устаревшей по материалу книге того же автора /10/, которую, тем не менее, полезно прочесть тем, кого интересуют вопросы практической реализации ОС. На фоне неисчислимых и неотличимых друг от друга пользовательских руководств по UNIX следует выделить достаточно серьезную работу /11/. Не потеряла интереса старенькая, тонкая книжка /12/, в которой содержится много полезного об основных структурах данных и алгоритмах UNIX. Намного подробнее те же вопросы рассмотрены в другой старой книге, которая давно приобрела известность в электронном варианте /13/. Бумажное издание этой книги на русском языке существует только в пиратском варианте, без указания имени автора. Для тех, кого еще интересует MS-DOS, можно порекомендовать /14/, это одна из лучших книг на данную тему. Некоторые алгоритмы, используемые при реализации различных ОС, хорошо изложены в классической книге /15/. Большие коллекции литературы и документации по ОС имеются в Интернете. Среди русскоязычных сайтов можно рекомендовать, например, /16, 17, 18, 19, 20/. Знание английского языка открывает доступ к морю свежей информации в Интернете. Огромная куча сведений по Windows содержится в /21/. На сайте /22/ можно найти интересные статьи по отдельным вопросам архитектуры Windows, а также скачать ряд полезных утилит. Из большого числа сайтов, посвященных UNIX и Linux, можно назвать, например, /23/ и /24/. На сайте /25/ можно найти много статей и книг по актуальным вопросам программирования, в том числе по ОС. Изучение истории развития ОС показывает, что все существенные продвижения в области архитектуры ОС связаны с влиянием двух основных факторов: · прогресс технологии, приводящий к быстрому возрастанию характеристик аппаратуры ЭВМ и к появлению принципиально новых типов аппаратуры; · принципиально новые идеи, возникающие у проектировщиков. Не ввязываясь в давний спор материалистов с идеалистами, в данном частном случае приходится признать, что первый, материальный фактор определял развитие ОС на 80 – 90%. Такие технологические прорывы, как изобретение магнитных дисков, микропроцессоров, создание высококачественных видеомониторов, настоятельно требовали радикальных изменений в технологии работы с компьютером, и вследствие этого обуславливали создание принципиально новых типов ОС или их отдельных подсистем. С другой стороны, некоторые идеи в области организации вычислительного процесса и интерфейса дали серьезный толчок совершенствованию архитектуры компьютеров. Не зная хотя бы в общих чертах основных этапов развития аппаратного и программного обеспечения, трудно понять многие особенности современных ОС. Дополнительный аргумент в пользу знания истории заключается в том, что многие технические решения, которые, казалось, навсегда ушли в прошлое вместе с конкретными системами, неожиданно вновь оказываются актуальными на новом витке развития. Некоторые примеры такого рода будут рассмотрены в курсе. 1.3.1. Предыстория ОС Вскоре после того, как в конце 40-х годов XX века были созданы первые электронные компьютеры, очень остро встала проблема повышения эффективности использования оборудования, и прежде всего центрального процессора. Типичный компьютер первого – второго поколений представлял собой большую комнату, уставленную шкафами и увитую кабелями. Каждое из основных устройств – центральный процессор, оперативная память, накопители на магнитных лентах, устройства ввода с перфокарт, принтер – занимало один или несколько «шкафов» или «тумб», наполненных радиолампами и механическими частями. Все это стоило больших денег, потребляло бешеное количество электроэнергии[1]
и регулярно ломалось. В таких условиях машинное время стоило очень дорого. Тем не менее, обычная практика использования ЭВМ не способствовала экономии. Как правило, программист, разрабатывающий программу, заказывал ежедневно несколько часов машинного времени и в течение этого времени монопольно использовал машину. Выполнив очередной запуск отлаживаемой программы (которую надо было каждый раз вводить либо с клавиатуры, либо, в лучшем случае, с перфокарт), пользователь получал распечатку (чаще всего в виде массива цифр), анализировал результаты, вносил изменения в программу и снова запускал ее. Таким образом, в ходе сеанса отладки дорогостоящее оборудование простаивало 99% времени, пока программист осмысливал результаты и работал с устройствами ввода/вывода. Кроме того, сбой при вводе одной перфокарты мог потребовать начать сначала всю работу программы. Возникла великая идея – использовать сам компьютер для повышения эффективности работы с ним же. Одно из ответвлений этой идеи – создание языков и систем программирования – рассматривается в отдельных курсах. Другим важным шагом стало возложение на специальную компьютерную программу части тех функций, которые до этого выполнял оператор или сам программист. Программы такого рода назывались обычно мониторами
(не путать с монитором как устройством вывода, который в то время был редчайшей экзотикой!). Монитор принимал команды, состоящие, как правило, из 1-2 букв названия и 1-3 аргументов, заданных 8-ричными или 16-ричными числами. Типичными командами были, например: · загрузка данных с перфокарт по указанному адресу памяти; · просмотр и корректировка (с пишущей машинки) значений в указанном диапазоне адресов; · пошаговое выполнение программы с выдачей результатов каждой команды на пишущую машинку; · запуск программы с указанного адреса с заданием адресов контрольных точек остановки. Несмотря на убогость, по нынешним меркам, подобных средств, они в свое время значительно повысили производительность работы программистов. Однако кардинального повышения загрузки процессора не произошло. Временем широкого распространения мониторов в мире были 50-е годы прошлого века (в СССР – 60-е годы). В настоящее время нечто подобное можно встретить на самых примитивных микропроцессорных контроллерах. 1.3.2. Пакетные ОС Историю собственно ОС можно начать с появления в конце 50-х годов первых систем, организующих работу по пакетному принципу. Важнейшим организационным изменением, происшедшим на этом этапе развития, стало массовое изгнание программистов из машинных залов, как фактора, лишь вносящего сумятицу в работу. Теперь от программиста требовалось собрать пакет перфокарт, содержащий его программу, данные к ней, а также управляющие перфокарты. Эти карты на специально разработанном языке управления заданиями
(JCL, JobControlLanguage) объясняли операционной системе, чье это задание, что нужно сделать с программой (например, передать ее транслятору с Фортрана), что предпринять в случае успешной трансляции (вероятно, пустить на решение), что – при наличии ошибок (например, перейти к другой программе), откуда взять исходные данные (например, с такого-то цилиндра магнитного диска). Кроме того, там могли быть даже указания на то, сколько метров бумаги можно выделить на распечатку и какое максимальное время может занять работа программы. Обойтись без столь подробных инструкций было нельзя, потому что программист не присутствовал при запуске задания и не мог вмешаться лично. Подготовленный пакет передавался, вместе с другими подобными пакетами, оператору ЭВМ, перед которым стояли две основные задачи: чтобы в устройстве ввода не переводились пакеты заданий и чтобы в принтере не кончилась бумага. Когда процессор заканчивал обработку задания и печать его результатов, он вводил следующий пакет и приступал к его обработке. Так достигалась основная цель пакетного режима – исключить простои процессора из-за нерасторопности людей. В скором времени разработчики ОС осознали, что вычерпаны далеко не все резервы повышения загрузки процессора. Операции ввода и печати требовали лишь очень небольшой доли от полной производительности процессора. Кроме того, в ходе работы программы случались обращения к периферийным устройствам (например, к магнитным лентам и, позднее, дискам), при выполнении которых процессор опять простаивал. Целесообразно было найти способ, чтобы в эти периоды ожидания загрузить процессор другой работой. Но для этого необходимо, чтобы в памяти процессора находились сразу несколько программ, тогда ОС смогла бы переключать процессор на выполнение той программы, которая в данный момент может работать. Такая организация работы, когда в памяти находятся несколько программ и система в определенные моменты переключает выполнение с одной программы на другую, была названа мультипрограммированием
. Эта важная идея в разных воплощениях пережила те пакетные системы, в которых она впервые была реализована, и является основой для функционирования практически всех современных ОС. Среди наиболее развитых пакетных ОС с мультипрограммированием нельзя не назвать OS/360, основную ОС знаменитого в 60-70 гг. семейства ЭВМ IBM 360/370. 1.3.3. ОС с разделением времени
На рубеже 60-70 гг. распространенным и не слишком дорогим периферийным устройством становятся мониторы (сначала монохромные и работающие только в текстовом режиме). При этом процессор и ОЗУ остаются самыми дорогими и громоздкими устройствами вычислительной системы. В этих условиях возникает и быстро приобретает популярность принципиально новый тип ОС – системы с разделением времени
. К одной ЭВМ подключается несколько десятков рабочих мест, оборудованных дисплеем (монитор + клавиатура) и совместно использующих вычислительные ресурсы ЭВМ. Процессорное время делится на кванты длительностью в несколько десятков миллисекунд и по истечении каждого кванта процессор может быть переключен на обслуживание другого процесса, другого дисплея. Поскольку теперь подготовку текстов программ выполняют сами программисты за дисплеями, а работа по редактированию текста требует очень малых затрат процессорного времени, процессор успевает обслужить все рабочие места практически без ощутимой задержки. Большая часть времени процессора уделяется небольшому числу рабочих мест, где в данный момент запущены на выполнение программы. При этом, разумеется, средняя скорость работы каждой программы уменьшается, по крайней мере во столько раз, сколько программ выполняется одновременно. Режим разделения времени стал огромным облегчением для программистов, которые вновь смогли в некоторой степени почувствовать себя «хозяевами» ЭВМ и получили возможность запускать программы на трансляцию и отладку хоть каждые 5 минут. Это позволило сократить сроки разработки и отладки программ. Для трудоемких вычислительных заданий, предусматривающих счет по ранее отлаженным программам, режим разделения времени менее эффективен, чем пакетный, поскольку частое переключение процессора между выполняемыми программами требует дополнительных затрат времени. Системы разделения времени используются в режиме диалога с пользователем, поэтому вместо громоздких, детализированных операторов JCL в них используются более простые команды, выполняющие элементарные действия – запуск программы, выдача на экран файла или каталога, копирование или удаление файла и т.п. Пользователю не нужно предвидеть заранее все возможные исходы выполнения команды, гораздо проще увидеть результат выполнения на экране и после этого принять решение, какую команду выполнять следующей. В то же время, некоторые часто повторяющиеся последовательности команд удобно описать один раз в виде «пакетного задания» и затем использовать при необходимости. В этом плане системы разделения времени сохраняют те удобные возможности, которые предоставляли пакетные системы. Первоначально в качестве аппаратной основы систем разделения времени должны были использоваться «большие» ЭВМ, которые позднее стало принято называть «мейнфреймами» (mainframes). Позднее, по мере прогресса вычислительной техники, это стало по плечу даже миниЭВМ (так назывался в те годы класс компьютеров, занимавших всего лишь один-два небольших шкафчика). Следует особо упомянуть серию миниЭВМ PDP-11, имевшую широчайшее распространение во всем мире в течение полутора десятков лет. Этот период (70-е годы в мире, 80-е в СССР) характерен глубоким развитием теории и практики создания мощных ОС, содержащих развитые средства управления процессами и памятью, реализующих многопользовательский режим работы. Из большого числа подобных систем особого упоминания заслуживает UNIX – единственная система, благополучно дожившая до нашего времени. 1.3.4. Однозадачные ОС для ПЭВМ В середине 70-х годов был изобретен микропроцессор, а к началу 80-х микропроцессоры стали догонять по функциональным характеристикам ранее использовавшиеся «большие» процессоры. Эта ситуация сделала почти бесполезным режим разделения времени: зачем делить один процессор между многими задачами и многими пользователями, если проще и дешевле дать отдельный микропроцессор каждому пользователю? Разделение времени осталось целесообразным разве что в отношении суперкомпьютеров. Появление и бурное распространение персональных компьютеров (ПК) вызвало к жизни новое поколение ОС, которые оказались во много раз проще своих предшественниц. Ненужной оказалась многопользовательская защита. На первых порах показалась ненужной и многозадачность. Все это можно было расценить как явный регресс в развитии ОС. Наиболее популярной ОС для ранних восьмиразрядных ПК была система CP/M известной тогда фирмы DigitalResearch, однако с появлением в начале 80-х знаменитой машины IBMPC лидерство было прочно перехвачено системой MS-DOS фирмы Microsoft. 1.3.5. Многозадачные ОС для ПК с графическим интерфейсом Быстрое развитие технологии привело к тому, что к концу 80-х годов ПК оказались в состоянии решать значительно более сложные и трудоемкие задачи, чем раньше. При этом многие из достижений прежних этапов развития ОС оказались вновь востребованными, но теперь уже в новых условиях, среди которых надо назвать резкое повышение мощности процессоров и объема памяти, появление высококачественных графических мониторов и развитие сетевых технологий. Стала реальной такая вещь, как многозадачная ОС для ПК. Надо сказать, что первоначально идея системы, в которой один пользователь запускает одновременно несколько приложений, большинству специалистов казалась пустым пижонством и вызывала насмешки: «Почему бы не выполнить несколько программ по очереди?». Сейчас с таким взглядом смешно даже спорить. А все же, как бы вы обосновали пользу многозадачности для современных ОС типа Windows? На смену ОС, которые выполняли текстовые команды, вводимые пользователем с клавиатуры, пришли системы, в которых взаимодействие с пользователем основано на использовании GUI (GraphicalUserInterface, графический интерфейс пользователя). Значительная часть ПК работает в составе локальных вычислительных сетей. Это привело к тому, что вопросы защиты данных пользователя вновь приобрели первостепенное значение. Существуют различные виды классификации ОС по тем или иным признакам, отражающие разные существенные характеристики систем. · По назначению. - Системы общего назначения. Это достаточно расплывчатое название подразумевает ОС, предназначенные для решения широкого круга задач, включая запуск различных приложений, разработку и отладку программ, работу с сетью и с мультимедиа. - Системы реального времени
. Этот важный класс систем предназначен для работы в контуре управления объектами (такими, как летательные аппараты, технологические установки, автомобили, сложная бытовая техника и т.п.). Из подобного назначения вытекают жесткие требования к надежности и эффективности системы. Должно быть обеспечено точное планирование действий системы во времени (управляющие сигналы должны выдаваться в заданные моменты времени, а не просто «по возможности быстро»). Особый подкласс составляют системы, встроенные
в оборудование. Такие системы годами могут выполнять фиксированный набор программ, не требуя вмешательства человека-оператора на более глубоком уровне, чем нажатие кнопки «Вкл.». Иногда выделяют также такой класс ОС, как системы с «нежестким» реальным временем. Это такие системы, которые не могут гарантировать точное соблюдение временных соотношений, но «очень стараются», т.е. содержат средства для приоритетного выполнения заданий, критичных по времени. Такой системе нельзя доверить управление ракетой, но она вполне справится с демонстрацией видеофильма. Выделение подобных систем в отдельный класс имеет скорее рекламное значение, позволяя таким системам, как WindowsNT и некоторые версии UNIX, тоже называть себя «системами реального времени». - Прочие специализированные системы. Это различные ОС, ориентированные прежде всего на эффективное решение задач определенного класса, с большим или меньшим ущербом для прочих задач. Можно выделить, например, сетевые системы (такие, как NovellNetware), обеспечивающие надежное и высокоэффективное функционирование локальных сетей. · По характеру взаимодействия с пользователем. - Пакетные ОС, обрабатывающие заранее подготовленные задания. - Диалоговые ОС, выполняющие команды пользователя в интерактивном режиме. Красивое слово «интерактивный» означает постоянное взаимодействие системы с пользователем. - ОС с графическим интерфейсом. В принципе, их также можно отнести к диалоговым системам, однако использование мыши и всего, что с ней связано (меню, кнопки и т.п.) вносит свою специфику. - Встроенные ОС, не взаимодействующие с пользователем. · По числу одновременно выполняемых задач. - Однозадачные ОС. В таких системах в каждый момент времени может существовать не более чем один активный пользовательский процесс. Следует заметить, что одновременно с ним могут работать системные процессы (например, выполняющие запросы на ввод/вывод). - Многозадачные ОС. Они обеспечивают параллельное выполнение нескольких пользовательских процессов. Реализация многозадачности требует значительного усложнения алгоритмов и структур данных, используемых в системе. · По числу пользователей. - Однопользовательские ОС. Для них характерен полный доступ пользователя к ресурсам системы. Подобные системы приемлемы в основном для изолированных компьютеров, не допускающих доступа к ресурсам данного компьютера по сети или с удаленных терминалов. - Многопользовательские ОС. Их важной компонентой являются средства защиты данных и процессов каждого пользователя, основанные на понятии владельца ресурса и на точном указании прав доступа, предоставленных каждому пользователю системы. · По аппаратурной основе. - Однопроцессорные ОС. В данном курсе будут рассматриваться только они. - Многопроцессорные ОС. В задачи такой системы входит, помимо прочего, эффективное распределение выполняемых заданий по процессорам и организация согласованной работы всех процессоров. - Сетевые ОС. Они включают возможность доступа к другим компьютерам локальной сети, работы с файловыми и другими серверами. - Распределенные ОС. Их отличие от сетевых заключается в том, что распределенная система, используя ресурсы локальной сети, представляет их пользователю как единую систему, не разделенную на отдельные машины. При сравнительном рассмотрении различных ОС в целом или их отдельных подсистем возникает вечный вопрос – какая из них лучше и почему, какая архитектура системы предпочтительнее, какой из алгоритмов эффективнее, какая структура данных удобнее и т.п. Очень редко можно дать однозначный ответ на подобные вопросы, если речь идет о практически используемых системах. Система или ее часть, которая хуже других систем во всех отношениях, просто не имела бы права на существование. На самом деле имеет место типичная многокритериальная задача: имеется несколько важных критериев качества, и система, опережающая прочие по одному критерию, обычно уступает по другому. Сравнительная важность критериев зависит от назначения системы и условий ее работы. 1.5.1. Надежность Этот критерий вообще принято считать самым важным при оценке программного обеспечения, и в отношении ОС его действительно принимают во внимание в первую очередь. Что понимается под надежностью ОС? Прежде всего, ее живучесть
, т.е. способность сохранять хотя бы минимальную работоспособность в условиях аппаратных сбоев и программных ошибок. Высокая живучесть особенно важна для ОС компьютеров, встроенных в аппаратуру, когда вмешательство человека затруднено, а отказ компьютерной системы может иметь тяжелые последствия. Во-вторых, способность, как минимум, диагностировать, а как максимум, компенсировать хотя бы некоторые типы аппаратных сбоев. Для этого обычно вводится избыточность хранения наиболее важных данных системы. В-третьих, ОС не должна содержать собственных (внутренних) ошибок. Это требование редко бывает выполнимо в полном объеме (программисты давно сумели доказать своим заказчикам, что в любой большой программе всегда есть ошибки, и это в порядке вещей), однако следует хотя бы добиться, чтобы основные, часто используемые или наиболее ответственные части ОС были свободны от ошибок. Наконец, к надежности системы следует отнести ее способность противодействовать явно неразумным действиям пользователя. Обычный пользователь должен иметь доступ только к тем возможностям системы, которые необходимы для его работы. Если же пользователь, даже действуя в рамках своих полномочий, пытается сделать что-то очень странное (например, отформатировать системный диск), то самое малое, что должна сделать ОС, это переспросить пользователя, уверен ли он в правильности своих действий. 1.5.2. Эффективность Как известно, эффективность любой программы определяется двумя группами показателей, которые можно обобщенно назвать «время» и «память». При разработке системы приходится принимать много непростых решений, связанных с оптимальным балансом этих показателей. Важнейшим показателем временнóй эффективности является производительность
системы, т.е. усредненное количество полезной вычислительной работы, выполняемой в единицу времени. С другой стороны, для диалоговых ОС не менее важно время реакции
системы на действия пользователя. Эти показатели могут в некоторой степени противоречить друг другу. Например, в системах разделения времени увеличение кванта времени повышает производительность (за счет сокращения числа переключений процессов), но ухудшает время реакции. В программировании известна аксиома: выигрыш во времени достигается за счет проигрыша в памяти, и наоборот. Это в полной мере относится к ОС, разработчикам которых постоянно приходится искать баланс между затратами времени и памяти. Забота от эффективности долгое время стояла не первом месте при разработке программного обеспечения, и особенно ОС. К сожалению, оборотной стороной стремительного увеличения мощности компьютеров стало ослабление интереса к эффективности программ. В настоящее время эффективность является первостепенным требованием разве что в отношении систем реального времени. 1.5.3. Удобство Этот критерий наиболее субъективен. Можно предложить, например, такой подход: система или ее часть удобна, если она позволяет легко и просто решать те задачи, которые встречаются наиболее часто, но в то же время содержит средства для решения широкого круга менее стандартных задач (пусть даже эти средства не столь просты). Пример: такое частое действие, как копирование файла, должно выполняться при помощи одной простой команды или легкого движения мыши; в то же время для изменения разделов диска не грех почитать руководство, поскольку это может понадобиться даже не каждый год. Разработчики каждой ОС имеют собственные представления об удобстве, и каждая ОС имеет своих приверженцев, считающих именно ее идеалом удобства. 1.5.4. Масштабируемость Довольно странный термин «масштабируемость» (scalability) означает возможность настройки системы для использования в разных вариантах, в зависимости от мощности вычислительной системы, от набора конкретных периферийных устройств, от роли, которую играет конкретный компьютер (сервер, рабочая станция или изолированный компьютер) от назначения компьютера (домашний, офисный, исследовательский и т.п.). Гарантией масштабируемости служит продуманная модульная структура системы, позволяющая в ходе установки системы собирать и настраивать нужную конфигурацию. Возможен и другой подход, когда под общим названием объединяются, по сути, разные системы, обеспечивающие в разумных пределах программную совместимость. Примером могут служить версии WindowsNT/2000/XP, Windows 95/98 и WindowsCE. В некоторых случаях фирмы, производящие программное обеспечение, искусственно отключают в более дешевых версиях системы те возможности, которые на самом деле реализованы, но становятся доступны, только если пользователь покупает лицензию на более дорогую версию. Но это уже вопрос, связанный не с технической стороной дела, а с маркетинговой политикой. 1.5.5. Способность к развитию Чтобы сложная программа имела шансы просуществовать долго, в нее изначально должны быть заложены возможности для будущего развития. Одним из главных условий способности системы к развитию является хорошо продуманная модульная структура, в которой четко определены функции каждого модуля и его взаимосвязи с другими модулями. При этом создается возможность совершенствования отдельных модулей с минимальным риском вызвать нежелательные последствия для других частей системы. Важным требованием к развитию ОС является совместимость версий снизу вверх
, означающая возможность безболезненного перехода от старой версии к новой, без потери ранее наработанных прикладных программ и без необходимости резкой смены всех навыков пользователя. Обратная совместимость – сверху вниз – как правило, не гарантируется, поскольку в ходе развития система приобретает новые возможности, не реализованные в старых версиях. Программа из Windows3.1 будет нормально работать и в WindowsXP; наоборот – вряд ли. Фирмы-производители ОС прилагают максимум усилий для обеспечения совместимости снизу вверх, чтобы не отпугнуть пользователей. Но при этом фирмы стараются в каждую новую версию заложить какую-нибудь новую конфетку, которая побудила бы пользователей как можно скорее купить ее. Совместимость версий – благо для пользователя, однако на практике она часто приводит к консервации давно отживших свой век особенностей или же просто неудачных решений, принятых в ранней версии системы. В документации подобные архаизмы помечаются как «устаревшие» (obsolete), но полного отказа от них, как правило, не происходит (а вдруг где-то еще работает прикладная программа, написанная двадцать лет назад с использованием именно этих средств?). Как правило, наиболее консервативной стороной любой ОС являются не алгоритмы, а структуры системных данных, поэтому дальновидные разработчики заранее строят структуры «на вырост»: закладывают в них резервные поля, используют переменные вместо некоторых констант, устанавливают количественные ограничения с большим запасом и т.п. 1.5.6. Мобильность Под мобильностью
(portability) понимается возможность переноса программы (в данном случае ОС) на другую аппаратную платформу, т.е. на другой тип процессора и другую архитектуру компьютера. Здесь имеется в виду перенос с умеренными трудозатратами, не требующий полной переработки системы. Свойство мобильности не столь однозначно положительно, как может показаться. Чтобы программа была мобильна, при ее разработке следует отказаться от глубокого использования особенностей конкретной архитектуры (таких, как количество и функциональные возможности регистров процессора, нестандартные команды и т.п.). Мобильная программа должна быть написана на языке достаточно высокого уровня (часто используется язык C), который можно реализовать на компьютерах любой архитектуры. Платой за мобильность всегда является некоторая потеря эффективности, поэтому немобильные системы распространены достаточно широко. С другой стороны, история системного программирования усеяна останками замечательных, эффективных и удобных, но немобильных ОС, которые вымерли вместе с процессорами, для которых они предназначались. В то же время мобильная система UNIX продолжает процветать четвертый десяток лет, намного пережив те компьютеры, для которых она первоначально создавалась. Примерно 5-10% исходных текстов UNIX написаны на языка ассемблера и должны переписываться заново при переносе на новую архитектуру. Остальная часть системы написана на C и практически не требует изменений при переносе. Некоторым компромиссом являются многоплатформенные
ОС (например, WindowsNT), изначально спроектированные для использования на нескольких аппаратных платформах, но не гарантирующие возможность переноса на новые, не предусмотренные заранее архитектуры. Согласно многолетней традиции, при рассмотрении основ функционирования ОС принято выделять четыре основных группы функций, выполняемых системой. · Управление устройствами
. Имеются в виду все периферийные устройства, подключаемые к компьютеру, – клавиатура, монитор, принтеры, диски и т.п. · Управление данными
. Под этим старинным термином сейчас понимается работа с файлами, хотя были времена, когда обращение к данным на магнитных носителях выполнялось путем указания адреса размещения данных на устройстве, а понятия файла не существовало. · Управление процессами
. Эта сторона работы ОС связана с запуском и завершением работы программ, обработкой ошибок, обеспечением параллельной работы нескольких программ на одном компьютере. · Управление памятью
. Оперативная память компьютера – это такой ресурс, которого всегда не хватает. В этих условиях разумное планирование использования памяти является важнейшим фактором эффективной работы. Имеется еще несколько важных обязанностей, ложащихся на ОС, которые трудно втиснуть в рамки традиционной классификации функций. К ним, прежде всего, относятся следующие. · Организация интерфейса с пользователем
. Формы интерфейса могут быть разнообразными, в зависимости от типа и назначения ОС: язык управления пакетами заданий, набор диалоговых команд, средства графического интерфейса. · Защита данных
. Как только система перестает быть достоянием одного изолированного от внешнего мира пользователя, вопросы защиты данных от несанкционированного доступа приобретают первостепенную важность. ОС, обеспечивающая работу в сети или в системе разделения времени, должна соответствовать имеющимся стандартам безопасности. · Ведение статистики
. В ходе работы ОС должна собираться, храниться и анализироваться разнообразная информация: о количестве времени, затраченном различными программами и пользователями, об интенсивности использования ресурсов, о попытках некорректных действий пользователей, о сбоях оборудования и т.п. Собранная информация хранится в системных журналах и в учетных записях пользователей. Для понимания работы ОС необходимо уметь выделять основные части системы и их связи, т.е. описывать структуру системы. Для разных ОС их структурное деление может быть весьма различным. Наиболее общими видами структуризации можно считать два. С одной стороны, можно считать, что ОС разделена на подсистемы, соответствующие перечисленным выше группам функций. Такое деление достаточно обосновано, программные модули ОС действительно в основном можно отнести к одной из этих подсистем. Другое важное структурное деление связано с понятием ядра
системы. Ядро, как можно понять из названия, это основная, «самая системная» часть операционной системы. Имеются разные определения ядра. Согласно одному из них, ядро – это резидентная
часть системы, т.е. к ядру относится тот программный код, который постоянно находится в памяти в течение всей работы системы. Остальные модули ОС являются транзитными
, т.е. подгружаются в память с диска по мере необходимости на время своей работы. К транзитным частям системы относятся: · утилиты
(utilities) – отдельные системные программы, решающие частные задачи, такие как форматирование и проверку диска, поиск данных в файлах, мониторинг (отслеживание) работы системы и многое другое; · системные библиотеки подпрограмм
, позволяющие прикладным программам использовать различные специальные возможности, поддерживаемые системой (например, библиотеки для графического вывода, для работы с мультимедиа и т.п.); · интерпретатор команд
– программа, выполняющая ввод команд пользователя, их анализ и вызов других модулей для выполнения команд; · системный загрузчик
– программа, которая при запуске ОС (например, при включении питания) обеспечивает загрузку системы с диска, ее инициализацию и старт; · другие виды программ, в зависимости от конкретной системы. Не менее важным является определение ядра, основанное на различении режимов работы компьютера. Все современные процессоры поддерживают, как минимум, два режима: привилегированный
режим (он же режим ядра, kernelmode) и непривилегированный
(режим задачи, режим пользователя, usermode). Программы, работающие в режиме ядра, имеют полный, неограниченный доступ ко всем ресурсам компьютера: его командам, адресам, портам ввода/вывода и т.п. В режиме задачи возможности программы ограничены, она, в частности, не может выполнить некоторые специальные команды. Аппаратное разграничение возможностей является абсолютно необходимым условием реализации надежной защиты данных в многопользовательской системе. Отсюда вытекает и определение ядра как части ОС, работающей в режиме ядра. Все остальные программы, как системные утилиты, так и программы пользователей, работают в режиме пользователя и должны обращаться к ядру для выполнения многих системных действий. Следует сказать, что переходы из режима пользователя в режим ядра и обратно – это действия, требующие определенного времени, и слишком частое их выполнение может привести к заметному снижению скорости работы программ. В связи с этим определение того, какие функции должны поддерживаться ядром, а какие лучше выполнять в режиме пользователя – это непростая и важная задача, которую должны решить разработчики ОС. Особую роль в структуре системы играют драйверы устройств
. Эти программы, предназначенные для обслуживания конкретных периферийных устройств, несомненно, можно отнести к ядру системы: они почти всегда являются резидентными и работают в режиме ядра. Но в отличие от самого ядра, которое изменяется только при появлении новой версии ОС, набор используемых драйверов весьма мобилен и зависит от набора устройств, подключенных к данному компьютеру. В некоторых системах (например, в ранних версиях UNIX) для подключения нового драйвера требовалось перекомпилировать все ядро. В большинстве современных ОС драйверы подключаются к ядру в процессе загрузки системы, а иногда разрешается даже загрузка и выгрузка драйверов в ходе работы системы. В качестве программного интерфейса системы, т.е. средств для обращения прикладных программ к услугам ОС, используется документированный набор системных вызовов
или функций API
(AppliedProgrammingInterface). Между этими двумя терминами есть некоторая разница. Под системными вызовами понимаются функции, реализуемые непосредственно программами ядра системы. При их выполнении происходит переход из режима пользователя в режим ядра, а затем обратно. В отличие от этого, API-функции определяются как функции, описанные в документации ОС, независимо от того, выполняются ли они ядром или же системными библиотеками, работающими в режиме пользователя. В Windows часто несколько разных API-функций обращаются к одному и тому же недокументированному системному вызову, но имеют различные обрамляющие части, работающие в режиме пользователя. Там, где различие между двумя этими понятиями несущественно, можно использовать нейтральный термин «системные функции
». В следующих разделах курса будут рассматриваться основные функции ОС и способы их реализации. Изложение общих подходов будет дополняться примерами, относящимися главным образом к трем широко известным ОС: · MS-DOS – пример простой однозадачной системы; · Windows – сложная современная система, выросшая на базе MS-DOS; · UNIX – система, по возможностям сопоставимая с Windows, однако разительно отличающая по набору основных концепций и методам реализации. 1.7.1. MS-DOS Система MS-DOS была разработана в 1981 г. специально для только что появившейся первой 16-разрядной ПЭВМ IBMPC на базе процессора i86. Первая версия системы была ужасна, но работоспособна. В последующие годы фирме Microsoft удалось значительно улучшить свою систему, хотя некоторые пережитки первой версии оказались неистребимы. Альянс с фирмой IBM позволил Microsoft добиться фантастического финансового успеха. MS-DOS представляет собой однозадачную, однопользовательскую, диалоговую ОС. Она ведет диалог с пользователем в текстовом режиме и в большей степени рассчитана на обслуживание прикладных программ текстового режима, хотя допускает и графику. Работа с мышью должна обеспечиваться самими прикладными программами при минимальной поддержке со стороны ОС. Для размещения программы пользователя и для своих собственных нужд MS-DOS позволяет использовать 640 Кбайт памяти, что казалось огромной величиной в те незапамятные времена аккуратного программирования и полного отсутствия файлов AVI и MP3. Позднее были добавлены средства, позволяющие с некоторым усилием использовать до 4 Мб памяти. Интерфейс MS-DOS с прикладными программами основан на вызовах программных прерываний, обрабатываемых системой. Бóльшую часть этих прерываний принято называть функциями
DOS
. Система MS-DOS явилась стартовой площадкой для создания Windows. В настоящее время MS-DOS тихо отмирает, хотя все версии Windows стараются обеспечить выполнение большей части программ, разработанных для их предшественницы. В данном курсе MS-DOS рассматривается как наиболее жизненный пример простой и хорошо изученной однозадачной системы для сравнения с более мощными многозадачными системами. 1.7.2. Windows Система Windows была первоначально разработана фирмой Microsoft как графическая оболочка, загружаемая поверх MS-DOS. Идеи GUI (GraphicUserInterface – графический интерфейс пользователя) были впервые разработаны для экспериментальной машины XeroxPARC еще в 70-х гг., затем подхвачены в MacOS – операционной системе компьютера Macintosh, откуда и были с некоторыми ухудшениями позаимствованы в Windows. Версию Windows 1.0, вышедшую в 1985 г. и работавшую на 1 Мб памяти с неперекрывающимися окнами, принято рассматривать как интересную игрушку. Версия 2.0 (1987 г.) была более серьезна, а версии 3.0 и 3.1 (1990-1992 гг.), предназначенные для процессоров i386 и использующие до 16 Мб памяти, уже имели большой успех. Все перечисленные версии продолжали оставаться надстройками над MS-DOS, использующими имеющуюся файловую систему, но добавляющие свое собственное управление процессами, памятью и устройствами. За счет этого комбинацию DOS + Windows можно было назвать многозадачной однопользовательской ОС с графическим интерфейсом пользователя. В 1993 г. Microsoft выпустила WindowsNT – полноценную многозадачную и многопользовательскую ОС, уже не основанную на MS-DOS. Однако, поскольку NT предъявляла повышенные требования к мощности процессора и объему памяти, в 1995 г. была выпущена компромиссная система Windows 95, предназначавшаяся для замены Windows 3.x у массового пользователя. Повышение скорости работы по сравнению с версией NT было достигнуто ценой отказа от многопользовательской защиты и ослабления надежности системы. В Windows 95 неаккуратно написанная прикладная программа может привести к краху системы, а в WindowsNT система лучше изолирована от программ пользователя. В то же время, практически все корректно написанные программы могут переноситься из Windows 95 в WindowsNT и наоборот. Некоторое время две линии Windows развивались параллельно. Очередные версии WindowsNT получили название Windows 2000, WindowsXP, Windows 2003. Линия Windows 95 была продолжена непринципиально отличающимися от нее версиями Windows 98 и WindowsME, но дальше, видимо, развиваться не будет. Microsoft считает, что современный уровень производительности ПЭВМ снимает необходимость в облегченной версии системы. Windows предоставляет в распоряжение прикладных программ несколько тысяч документированных API-функций на все случаи жизни. Современная Windows– весьма мощная и чересчур сложная система, имеющая множество достоинств и недостатков, которые невозможно обсудить коротко. Отметим, что широкому распространению Windows, помимо особого положения фирмы Microsoft на рынке, способствует простота установки системы, позволяющая рядовому пользователю обойтись без помощи специалистов. В дальнейшем изложении описание возможностей Windows будет в основном ориентировано на линию Windows NT/2000/XP. 1.7.3. UNIX ОС UNIX была первоначально разработана в 1969 г. сотрудниками фирмы BellLaboratories Кеном Томпсоном и Деннисом Ритчи. В 1971 г. система была перенесена на машины чрезвычайно распространенной в 70-е годы серии PDP-11, а в 1973 г. Ритчи переписал систему на языке C, оставив лишь минимум текста на языке ассемблера. В первое десятилетие существования UNIX и сама система, и ее исходные тексты распространялись свободно, что привело к чрезвычайной популярности системы в научных кругах и университетах. Усовершенствования системы могли вноситься каждым желающим и обсуждались «всем миром». Оборотной стороной такой открытости стала трудность стандартизации UNIX. Однако в 1988-1990 гг. был разработан набор стандартов, получивший название POSIX (PortableOS, а окончание IX – как намек на UNIX). Эти стандарты фиксировали современные требования к системам типа UNIX с учетом теоретических и практических достижений за прошедшие годы. Начиная с первых версий, UNIX представляет собой многозадачную, многопользовательскую систему разделения времени. Основными достоинствами UNIX являются ее высокая мобильность, хорошо продуманный программный и пользовательский интерфейс. Общепризнанной особенностью UNIX является внутренняя красота, элегантность основных архитектурных решений. Как известно, красота программы является верным признаком ее удачной конструкции и дает основания надеяться, что программа способна к совершенствованию и будет служить долго. Многолетняя история UNIX подтверждает это правило. К недостаткам UNIX можно отнести более низкую эффективность и надежность работы, что в значительной мере является платой за мобильность. Традиционная модель безопасности UNIX не соответствует современным требованиям, поэтому в различные коммерческие версии приходится включать дополнительные средства защиты данных. Широкому распространению UNIX мешает также то, что процедуры установки и настройки системы не так просты, как у Windows, и при их выполнении желательно участие программиста. В 80-е годы были попытки превратить UNIX в коммерческую систему. Однако в 1991-1994 гг. Линус Торвальдс, в то время студент-программист из Хельсинки, заново написал систему, соответствующую стандартам POSIX, но отличающуюся от традиционной UNIX большей надежностью и эффективностью. Эта система получила название Linux. Исходные тексты Linux свободно распространяются, что позволяет, как во времена молодости UNIX, развивать систему общими усилиями огромного сообщества заинтересованных программистов. Эффективной координации этих усилий очень способствует Интернет. Несколько позднее был открыт свободный доступ к текстам известной версии UNIXFreeBSD. Архитектура UNIX, первоначально предназначенная для систем разделения времени с одним процессором, впоследствии оказалась вполне подходящей для поддержки сетевых систем. Значительная часть серверов Интернета работает под управлением той или иной версии UNIX. В настоящее время происходит ощутимое сближение разных типов ОС, предназначенных для поддержки одних и тех же типов вычислительных систем. Современные версии UNIX и Windows предоставляют весьма близкие функциональные возможности, хотя зачастую в совершенно разной форме. Выравниваются также характеристики надежности и производительности систем. Существенным отличием UNIX от Windows остается место, занимаемое в системе средствами графического интерфейса. Если в Windows окна и все, что с ними связано, являются неотъемлемой частью архитектуры системы, то для UNIX по традиции основным средством интерфейса с пользователем является текстовая консоль. Те или иные средства оконного интерфейса, конечно, присутствуют в современных UNIX-системах, но как дополнительная, необязательная надстройка скорее прикладного, чем системного характера. Очень интересной особенностью UNIX является развитый язык команд shell, который позволяет не только вести элементарный диалог с системой, но и писать своеобразные программы (скрипты), с помощью которых часто удается решить требуемую задачу, не прибегая к разработке новой программы на одном из традиционных языков программирования. Понятие периферийных устройств (ПУ) объединяет, по сути, все основные аппаратурные блоки компьютера, за исключением процессора и основной памяти. Характерными чертами современных вычислительных систем являются широкое разнообразие типов и моделей ПУ, а также быстрый прогресс технологий, приводящий к постоянному увеличению производительности устройств и к появлению дополнительных возможностей аппаратуры. Важнейшими задачами любой ОС являются обеспечение надежной работы ПУ, эффективное использование всех возможностей устройств. Для повышения надежности могут использоваться различные аппаратно-программные методы, такие как дублирование данных, использование помехозащищенных кодов, контрольных сумм данных и т.п. Процедуры выполнения операций с устройствами должны обеспечивать, как минимум, выявление аппаратных ошибок и сбоев, а как максимум – их компенсацию за счет избыточности данных и повторного выполнения операций. Эффективность использования устройств означает прежде всего сокращение времени, затрачиваемого на обмен данными. Помимо повышения скорости обмена, сокращение времени может достигаться за счет распараллеливания работы ПУ и процессора. Мощным фактором повышения производительности системы является сокращение количества операций ввода/вывода за счет сохранения данных в памяти для последующего использования. Большое разнообразие используемых устройств и постоянное появление новых моделей диктуют необходимость такой структуры системы, которая позволяла бы легкое подключение новых устройств. Широкое распространение получает технология «Plug & Play», т.е. возможность оперативного подсоединения устройств без выключения компьютера. При всем разнообразии ОС должна обеспечивать максимально возможную стандартизацию работы с ними, чтобы изменения аппаратуры не приводили к необходимости постоянно модифицировать прикладное программное обеспечение. К числу дополнительных задач, решаемых подсистемами управления устройствами современных ОС, можно отнести хранение данных в сжатом виде, шифрование данных и т.п. Под программной архитектурой
(или просто – архитектурой
) устройства мы будем понимать совокупность тех структурных особенностей, которые влияют на работу программ с устройством. Например, форма разъема для подключения устройства не входит в его архитектуру, но количество и назначение линий в этом разъеме может в нее входить (если эти линии могут программно управляться). Как правило, вместе с устройством поставляется его контроллер
(адаптер), содержащий электронные схемы управления устройством. Конструктивно контроллер может представлять собой плату, вставляемую в разъем шины компьютера, либо может быть расположен в корпусе устройства. В любом случае программы работают с устройством через посредство его контроллера, а поэтому с точки зрения архитектуры нет различия между понятиями «устройство» и «контроллер устройства». Классификация периферийных устройств может быть выполнена по различным признакам. · Устройства последовательного доступа
(sequentialaccess) и устройства произвольного доступа
(randomaccess). Для последовательных устройств характерно наличие определенного естественного порядка данных, при этом обработка данных в ином порядке либо невозможна, либо крайне затруднена. Классическим примером являются магнитные ленты, для которых чтение и запись данных ведутся от начала ленты к концу, а попытка доступа в ином порядке потребует постоянной перемотки ленты, резко снижающей скорость работы. К устройствам последовательного доступа можно отнести также клавиатуру, мышь, принтер, модем. Для устройств произвольного доступа возможно обращение к различным порциям данных в любом порядке, причем эффективность работы не зависит (или слабо зависит) от порядка обращения. Для таких устройств характерно наличие адресации данных и операции поиска нужного адреса. Наиболее известный пример – магнитные диски и другие дисковые устройства. Кроме того, к устройствам произвольного доступа можно отнести монитор ПК (там есть адресация точек-пикселов, хотя операция поиска не нужна). · Символьные (байтовые
) и блочные
устройства. Для символьных устройств наименьшей порцией вводимых и выводимых данных является один байт. Для некоторых символьных устройств можно за одну операцию выполнить ввод или вывод любого (в разумных пределах) требуемого количества байт. Для блочных устройств наименьшей порцией ввода/вывода, выполняемого за одно обращение к устройству, является один блок, равный, как правило, 2k
байт. Типичным размером блока может быть 512 байт, 1K байт, 4K байт и т.п., в зависимости от конкретного устройства. Наиболее известные примеры блочных устройств – магнитные диски и магнитные ленты. Для диска понятие блока обычно совпадает с понятием сектора. В частности, для IBM-совместимых ПК сектор (блок) диска равен 512 байт. Блочная архитектура обусловлена особенностями используемой среды и, кроме того, блочный ввод/вывод более эффективен для высокоскоростных устройств, поскольку при этом уменьшается относительная доля времени, расходуемая на подготовительные и заключительные операции при каждом обращении к устройству. · Физические
, логические
и виртуальные
устройства. Под физическим устройством обычно понимается некоторый реально существующий прибор, «железка». На самом деле, с точки зрения программной архитектуры для наличия физического устройства достаточно знать набор адресов, команд, прерываний и других сигналов, позволяющих выполнять операции с данными. Куда идут или откуда приходят эти сигналы – это вопрос, не касающийся программиста. Логическое устройство – это понятие, характеризующее специальное назначение устройства в данной ОС. Например, «загрузочный диск» (т.е. тот, с которого была выполнена загрузка ОС). Наиболее важными логическими устройствами во многих ОС являются устройство стандартного ввода
и устройство стандартного вывода
. Их можно упрощенно определить как устройства, используемые для ввода и, соответственно, вывода «по умолчанию», т.е. когда в программе явно не указано другое устройство или файл для ввода/вывода. Как правило, для современных компьютеров устройству стандартного ввода соответствует физическое устройство – клавиатура, а устройству стандартного вывода – монитор. Важно, однако, понимать, что это соответствие может быть изменено: стандартный вывод может быть переназначен, например, на принтер или в файл, стандартный ввод – на удаленный терминал, на файл и т.п. Понятие «виртуальный» в программировании, вообще говоря, означает примерно следующее: «нечто, на самом деле не существующее, но ведущее себя так, как если бы оно существовало». С этой точки зрения, виртуальное устройство – это программно реализованный объект, который ведет себя подобно некоторому физическому устройству, хотя на самом деле использует ресурсы совсем других устройств (или даже никаких устройств). Примеры виртуальных устройств весьма разнообразны: - виртуальные диски, расположенные на самом деле в оперативной памяти (такие устройства были популярны в конце 80-х годов); - виртуальная память, расположенная на самом деле на диске; - виртуальные CD и DVD – программы, имитирующие поведение соответствующих устройств; - виртуальный экран, предоставляемый DOS-программе, работающей в режиме окна Windows (программа работает так, как если бы ей был предоставлен весь экран, но на самом деле система направляет вывод программы в отведенное ей окно); - самый забавный (но очень полезный) пример – пустое устройство, которому не соответствует никакая аппаратура. Почему его вообще можно назвать устройством? Потому что соответствующая системная программа (драйвер пустого устройства) корректно выполняет все действия, которые обязан выполнять драйвер устройства. Такое устройство безотказно принимает выходной поток символов (и тут же выбрасывает принятые данные), а также может использоваться для ввода, но при этом тут же сообщает – дескать, достигнут конец файла. Пустое устройство полезно в тех случаях, когда некоторая программа требует непременно указать файл или устройство для вывода объемных и не очень нужных данных. Кроме того, копирование файла на пустое устройство – это простой способ убедиться, что файл читается без ошибок. Прерывания (аппаратные) – это сигналы, при поступлении которых нормальная последовательность выполнения программы может быть прервана, при этом система запоминает информацию, необходимую для возобновления работы прерванной программы, и передает управление подпрограмме обработки прерывания
(ISR, InterruptServiceRoutine). По завершению обработки, как правило, управление возвращается прерванной программе. Все прерывания можно разделить на три основных типа: · аппаратные прерывания от периферийных устройств; · внутренние аппаратные прерывания (называемые также исключениями
, exceptions); · программные прерывания. В подавляющем большинстве ОС обработку всех прерываний берет на себя сама система, поскольку это слишком «интимная» часть работы, способная повлиять на функционирование всех системных и прикладных программ. Поскольку типы и разновидности прерываний весьма многообразны и каждый из них требует особой обработки, большинство процессоров поддерживает векторные прерывания
. Это означает, что каждая разновидность прерывания имеет свой номер, и этот номер используется как индекс в массиве, хранящем адреса ISR для всех прерываний. При возникновении прерывания аппаратура компьютера по номеру прерывания определяет адрес подпрограммы обработки и вызывает ее. Для того чтобы некоторые наиболее ответственные участки системных программ выполнялись без прерываний, система имеет возможность временно запретить прием большинства прерываний. Такой запрет должен устанавливаться лишь на короткие интервалы времени, не более нескольких миллисекунд. Программные прерывания вызываются выполнением специальной команды, но обрабатываются точно так же, как остальные типы прерываний. По сути, команда программного прерывания представляет собой особый случай вызова подпрограммы, но при этом вместо адреса подпрограммы указывается номер прерывания, обработчик которого должен быть вызван. В большинстве современных ОС программные прерывания используются для перехода из режима пользователя в режим ядра при вызове системных функций из прикладной программы. Одним из важнейших источников прерываний являются периферийные устройства. Как правило, устройство генерирует сигнал прерывания в одном из двух случаев: · при переходе в состояние готовности; · при возникновении ошибки выполнения операции. Состояние готовности – это такое состояние устройства, в котором оно готово принять и выполнить команды от процессора. Для устройства ввода готовность означает наличие в устройстве данных, которые могут быть переданы в процессор (например, клавиатура переходит в состояние «Готово» при нажатии клавиши и возвращается в состояние «Не готово», когда код нажатой клавиши считан в процессор). Для устройства вывода готовность – это возможность принять от процессора данные, которые следует вывести. Например, матричный принтер принимает символы, которые нужно напечатать, в свой внутренний буфер. Если буфер полон, принтер переходит в состояние «Не готово» до тех пор, пока часть символов будет напечатана и в буфере освободится место. Дисковый накопитель при начале выполнения новой операции чтения или записи на диск переходит в состояние «Не готово», а после завершения операции возвращается в состояние «Готово». В любом из этих случаев переход в состояние «Готово» – это повод для устройства напомнить о себе процессору: обратите на меня внимание, я к вашим услугам! Для этого и служит сигнал прерывания. Ошибка операции также требует вмешательства системы или пользователя. Например, при ошибке отсутствия бумаги в лотке принтера система должна оповестить об этом пользователя; при ошибке чтения с диска либо система, либо пользователь должен решить, что делать: повторить операцию, завершить программу или продолжить выполнение. Не каждое устройство генерирует прерывания. Например, монитор ПК не выдает прерываний: он «всегда готов», т.е. всегда может принять данные для отображения, и он «никогда не ошибается», точнее сказать, его неисправность обнаруживается «на глаз». С программной точки зрения, устройство (или его контроллер) обычно представлено одним или несколькими регистрами
. Регистр устройства – это адресуемое машинное слово, используемое для обмена данными или сигналами между устройством и процессором. Можно выделить два основных типа регистров. · Регистр данных
служит для обмена данными. Запись данных в такой регистр (если она возможна) означает вывод данных на устройство, чтение данных из регистра – ввод с устройства. · Регистр управления и состояния
содержит два типа двоичных разрядов (битов). Биты состояния служат для передачи процессору информации о текущем состоянии устройства (например, флагов готовности и ошибки, сигналов прерывания). Биты управления служат для передачи на устройство команд, позволяющих задать выполняемую операцию, запустить выполнение операции, установить режимы работы устройства и т.п. В различных компьютерах используется один из двух способов адресации регистров устройств. · Отображение регистров устройств на память. При этом способе для устройств отводится определенная часть адресного пространства памяти, а для работы с устройствами можно использовать те же команды, что и для работы с основной памятью (например, команду MOV). · Адресация регистров через порты ввода/вывода. Для портов отводится отдельное адресное пространство, и для работы с ними имеются специальные команды (например, IN и OUT). Первый способ удобнее для программирования, поскольку позволяет использовать более широкий набор команд. Однако этот способ труднее реализовать на аппаратном уровне, поскольку аппаратура должна определять, относится ли конкретный адрес к памяти или к устройству, и по-разному обрабатывать эти два случая. Среди различных возможных конфигураций однопроцессорной вычислительной системы принято выделять два основных типа: системы с магистральной и с радиальной архитектурой (рис. 2‑1). Рис.
2‑1 · Магистральная
архитектура основана на подключении всех имеющихся устройств, включая процессор и память, к единой системной магистрали (шине), которая объединяет в себе линии передачи данных, адресов и управляющих сигналов. Совместное использование магистрали различными устройствами подчиняется специальным правилам (протоколу), обеспечивающему корректность работы магистрали. · Радиальная
архитектура предполагает, что каждое из устройств, включая память, подключается к процессору отдельно, независимо от других устройств, и взаимодействует с процессором по собственным правилам. Для программиста понятия магистральной и радиальной архитектуры имеют несколько иное содержание, чем для инженера-системотехника. С точки зрения программной архитектуры, неважно, подсоединено ли устройство к процессору напрямую или через посредство системной магистрали. Важно то, какие сигналы должна посылать и принимать программа, работающая с устройством, и какие команды могут для этого использоваться. Основная особенность магистральной архитектуры – единообразный способ подключения всех устройств. Структура регистров устройства стандартизуется, при этом определяется, какими сигналами любое устройство может обмениваться с процессором и каким разрядам регистра должны соответствовать эти сигналы. Конечно, не всякое устройство нуждается в использовании всего набора стандартных сигналов. Некоторые типы устройств могут, например, не генерировать прерываний, не сообщать об ошибках. Но те сигналы, которые устройство использует, должны соответствовать стандарту данной магистрали. Преимуществом магистральной архитектуры является простота подключения новых типов устройств, поэтому такая архитектура особенно удобна для открытых вычислительных систем, т.е. таких, которые рассчитаны на расширяемый набор периферийных устройств. Напротив, для радиальной архитектуры характерен индивидуальный выбор способа подключения, наиболее удобного для каждого типа устройств. При этом в принципе можно достичь экономии аппаратных ресурсов и более высокой эффективности. Случается даже, что в одном порту объединяются управляющие сигналы от нескольких разных устройств. Очевидно, подобная архитектура удобна только в том случае, когда она рассчитана на постоянный набор устройств. Расширение радиальной системы всегда вызывает затруднения. Исходя их этих определений, не так уж легко точно охарактеризовать современные IBM-совместимые ПК. Исходная модель IBMPC имела довольно четко выраженную радиальную архитектуру и небольшой набор стандартных устройств. В последующих моделях были сделаны значительные шаги по стандартизации подключения новых устройств. Однако и сегодня эти компьютеры не тянут на магистральную архитектуру в полном смысле слова: у них для этого слишком много разных шин. Важной деталью архитектуры современных компьютеров является такое устройство, как контроллер прямого доступа к памяти
(ПДП, англ. DMA – Direct Memory Access). Если обычно весь обмен данными идет через регистры процессора, то ПДП подразумевает прямой перенос данных с устройства в память или обратно. Роль процессора в данном случае только в том, чтобы инициировать операцию ввода/вывода блока данных, послав соответствующие команды контроллеру ПДП. Далее процессор не участвует в выполнении обмена данными. Завершив операцию, контроллер ПДП посылает сигнал прерывания, извещая об этом процессор. Это позволяет повысить производительность системы за счет частичной разгрузки процессора и магистрали. 2.5.1. Ввод/вывод по опросу и по прерываниям
Рассмотрим более подробно работу программы, непосредственно выполняющей ввод или вывод данных на конкретное устройство. (На самом деле, этой работой обычно занимается драйвер устройства, так что мы фактически рассматриваем логику работы драйвера.) Для определенности положим, что программа должна выдать N байт данных из массива A на символьное устройство X. Для операции ввода могут использоваться те же подходы, которые будут рассмотрены здесь для операции вывода. Пусть архитектура устройства представлена регистром данных X.DATA и флагом готовности X.READY. Когда X.READY = TRUE, в регистр X.DATA можно выдавать очередной байт данных. Запишем на псевдокоде, близком к языку Паскаль, варианты организации соответствующей программы. а) Ввод/вывод без проверки готовности i := 1; while i <= N do begin X.DATA := A[i]; i := i + 1; end; Этот «наглый» способ вывода вполне работоспособен, если используется «всегда готовое» устройство (например, монитор), т.е. флаг X.READY всегда истинен и потому вообще не нужен. При попытке использовать тот же подход для вывода на принтер мы убедились бы, что напечатаны будут лишь некоторые символы, которым посчастливилось быть выданными в редкие моменты готовности принтера. б) Ввод/вывод по опросу готовности i := 1; while i <= N do begin while not X.READY do ; X.DATA := A[i]; i := i + 1; end; Здесь добавлен цикл ожидания, в котором не делается ничего, кроме постоянной циклической проверки готовности устройства. Передача данных происходит только тогда, когда устройство готово. Поскольку после выдачи одного байта устройство вполне может опять перейти в состояние неготовности, следует опять выполнять цикл ожидания, пока выданный символ не будет обработан устройством. Такая организация ввода/вывода позволяет корректно работать с любыми устройствами. Этот способ действительно применяется в некоторых однозадачных системах. Недостатком данного способа является непроизводительная трата времени на постоянное «долбление» флага готовности. При современном соотношении скоростей работы процессора и периферии, цикл ожидания может повторяться миллионы раз перед выдачей каждого байта. Более того, если по каким-то причинам устройство вообще не перейдет в состояние готовности, то работа всей системы может быть парализована бесконечным циклом ожидания. в) Ввод/вывод по прерываниям i := 1; while i <= N do begin X_INT: if not X.READY return; X.DATA := A[i]; i := i + 1; end; Здесь исчез цикл ожидания, вместо него – однократная проверка готовности и оператор возврата, если не готово. Куда, собственно, происходит возврат? Чтобы это понять, надо вспомнить, что данный фрагмент – явно не единственная программа, работающая в данный момент на ЭВМ. Очевидно, операция вывода была начата операционной системой по запросу какой-то программы. Данный фрагмент был вызван как подпрограмма ОС, и возврат означает передачу управления ОС. Как система распорядится полученным временем? Это уже совсем другой вопрос, не связанный с вводом/выводом. Например, ОС может переключиться на другой процесс. Или, от нечего делать, запустить экранную заставку либо программу самотестирования. Но как же быть с брошенной на полпути операцией вывода? Для ее возобновления будет использовано аппаратное прерывание, которое должно выдать устройство X при переходе в состояние готовности. Системный обработчик прерывания должен будет передать управление по адресу, обозначенному меткой X_INT. После нелишней дополнительной проверки готовности программа вывода передаст очередной байт на устройство, затем снова проверит готовность и, возможно, вновь вернет управление системе. Таким образом, выполнение ввода/вывода разбивается на отдельные интервалы работы при готовности устройства, перемежающиеся работой системы, пока устройство не готово. Для устройств, использующих контроллер ПДП, возможные варианты организации работы остаются, по сути, теми же, но только используются гораздо более крупные операции: вместо ввода или вывода одного элемента данных выполняется ввод/вывод целого блока данных, и только после этого контроллер переходит в состояние готовности и генерирует прерывание. 2.5.2. Активное и пассивное ожидание
Поговорим подробнее об одном важном различии между способами ввода/вывода по опросу готовности и по прерываниям. Основной особенностью ввода/вывода по опросу готовности является цикл ожидания. Если выполняется ввод или вывод на медленное устройство (например, матричный принтер), то этот скромно выглядящий цикл будет занимать, мягко говоря, 99% всего времени работы процессора. Если происходит ожидание ввода с клавиатуры, то процессор вообще не будет делать ничего полезного, пока пользователь не удосужится нажать клавишу. Такое абсурдное использование процессора может быть оправдано разве что в том случае, если для него нет никакой более полезной работы. Это возможно в случае однозадачной ОС, когда работающая прикладная программа не может продвигаться дальше, пока не завершена операция ввода/вывода. В этом случае ввод/вывод по опросу не лишен определенных достоинств: он не связан с обработкой прерываний, которая требует некоторого времени, а потому замедляет реакцию на переход устройства в состояние готовности. Способ ожидания программой некоторого события, основанный на постоянной циклической проверке ожидаемого условия, называется активным ожиданием
(busywaiting). Это понятие применяется не только по отношению к вводу/выводу, но и во многих других ситуациях, возникающих при работе системных и прикладных программ. Если рассматривается многозадачная ОС, в которой может быть несколько активных задач одновременно, то активное ожидание становится совершенно неприемлемым. В этом случае расход процессорного времени на выполнение циклического опроса наносит прямой ущерб другим программам, которые могли бы использовать это время более осмысленно. Поэтому при разработке многозадачных систем, как при вводе/выводе, так и в некоторых других ситуациях, обязательно реализуется пассивное ожидание
, т.е. такая реализация ожидания, при которой ожидающая программа не затрачивает процессорного времени. Для реализации пассивного ожидания всегда в той или иной форме используются аппаратные прерывания. Частным примером пассивного ожидания является рассмотренный выше ввод/вывод по прерываниям. 2.5.3. Синхронный и асинхронный ввод/вывод Программист, разрабатывающий прикладные программы, не должен думать о таких вещах, как способ работы системных программ с регистрами устройств. Система скрывает от приложений детали низкоуровневой работы с устройствами. Однако различие между организацией ввода/вывода по опросу и по прерываниям находит определенное отражение и на уровне системных функций, в виде функций для синхронного и асинхронного ввода/вывода. Выполнение функции синхронного ввода/вывода
включает в себя запуск операции ввода/вывода и ожидание завершения этой операции. Только после завершения ввода/вывода функция возвращает управление вызвавшей программе. Синхронный ввод/вывод – это наиболее привычный для программистов способ работы с устройствами. Стандартные процедуры ввода/вывода языков программирования работают именно таким способом. Вызов функции асинхронного ввода/вывода
означает только запуск соответствующей операции. После этого функция сразу возвращает управление вызвавшей программе, не дожидаясь завершения операции. Рассмотрим, например, асинхронный ввод данных. Понятно, что программа не может обращаться к данным, пока нет уверенности, что их ввод завершен. Но вполне возможно, что программа может пока что заняться другой работой, а не простаивать в ожидании. Рано или поздно программа все-таки должна приступить к работе с введенными данными, но предварительно убедиться, что асинхронная операция уже завершилась. Для этого различные ОС предоставляют средства, которые можно разбить на три группы. · Ожидание завершения операции. Это как бы «вторая половина синхронной операции». Программа сначала запустила операцию, потом выполнила какие-то посторонние действия, а теперь ждет окончания операции, как при синхронном вводе/выводе. · Проверка завершения операции. При этом программа не ожидает, а только проверяет состояние асинхронной операции. Если ввод/вывод еще не завершен, то программа имеет возможность еще какое-то время погулять. · Назначение процедуры завершения. В этом случае, запуская асинхронную операцию, программа пользователя указывает системе адрес пользовательской процедуры или функции, которая должна быть вызвана системой после завершения операции. Сама программа может больше не интересоваться ходом ввода/вывода, система напомнит ей об этом в нужный момент, вызвав указанную функцию. Этот способ наиболее гибкий, поскольку в процедуре завершения пользователь может предусмотреть любые действия. В Windows прикладной программе доступны все три способа завершения асинхронных операций. В UNIX асинхронных функций ввода/вывода нет, однако тот же эффект асинхронности может быть достигнут иначе, путем запуска дополнительного процесса. Асинхронное выполнение ввода/вывода позволяет в некоторых случаях повысить производительность работы и обеспечить дополнительные функциональные возможности. Без такой простейшей формы асинхронного ввода, как «ввод с клавиатуры без ожидания», были бы невозможны многочисленные компьютерные игры и тренажеры. В то же время логика программы, использующей асинхронные операции, сложнее, чем при синхронных операциях. А в чем заключается упомянутая выше связь между синхронными/асинхронными операциями и способами организации ввода/вывода, рассмотренными в предыдущем пункте? Ответьте сами на этот вопрос. 2.6.1. Понятие буферизации Буферизацию
в самом широком смысле можно определить как такую организацию ввода/вывода, при которой данные не передаются непосредственно с устройства в заданную область памяти (или из области памяти на устройство), а предварительно направляются во вспомогательную область памяти, называемую буфером
. Как правило, организуемые системой буферы невидимы для прикладного программиста, он получает данные как готовый результат. Нередко данные «по дороге» проходят через несколько буферов разного назначения. Существует несколько причин для использования буферизации, важнейшие из которых рассмотрены ниже. 2.6.2. Сглаживание неравномерности скоростей процессов Достаточно часто в работе ОС встречается ситуация, когда один процесс порождает данные, которые должны оперативно обрабатываться другим процессом. В качестве примера можно привести прием по сети данных, которые должны обрабатываться браузером или другой прикладной программой. Скорость приема данных очень неравномерна: интервалы времени интенсивного поступления данных перемежаются с интервалами простоя. Обработка данных прикладной программой тоже не обязательно идет с постоянной скоростью. В результате, хотя средняя скорость обработки может быть вполне достаточной, не исключено, что в некоторые моменты обрабатывающая программа будет «захлебываться» данными. Это может привести к потере части данных, не успевших пройти обработку. Стандартным решением в этой ситуации является использование буфера, размер которого достаточно велик, чтобы вместить все данные, ожидающие обработки. Чем больше буфер, тем меньше вероятность потери данных из-за его переполнения. 2.6.3. Распараллеливание ввода и обработки Во многих вычислительных системах имеются аппаратные возможности совместить во времени выполнение операций ввода/вывода и обработку данных процессором. Чтобы использовать эти возможности, данные при вводе направляются в буфер. После заполнения буфера его данные пересылаются в обрабатывающую программу, а их обработка выполняется параллельно с накоплением следующей порции данных в буфере. Еще более эффективна схема работы с двумя переключаемыми буферами. Пока в первом буфере накапливаются вводимые данные, предыдущая порция данных обрабатывается во втором буфере, без потери времени на пересылку. Затем буфера меняются ролями: в первом буфере обрабатывается следующая введенная порция данных, а второй буфер используется для ввода, и т.д. Аналогичным образом буферизация может использоваться и при выводе данных. В некоторых случаях оказывается выгодно выполнять ввод «с опережением», т.е. вводить те данные, которые пока не запрошены обрабатывающим процессом, но по всей вероятности скоро понадобятся. 2.6.4. Согласование размеров логической и физической записи Логической записью называют порцию данных, указанную в операторе ввода/вывода. Размер логической записи определяется логикой работы программы или, например, логической структурой базы данных. При фактическом выполнении чтения или записи на блочное устройство обрабатывается порция данных, называемая физической записью или блоком. Размер физической записи определяется особенностями устройства (для диска это один сектор) и никак не связан с логикой программы. На рис. 2‑2 показана ситуация, когда логическая запись содержит 100 байт, а физическая – 512 байт. Рис.
2‑2 Предположим, что логические записи в последовательном порядке записываются в файл на диске. Если каждый оператор вывода логической записи будет вызывать немедленную запись на диск, то выдача первых пяти логических записей потребует пять раз выполнить последовательность операций: «чтение физической записи с диска – изменение 100 байт – запись измененной записи на диск». На шестой раз получится еще хуже, поскольку придется читать – изменять – записывать не одну, а две физических записи. Использование буфера для накопления данных до размера физической записи позволяет резко сократить количество операций записи на диск и почти полностью исключить чтение с диска. 2.6.5. Редактирование при интерактивном вводе Несколько особняком от других форм буферизации стоит использование буфера строки при вводе с клавиатуры. Для пользователя привычно, что в процессе ввода числовых или строковых значений он может легко откорректировать ошибки ввода: «забить» неверный символ, вернуться в любое место вводимой строки и внести там изменения и т.п. При этом прикладная программа «не видит» процесса редактирования строки, она получает всю строку целиком после нажатия, например, клавиши Enter. Чтобы обеспечить возможность редактирования вводимой строки, используется буфер строки, выделяемый либо ОС, либо библиотекой времени выполнения конкретной системы программирования. Все редактирование выполняется над символами, которые помещаются в этот буфер подпрограммами ввода с клавиатуры. После нажатия Enter происходит либо копирование символов из буфера в массив, выделенный прикладной программой, либо передача этой программе указателя на буфер. Очень важной, специфической формой буферизации является кэширование[2]
. Этот термин означает использование сравнительно небольшой по объему, но быстродействующей памяти для того, чтобы уменьшить количество обращений к более медленной памяти большого объема. Идея кэширования основывается на так называемой гипотезе о локальности ссылок
. Эта гипотеза заключается в следующем. Если в какой-то момент времени произошло обращение к определенному участку данных, то в ближайшее время можно с высокой вероятностью ожидать повторения обращений к тем же самым данным или же к соседним участкам данных. Конечно, локальность ссылок нельзя считать законом, однако практика показывает, что эта гипотеза оправдывается для подавляющего большинства программ. В современных вычислительных системах может использоваться несколько уровней кэширования. В данном курсе не рассматривается аппаратный кэш процессора, позволяющий сократить число обращений к основной памяти за счет использования быстродействующих регистров. К работе ОС более прямое отношение имеет программное кэширование устройств произвольного доступа (дисковых накопителей). В этом случае гипотезу о локальности ссылок можно переформулировать более конкретно: если программа выполнила чтение или запись данных из некоторого блока диска, то весьма вероятно, что в скором будущем последуют еще операции чтения или записи данных из того же блока. В роли быстродействующей памяти (кэша) здесь выступает массив буферов, размещенный в системной памяти. Каждый буфер состоит из заголовка и блока данных, соответствующего по размеру блоку (сектору) диска. Заголовок буфера содержит адрес блока диска, копия которого в данный момент содержится в буфере, и несколько флагов, характеризующих состояние буфера. Когда система получает запрос на чтение или запись определенного блока данных диска, она прежде всего проверяет, не содержится ли в данный момент копия этого блока в одном из буферов кэша. Для этого требуется выполнить поиск по заголовкам буферов. Если блок найден в кэше, то обращение к диску выполняться не будет. Вместо этого данные читаются из буфера или, соответственно, записываются в буфер. В случае записи данных следует также в заголовке буфера отметить с помощью специального флага, что буфер стал «грязным
», т.е. его содержимое не соответствует данным на диске. Если требуемый блок диска не найден в кэше, то для него должен быть выделен буфер. Проблема в том, что общее количество буферов кэша ограничено. Чтобы отдать один из них под требуемый блок, надо «вытеснить» из кэша один из блоков, которые там хранились. При этом, если вытесняемый блок «грязный», то он должен быть «очищен», т.е. записан на диск. При вытеснении «чистого» блока никаких операций с диском выполнять не надо. Какой из блоков, хранящихся в кэше, следует выбрать для вытеснения, чтобы сократить общее количество обращений к диску? Это крайне важный вопрос, и если он будет решаться неправильно, то вся работа системы может затормозиться из-за постоянных обращений к диску. Имеется теоретически оптимальное решение данной задачи, которое заключается в следующем. Число обращений к диску будет минимально, если каждый раз выбирать для вытеснения тот блок данных, к которому в будущем дольше всего не будет обращений. К сожалению, воспользоваться этим правилом на практике невозможно, так как последовательность обращений к блокам диска непредсказуема. Данный теоретический результат полезен только как недостижимый идеал, с которым можно сравнивать результаты применения более реалистичных алгоритмов выбора. Среди алгоритмов, используемых на практике, лучшим считается алгоритм LRU
(LeastRecentlyUsed, в вольном переводе «давно не использовавшийся»). Он заключается в следующем: выбирать для вытеснения следует тот блок, к которому дольше всего не было обращений. Здесь как раз используется принцип локальности ссылок: раз обращений давно не было, то, вероятно, их и не будет в ближайшее время. Как на практике реализуется выбор блока по правилу LRU? Очевидное решение – при каждом обращении к буферу записывать в его заголовке текущее время, а при выборе для вытеснения искать самую раннюю запись – слишком громоздко и медленно. Есть гораздо лучшая возможность. Все буферы кэша связываются в линейный список. В заголовке каждого буфера хранится ссылка на следующий по порядку списка буфер (фактически хранится индекс этого буфера в массиве буферов). При каждом обращении к блоку данных для чтения или записи выполняется также перемещение соответствующего буфера в конец списка. Это не означает перемещения данных, хранящихся в буфере, изменяются только несколько ссылок в заголовках. В результате постоянного перемещения использованных блоков в конец списка буферов этот список оказывается отсортированным по возрастанию времени последнего обращения. В начале списка оказывается тот буфер, к данным которого дольше всего не было обращений. Он-то нам и нужен как кандидат на вытеснение. На рис. 2‑3 показан массив буферов, связанный в список. Рис.
2‑3 Теперь о «грязных» буферах. В каких случаях должна выполняться их «очистка», т.е. запись блока данных из кэш-буфера на диск? Можно назвать три таких случая. · Выбор блока для вытеснения из кэша. · Закрытие файла, к которому относятся «грязные» блоки. Общепринято, что при закрытии файла должно выполняться его сохранение на диске. · Операция принудительной очистки всех буферов либо только буферов, относящихся к определенному файлу. Подобная операция может выполняться для повышения надежности хранения данных, как страховка от возможных сбоев. В ОС UNIX, например, очистка всех буферов традиционно выполняется каждые 30 с. Следует признать, что кэширование операций записи на диск, в отличие от кэширования чтения, всегда создает определенную опасность потери данных. В случае случайного сбоя системы, отключения питания и т.п. может оказаться, что важная информация, которую следовало записать на диск, застряла в грязных буферах кэша и была поэтому потеряна.[3]
Это неизбежная плата за значительное повышение производительности системы. Программы, требующие высокой надежности работы с данными (например, банковские программы), обычно записывают данные прямо на диск. При этом кэш либо не используется вообще, либо в кэш-буфер заносится копия данных, которая может пригодиться при последующих операциях чтения. «Узким местом» кэширования дисков является поиск требуемого блока данных в кэше. Как было описано выше, для этого система просматривает заголовки буферов. Если кэш состоит из нескольких сотен буферов, время поиска будет ощутимо. Один из возможных приемов ускорения поиска, используемый в UNIX, показан на рис. 2‑4. Рис.
2‑4 В UNIX каждый кэш-буфер может входить одновременно в два линейных списка. Один из них, называемый «списком свободных блоков», это знакомый нам LRU-список, используемый для определения блока, подлежащего вытеснению. Слово «свободный» не значит «пустой»; в данном случае это слово означает блок, не занятый в текущий момент в операции чтения/записи, выполняемой каким-нибудь процессом. Другой список называется «хеш-цепочкой» и используется для ускорения поиска нужного блока. При записи в буфер данных, соответствующих некоторому блоку диска, номер хеш-цепочки, в которую будет помещен этот буфер, определяется как остаток от деления номера блока на N – количество хеш-цепочек. Для наглядности на рисунке принято значение N = 10. Таким образом, блоки с номерами 120, 40, 90 попадают в цепочку 0, блоки 91, 1, 71 – в цепочку 1 и т.д. Когда система ищет в кэше блок с определенным номером, она прежде всего по номеру блока определяет, в какой из хеш-цепочек этот блок должен находиться. Если блока нет в этой цепочке, то его вообще нет в кэше. Таким способом удается сократить поиск в лучшем случае в N раз (это если все цепочки окажутся одинаковой длины). Перемещение буфера из одной хеш-цепочки в другую, как и его перемещение в конец списка свободных блоков, не требует перезаписи всего блока данных в памяти и выполняется путем изменения ссылок в заголовках блоков. Еще одна особенность кэширования дисков в UNIX состоит в том, что при обнаружении в начале списка свободных блоков «грязных» буферов система запускает процессы их очистки, но не дожидается завершения этих процессов, а выбирает для вытеснения первый по списку чистый блок. После завершения очистки блоки возвращаются в начало списка свободных блоков, оставаясь первыми кандидатами на вытеснение. В том случае, если обработка данных ведется последовательным образом (от начала файла к концу), кэширование не дает значительного эффекта. После того, как обработаны данные из одного блока, дальнейшее пребывание этого блока в кэш-буфере бесполезно. Значительно более полезной в этом случае может оказаться другая специальная форма буферизации, известная как опережающее чтение
. Она заключается в том, что при обращении к некоторому блоку диска система, выполнив чтение требуемого блока, считывает затем еще несколько следующих за ним блоков. Если аппаратура позволяет выполнять операцию чтения одновременно с обработкой ранее прочитанных данных, то велика вероятность, что к моменту, когда следующий блок данных будет запрошен для обработки, этот блок уже окажется прочитанным. Как правило, системе неизвестно, будет ли обработка файла вестись в режиме последовательного или произвольного доступа, поэтому часто используется та или иная комбинация кэширования с опережающим чтением. В Windows программа, открывающая файл, может указать системе, для какого способа доступа желательно оптимизировать механизм буферизации. Идея опережающего чтения получила интересное развитие в WindowsXP. В этой системе введен механизм опережающей загрузки данных (prefetch), который основан на автоматическом сборе и хранении статистики о том, какие файлы и каталоги используются в ходе загрузки ОС и при запуске конкретных приложений, а также какие данные читаются из этих файлов в первые минуты работы. При последующих загрузках ОС и запусках приложений система выполняет ожидаемые операции чтения еще до того, как они будут в действительности запрошены загружаемыми компонентами ОС или приложением. При этом система планирует порядок операций таким образом, чтобы сократить перемещения читающих головок и тем самым ускорить загрузку данных. Драйвер устройства
– это системная программа, которая под управлением ОС выполняет все операции с конкретным периферийным устройством. Драйвер является как бы посредником между ОС и устройством. Перед драйверами стоят две одинаково важные, но трудно совместимые задачи: · обеспечить возможность стандартного обращения к любому устройству, скрывая от остальных частей ОС специфические особенности отдельных устройств; · добиться максимально эффективного использования всех функциональных возможностей и особенностей конкретных устройств. Возможность стандартными средствами работать с разными устройствами очень желательна с точки зрения архитектуры ОС и удобства программирования. Было бы крайне противно, если бы при написании прикладной программы нужно было заранее учитывать, какая модель принтера будет использоваться для выдачи результатов. Наоборот, в большинстве случаев прикладной программист даже не должен знать, будет ли это принтер или плоттер-графопостроитель, или же результаты будут отображаться на экране. Большие проблемы могли бы возникнуть и при замене одной модели принтера, диска, монитора на другую, если бы такая замена потребовала переписывать заново все программы, работающие с этим устройством. Другое дело, если все особенности устройства учитываются в одном-единственном месте, а именно – в драйвере этого устройства. Разумеется, полностью скрыть все различия между устройствами невозможно. Никаким образом нельзя приравнять, скажем, диск к клавиатуре, и даже разные типы дисков похожи, но не совсем. Например, для дискет можно выполнить такую операцию, как проверка смены носителя (фактически при этом проверяется, открывался ли карман дисковода). Для жестких дисков эта операция не имеет смысла. В большинстве ОС различаются, как минимум, два разных типа драйверов: для символьных и для блочных устройств. Обращаясь к драйверу, ОС указывает функцию, которую требуется выполнить. Список этих функций общий для драйверов различных устройств, при этом каждый драйвер может реализовать только те функции, которые имеют смысл для данного устройства. Наиболее общими являются функции чтения данных, записи данных, инициализации устройства (эта функция вызывается системой один раз, сразу после загрузки), открытия и закрытия устройства (используются, когда символьное устройство открывается как файл). Для блочных устройств имеют смысл функции форматирования, поиска сектора. Для символьных устройств ввода – функция «неразрушающего ввода», т.е. проверки очередного символа без его изъятия из входного потока. Для того, чтобы учесть все разнообразие возможных операций, в число функций драйвера вводят такую, как «выполнение специальных функций», и здесь уже для каждого устройства определен свой набор этих специальных функций. Типичный драйвер устройства содержит, как минимум, три основных блока: · заголовок драйвера; · блок стратегии; · блок прерываний. Заголовок
содержит различную информацию о данном драйвере и об управляемом устройстве. Сюда может включаться имя устройства, тип устройства, число однотипных устройств, обслуживаемых одним драйвером, объем памяти на устройстве и т.п. Заголовок содержит также адреса блока стратегии и блока прерываний. В обязанность блока стратегии
входит прием заявок на выполнение операции, ведение очереди заявок (в многозадачных системах, а также при асинхронных операциях, выполнения могут дожидаться несколько заявок), а также запуск операции и ее завершение. Заявка на выполнение операции представляет собой стандартную запись, формируемую системой перед обращением к драйверу. Заявка содержит код требуемой функции драйвера и сведения об адресе данных в памяти и на устройстве, о количестве передаваемых данных. Заявка также содержит поле, в которое драйвер должен будет записать код завершения операции (обычно 0 – нормально выполненная операция, другие значения – коды ошибок). Блок прерываний
выполняет примерно тот алгоритм, который в п. 2.5.1 назывался вводом/выводом по прерываниям. Система вызывает этот блок, когда получает сигнал прерывания от устройства, обслуживаемого драйвером. Закончив выполнение заявки, блок прерываний возвращает управление блоку стратегии для завершения операции. Помимо трех основных блоков, в разных ОС драйверы могут содержать, например, блок инициализации (он используется один раз при загрузке ОС, а затем может быть выгружен из памяти), блок изменения параметров драйвера и др. В последние годы возрастающее усложнение периферийных устройств и самих ОС сделало популярной многоуровневую схему использования драйверов. По этой схеме, помимо описанных выше низкоуровневых драйверов аппаратуры, допускается еще создание высокоуровневых драйверов, лежащих между драйверами аппаратуры и остальной частью ОС. Высокоуровневый драйвер не содержит блока прерываний, он принимает заявки от системы, преобразует данные тем или иным образом, а затем вызывает низкоуровневый драйвер для работы с устройством. Например, высокоуровневый графический драйвер может преобразовывать команды рисования фигур, заливок, текста в набор команд конкретной модели принтера, а связанный с ним драйвер параллельного порта отвечает за передачу этих команд принтеру. Для диска можно реализовать в виде отдельного драйвера алгоритм шифрации данных, которые потом передаются обычному драйверу диска. 2.8.1. Уровни доступа к устройствам Система MS-DOS предоставляет пользователю возможности доступа к устройствам на нескольких уровнях, отличающихся степенью близости к аппаратуре. Нижние уровни позволяют более полно использовать тонкие особенности устройств, но за это приходится платить сложностью программирования. Верхние уровни более удобны для решения стандартных задач ввода/вывода. Уровни доступа к устройствам показаны на рис. 2‑5. Рис.
2‑5 Самый нижний уровень предполагает, что программа пользователя работает непосредственно с портами ввода/вывода, а также, если это необходимо, частично или полностью берет на себя обработку аппаратных прерываний, поступающих от устройства. В принципе, программа пользователя может вообще не использовать средства MS-DOS для работы с устройствами, но при этом ей придется взять на себя много скучной работы. В работе MS-DOS широко используются возможности, предоставляемые BIOS (BasicInput/OutputSystem, базовая система ввода/вывода) – набором программных модулей, записанных в постоянной памяти (ПЗУ) компьютера. BIOS по умолчанию выполняет обработку всех аппаратных прерываний, если эту работу не берет на себя DOS или прикладная программа. Кроме того, BIOS содержит процедуры обработки ряда программных прерываний ввода/вывода. Программные прерывания BIOS представляют собой подпрограммы, выполняющие операции ввода/вывода и управления конкретными устройствами. Для каждого из стандартных устройств зарезервирован свой номер прерывания, а для указания требуемой операции используется номер функции, который заносится в один из регистров процессора перед вызовом прерывания. Драйверы устройств не вызываются непосредственно из программы пользователя. Они вызываются из функций DOS и выполняют заданную операцию, обычно используя для этого программные прерывания BIOS, хотя возможна и прямая работа драйвера с портами и аппаратными прерываниями. Функции DOS, в отличие от прерываний BIOS, работают не с конкретной аппаратурой, а с именованными устройствами. Имена устройств задаются в заголовках соответствующих драйверов. Например, для DOS клавиатура и экран объединяются драйвером консольного устройства CON. Процедуры ввода/вывода, используемые в языках программирования (например, Read и Write в Паскале, scanf и printf в C), при компиляции реализуются как подходящие вызовы функций DOS или, в особых случаях, программных прерываний BIOS. 2.8.2. Драйверы устройств в MS-DOS Драйвер устройства в MS-DOS состоит из трех блоков с известными нам названиями: заголовок драйвера, блок стратегии и блок прерываний. При близком рассмотрении оказывается, однако, что сходство ограничивается в основном названиями блоков. Заголовок драйвера содержит основную информацию об устройстве: символьное или блочное устройство; для символьных устройств – имя устройства; для блочных – количество однотипных устройств, обслуживаемых данным драйвером; не является ли данное устройство системной консолью, системными часами или пустым устройством; какие специальные операции поддерживает устройство. В заголовке содержатся адреса блока стратегии и блока прерываний, а также адрес заголовка следующего драйвера в списке. Когда система должна выполнить запрос на ввод/вывод, она просматривает список всех драйверов, пока не найдет устройство с нужным именем (если задано символьное устройство) или, для блочного устройства, не определит, какой по счету драйвер соответствует указанному номеру (букве) диска. Затем система вызывает блок стратегии найденного драйвера, передавая ему адрес заявки на выполнение операции. Затем вызывается блок прерываний. Если в файле конфигурации CONFIG.SYS указаны имена файлов дополнительных (загружаемых) драйверов, то эти драйверы помещаются в списке впереди стандартных системных драйверов. Поэтому, если имя устройства для загружаемого драйвера совпадает с именем стандартного устройства MS-DOS, то будет вызван загружаемый драйвер, а не стандартный. Блок стратегии драйвера MS-DOS не делает практически ничего, только запоминает адрес заявки. Блок прерываний выполняет всю работу по обработке заявки, причем у всех стандартных драйверов этот блок работает вовсе не по прерываниям, а по опросу готовности. По-видимому, разработчики первой версии MS-DOS предполагали когда-нибудь в будущем реализовать нормальную структуру драйвера, да так и не собрались. Заявка на выполнение операции содержит код операции, поле для записи результата операции, номер диска (для блочных устройств) и другие данные (например, адрес выводимых данных в памяти и адрес сектора на диске). Код операции определяет требуемую операцию – например, чтение, запись, запись с проверкой, открытие или закрытие устройства, проверка смены дискеты, опрос состояния устройства и т.п. Закончив выполнение операции, драйвер записывает в поле результата, была ли операция выполнена успешно или с ошибкой, и с какой именно (ошибка чтения, ошибка записи, нет бумаги в принтере, не найден сектор на диске, недопустимая операция для данного устройства и т.п.). 2.8.3. Управление символьными устройствами Работу MS-DOS с символьными устройствами интереснее всего рассмотреть на примере клавиатуры. Путь, который проходят при этом вводимые данные, схематично показан на рис. 2‑6. Рис.
2‑6 Когда пользователь нажимает клавишу, клавиатура переходит в состояние готовности и по этому поводу посылает сигнал аппаратного прерывания Int 09h. Одновременно в порт, к которому подключена клавиатура, посылается скан-код нажатия
клавиши. Этот код представляет собой однобайтовое число, означающее порядковый номер нажатой клавиши. Если клавиша долго удерживается нажатой, то через некоторое время начинается «автоповтор» – сигнал прерывания и скан-код посылаются многократно. Наконец, когда клавиша отпускается, генерируется еще одно прерывание и посылается скан-код отпускания
клавиши, который отличается от кода нажатия единичным значением старшего бита. Этим практически исчерпываются аппаратные события, связанные с клавиатурой. Все остальное делается программно. На самом деле, все происходило именно так со старой, 83-клавишной клавиатурой компьютеров IBMPCXT. Современные клавиатуры за одно нажатие умудряются послать от 1 до 4 скан-кодов подряд. Причины этого объяснять долго и не очень интересно. Подпрограмма BIOS, обрабатывающая аппаратное прерывание от клавиатуры, должна, во-первых, запоминать текущее состояние клавиатуры: нажаты или нет «сдвиговые» клавиши Shift, Ctrl, Alt, включены или нет режимы Caps Lock, Num Lock. Во-вторых, обработчик должен с учетом этого состояния определить, какой символ хотел ввести пользователь. Одна и та же клавиша может, например, означать букву ‘Z’ прописную или строчную, русскую букву ‘Я’ прописную или строчную, а также быть частью комбинаций Ctrl+Z, Alt+Z. Соответствующий символ будет помещаться в буфер клавиатуры в виде двух байт: скан-код нажатой клавиши и ASCII-код символа. Для некоторых клавиш и комбинаций, которым не соответствует никакой ASCII-код (например, F1, Insert, Ctrl+Home, Alt+буква, -), фирма IBM разработала собственный набор «расширенных» кодов. Буфер клавиатуры может вместить до 15 введенных символов, а при переполнении начинает противно пищать. Программное прерывание Int 16h также обрабатывается BIOS’ом. Его назначение – удовлетворять запросы программ, обращающихся к клавиатуре. Наиболее часто используются следующие три функции этого прерывания. · Ввод символа с ожиданием. Эта функция возвращает значение кодов очередного символа из буфера клавиатуры и удаляет этот символ из буфера. Если буфер был пуст, функция выполняет активное ожидание до тех пор, пока при обработке очередного нажатия клавиши в буфере не появится введенный символ. · Ввод символа без ожидания. Он отличается тем, что при пустом буфере не происходит ожидания, а возвращается соответствующий признак. Без этой функции было бы невозможно запрограммировать большую часть игр. · Опрос состояния клавиатуры. Возвращает информацию о текущем состоянии «сдвиговых» клавиш. Прикладные программы могут вызывать либо прерывание Int 16h, либо одну из функций DOS, предназначенных для ввода символов с консоли. Следует подчеркнуть, что эти функции работают не с клавиатурой, а с устройством CON (консолью оператора), через драйвер этого устройства. Конечно, практически всегда устройство CON – это и есть клавиатура (плюс еще и экран монитора, который используется при выводе символов на консоль). Однако теоретически есть возможность написать нестандартный драйвер устройства CON, который будет брать вводимые символы, например, с удаленного терминала, через модем. Или в качестве консольного устройства можно использовать пишущую машинку, как это и делалось раньше, до широкого распространения мониторов. Набор функций DOS для ввода с консоли довольно разнообразен. Однако ни одна из этих функций не использует особенностей клавиатуры как устройства. В частности, функции DOS не знают понятия «состояние клавиатуры». Зато набор функций включает ввод с «эхо-отображением» введенного символа на устройстве CON (т.е. на экране) или без отображения, с ожиданием или без ожидания, ввод одного символа или сразу строки (завершающейся нажатием Enter), а также ввод с предварительной очисткой буфера (чтобы давно завалявшиеся там символы не были случайно введены как ответ на задаваемый программой вопрос). Кратко рассмотрим работу с другими символьными устройствами. Монитор не посылает сигналов прерываний и вывод на него выполняется не через порт, а путем записи данных в область видеопамяти. Имеющееся программное прерывание BIOS практически используется для переключения видеорежима (текстовый или графический, число цветов, число точек на экране) и для изменения вида и положения курсора текстового режима. Вывод символов через BIOS достаточно медленный и используется в основном для небольших текстовых сообщений. В графических режимах BIOS работает неприемлемо медленно, ибо он за каждый вызов прерывания может вывести только одну точку. Серьезные программы работают с видеопамятью напрямую. Функции DOS для вывода на консоль не имеют даже права использовать такую специфику монитора, как управление курсором и выбор цвета, ведь они работают с устройством CON, которое может оказаться и пишущей машинкой. Для принтера BIOS предлагает возможность проверки состояния устройства (в частности, находится ли принтер в состоянии готовности) и вывода одного символа с опросом готовности. В то же время, DOS, кроме убогой функции вывода одного символа с ожиданием на устройство PRN, позволяет использовать системную программу PRINT, которая умеет выводить файлы в фоновом режиме, не мешая одновременно выполнять другие программы. Эта программа работает с аппаратными прерываниями в обход BIOS. Про работу с последовательным портом можно сказать почти то же самое, что про работу с принтером. Отличие в том, что порт может работать и на ввод данных. Один из самых верных способов «подвесить» систему навечно – запросить ввод символа из COM-порта с ожиданием через BIOS или DOS, если на вход порта не поступают никакие данные. Практически всегда работа с COM-портом ведется с помощью нестандартных драйверов, работающих по прерываниям. Мышь вообще не является стандартным устройством для компьютеров – потомков IBMPC. BIOS ничего не знает о существовании мышей. Драйверы мыши мало похожи на другие драйверы MS-DOS. Они позволяют опрашивать текущее положение мыши и состояние кнопок, однако более удобной для приложений является возможность задать с помощью драйвера собственную процедуру обработки прерываний от мыши. Эта процедура должна определять, в каком месте экрана был курсор при нажатии кнопки мыши, какой элемент управления (кнопка, пункт меню, полоса прокрутки и т.п.) находится в этой точке, и только потом – какое действие следует предпринять при щелчке мыши на этом элементе. Слишком много черновой работы, которую более современные ОС (например, Windows) берут на себя. 2.8.4. Управление блочными устройствами Основным видом блочных устройств являются магнитные и другие диски, поэтому начнем с рассмотрения структуры диска (рис. 2‑7). Рис.
2‑7 Поверхность нового магнитного диска покрыта однородным слоем магнитного материала. У дискеты используется либо одна поверхность, либо (чаще) обе поверхности. Число поверхностей жесткого дискового тома определяется количеством дисков, из которых собран том. Первой операцией, которая должна быть проделана с диском, является низкоуровневое форматирование
. Оно заключается в разметке поверхности на дорожки
магнитной записи, разделенные на секторы
. Расстояние между дорожками определяется шагом перемещения головок чтения/записи, а разбиение на секторы выполняется программно, путем записи данных на дорожки в моменты, рассчитанные на основании известной скорости вращения диска. Для всех операций с диском, кроме низкоуровневого форматирования, сектор является минимальной единицей чтения или записи данных. Совокупность дорожек одинакового радиуса на всех поверхностях диска называется цилиндром
. Структура сектора показана на рис. 2‑8. Рис.
2‑8 Сектор состоит из заголовка, блока данных и контрольной информации (контрольной суммы), которая служит для проверки правильности считывания сектора. Заголовок сектора содержит физический адрес
сектора и его размер. Физический адрес состоит из трех чисел: номер цилиндра, номер поверхности и номер сектора на дорожке. Самый первый сектор диска имеет адрес (0, 0, 1). Размер сектора на IBM-совместимых компьютерах всегда равен 512 байт. Одно время было модно использовать нестандартный размер отдельных секторов на дискете (например, 1024 байта) для затруднения несанкционированного копирования. Дискету, содержащую нестандартный сектор, могла правильно прочитать только программа, которой было точно известно о наличии такого сектора. Между секторами и внутри секторов имеются промежутки, которые используются аппаратурой при поиске заданного сектора. Нумерация секторов не обязательно ведется в порядке их размещения на дорожке. Если скорость имеющейся аппаратуры недостаточна для того, чтобы успеть прочесть и передать в память данные со всей дорожки за время одного оборота диска, то система при форматировании нумерует секторы «через один» или даже «через два». Например, при 9 секторах на дорожке они могут быть пронумерованы «через один» в таком порядке: 1, 6, 2, 7, 3, 8, 4, 9, 5. После чтения сектора 1 у контроллера диска есть время передать прочитанные данные, пока к головке чтения не подойдет сектор 2. В результате вся дорожка может быть прочитана за два оборота диска. Общая структура дискет и жестких дисков различаются между собой. Эти структуры показаны на рис. 2‑9. Рис.
2‑9 Начальный сектор дискеты (рис. 2‑9, а) принято называть BOOT-сектором
. Он содержит количественные данные о дискете (размер секторов, количество секторов на каждой дорожке и на всей дискете, число поверхностей и т.п.), метку (название) и серийный номер дискеты, а также данные о файловой системе. Кроме того, если дискета содержит системные файлы ОС, то в BOOT-секторе находится также небольшая программа начальной загрузки, которая считывает один сектор ОС и передает ему управление для продолжения загрузки. Все остальные секторы дискеты могут использоваться ОС для хранения ее файлов и других данных. Общее количество секторов на дискете не может превышать 216
(на самом деле, их значительно меньше). Скажите быстро, сколько примерно секторов содержит стандартная трехдюймовая дискета? Для жесткого диска (рис. 2‑9, б) начальный сектор называется MBR (MasterBootRecord, главная загрузочная запись). Он тоже может содержать программу начальной загрузки, но, кроме того, содержит таблицу разделов
(partitiontable), которая описывает разбиение жесткого диска на разделы
. Таблица может содержать от 1 до 4 записей о разделах. Каждая запись содержит тип раздела, число секторов в нем, физические адреса начала и конца раздела. Возможны следующие типы разделов. · Обычный
раздел. Его структура точно такая же, как у дискеты, т.е. такой раздел начинается с BOOT-сектора, а общее число секторов не превышает 216
. Таким образом, общий размер раздела не может превышать 32 Мб. · Большой
раздел. Он отличается от обычного тем, что число секторов может достигать 232
. Это позволяет описывать большие разделы размером до 2048 Гб. · Расширенный
раздел. Его структура аналогична структуре всего жесткого диска, т.е. начальный сектор раздела – не BOOT, а MBR-сектор. Аналогия не совсем полная, поскольку таблица разделов в MBR расширенного раздела может содержать не более двух записей, причем первая из них должна описывать либо обычный, либо большой раздел, а вторая запись, если она имеется, описывает еще один расширенный раздел. · Разделы других ОС (например, UNIX). Обычные и большие разделы называются также логическими томами
или логическими дисками
, в отличие от физических дисков. Обычная буквенная нумерация дисков A, B, C, D и т.д. относится именно к логическим томам. Для дискет понятия физического и логического тома совпадают. Изначально MS-DOS поддерживала только обычные разделы на жестком диске. В 80-е годы казалось, что 32 Мб – это очень большой объем диска. Когда появились диски объемом в несколько сотен мегабайт, была придумана матрешечная структура расширенных разделов, что позволило на одном физическом томе разместить сколько угодно логических томов по 32 Мб. Затем были реализованы большие разделы, что потребовало от разработчиков MS-DOS внести существенные изменения в программный интерфейс и реализацию средств работы с дисками. После этого использование расширенных разделов стало необязательным, если пользователю достаточно иметь не более четырех логических томов на одном физическом диске. На уровне архитектуры системы контроллер диска представлен несколькими регистрами, доступными через порты компьютера. В эти порты перед выполнением операций заносятся такие данные, как номер диска, количество секторов, участвующих в операции и физический адрес начального сектора, записываемые данные. Один из портов служит для посылки команды на выполнение операции (чтение, запись, запись с проверкой, поиск цилиндра, форматирование дорожки и др.). Когда операция завершена, контроллер посылает сигнал прерывания. Прикладные программы могут работать с дисками либо средствами BIOS (программное прерывание int 13h), либо средствами DOS (программные прерывания int 25h – чтение и int 26h – запись). При этом BIOS работает только с физическими дисками, используя физическую нумерацию секторов, в то время как MS-DOS работает только с логическими томами, а секторы при этом нумеруются числами от 0 (что соответствует BOOT-сектору) до максимального номера сектора на томе. На практике то и другое используется достаточно редко. Большинство прикладных программ не работают с дисками как с устройствами, вместо этого работа ведется на уровне файлового ввода/вывода, а отображение файлов на секторы диска является обязанностью ОС. Для повышения эффективности работы с дисками в MS-DOS используются кэширование дисков и опережающее чтение, описанные в пп. 2.6.6 и 2.6.7. Дисковый кэш в MS-DOS устроен проще, чем в UNIX. Во-первых, в однозадачной системе нет необходимости в списке свободных блоков (когда процесс обращается к диску, нет других процессов, которые могли бы в это время работать с буферами). Во-вторых, размер кэша редко превышает 30 – 40 буферов, поэтому не нужны и хеш-цепочки, все буфера объединены в едином LRU-списке. Почему в MS-DOS не нужен такой большой кэш, как в UNIX? Поскольку Windows – многозадачная система, она исключает для прикладных программ такие вольности, как прямое обращение к портам ввода/вывода или обработка аппаратных прерываний. Взаимодействие с аппаратурой на низком уровне может выполняться только системными программами, работающими в привилегированном режиме. Основную роль здесь играют драйверы устройств. В Windows используется многоуровневая структура драйверов, в которой высокоуровневые драйверы могут играть роль фильтров, выполняющих специальную обработку данных, полученных от драйвера низкого уровня или передаваемых такому драйверу. В качестве примера можно привести отделение драйвера, управляющего шиной, от драйверов конкретных устройств, подключенных к шине. Еще один пример – драйвер, выполняющий шифрацию/дешифрацию данных при работе с файловой системой NTFS. Структура драйверов всех уровней подчинена единым стандартам, известным как WDM (WindowsDiverModel), однако высокоуровневые драйверы, в отличие от низкоуровневых, не занимаются обработкой аппаратных прерываний. Как ни странно, в WindowsNT низкоуровневые драйверы – это еще не самый нижний уровень управления устройствами. Еще ближе к аппаратуре лежит так называемый уровень HAL (HardwareAbstractionsLevel, уровень аппаратных абстракций). Его роль – скрыть от остальных модулей ОС, в том числе и от драйверов, некоторые детали работы с аппаратурой, зависящие от конкретных шин, типа материнской платы, способа подключения. Например, HAL предоставляет драйверам возможность обращаться к регистрам устройств по их логическим номерам, не зная при этом, подключен ли регистр к порту процессора или отображен на память. Несмотря на стандартизацию структуры, можно выделить несколько специальных типов драйверов, отличающихся функциональным назначением. · Драйверы GDI (GraphicDeviceInterface) представляют собой высокоуровневые драйверы графических устройств (мониторов, принтеров, плоттеров). Эти драйверы выполняют трансляцию графических вызовов Windows (таких, как «провести линию», «залить область», «выдать текст», «выбрать текущий шрифт, текущее перо, текущую заливку») в команды, выполняющие соответствующие действия на конкретном устройстве. Выдача этих команд на устройство выполняется уже другим, низкоуровневым драйвером. Благодаря наличию драйверов GDI одна и та же программа может выдавать графическое изображение на разные устройства. Яркий пример этого – имеющийся в различных редакторах режим предварительного просмотра, который отображает страницы на экране точно в том виде, как они будут напечатаны. · Драйверы клавиатуры и мыши, помимо стандартных для драйвера операций, выполняют дополнительную нагрузку. Они генерируют сообщения о событиях на соответствующем устройстве (нажатие и отпускание клавиши, перемещение мыши, нажатие и отпускание кнопок мыши) и помещают их в системную очередь сообщений. Затем система переправляет каждое сообщение процессу, которому оно было предназначено, для дальнейшей обработки. · Драйверы виртуализации устройств (VxD-драйверы) служат для того, чтобы разделять устройства между процессами, создавая иллюзию, что процесс монопольно владеет устройством. На самом деле драйвер организует очередь заявок от процессов, переключает устройство в нужный для очередного процесса режим и т.п. Примером может служить драйвер виртуализации монитора. Консольное приложение (например, программа MS-DOS) работает со всем экраном в текстовом режиме. Но если такое приложение запущено в окне Windows, то VxD-драйвер имитирует текстовый режим в графике. Для этого драйвер должен перехватывать попытки программы обратиться напрямую к адресам видеопамяти и преобразовывать координаты знакомест текстового режима в координаты соответствующих позиций в окне. В большинстве случаев программы не работают непосредственно с устройствами. Вместо этого для выполнения требуемых операций используются API-функции более высокого уровня, а обращения к устройствам выполняются системой по мере надобности. Например, файловые функции обращаются в конечном счете к дисковым устройствам, а функции GDI работают с монитором или с принтером, в зависимости от указанного контекста устройства. В ряде случаев программист все же может предпочесть непосредственную работу с устройством. Чтобы получить доступ к устройству, программа должна открыть это устройство вызовом той же API-функции CreateFile, которая используется и для открытия файлов. В данном случае вместо имени файла следует указать имя драйвера открываемого устройства. Для дисковых устройств можно вместо имени драйвера указать имя самого устройства. Например, имя «\\.\C:» означает логический диск C, а имя «\\.\PHYSICALDRIVE0» – первый физический диск компьютера. Открыв устройство, программа может либо читать или записывать данные, используя функции файлового ввода/вывода, либо выдавать команды управления устройством с помощью функции DeviceIoControl. С помощью этих команд можно, например, отформатировать диск и разбить его на разделы, загрузить или извлечь CD-ROM диск, изменить некоторые параметры работы модема и т.п.. 2.10.1. Драйверы устройств в
UNIX Драйверы в ОС UNIX довольно точно соответствуют стандартной схеме драйвера, приведенной в п. 2.7. Тем не менее, ввиду существенных различий в работе с символьными и с блочными устройствами, в UNIX различаются два основных типа драйверов: символьные и блочные. Для символьных устройств используются только символьные драйверы. Для каждого блочного устройства обычно имеется два разных драйвера: блочный и символьный. Блочный драйвер позволяет выполнять операции только с целым числом блоков, как и положено работать с блочными устройствами. Символьный драйвер блочного устройства является более высокоуровневой программой, которая имитирует выполнение операций чтения и записи произвольного количества байт, на самом деле используя обращения к блочному драйверу. Помимо драйверов реальных физических устройств, система может включать драйверы «псевдоустройств». Примером может служить драйвер, обеспечивающий обращение программ к содержимому системной памяти. При загрузке системы формируются две таблицы, для символьных и для блочных драйверов. Строки таблицы соответствуют конкретным драйверам, а столбцы – функциям, которые должен уметь выполнять драйвер, так что в ячейках таблицы содержатся адреса, по которым вызываются функции драйвера. Набор функций для символьных и для блочных драйверов слегка разнится, поэтому используются две разных таблицы. К наиболее важным функциям драйвера относятся следующие. · Открытие устройства. Как минимум, при этом увеличивается счетчик текущих обращений к устройству, что позволяет ставить обращения в очередь, если устройство занято. Некоторые устройства при открытии могут выполнять еще какие-то начальные действия. · Закрытие устройства – операция, противоположная открытию. · Обработка прерывания – выполняет ввод или вывод очередной порции данных, когда устройство переходит в состояние готовности. · Опрос устройства – эта функция выполняется для тех устройств, которые не генерируют прерываний, или если при разработке драйвера почему-либо решено не использовать прерывания от устройств. Опрос выполняется не постоянно, а с некоторым периодом, по прерыванию от таймера. · Чтение данных с устройства. · Запись данных на устройство. · Вызов стратегии. Это способ выполнения операций ввода/вывода, характерный для блочных устройств. При этом запрос может быть поставлен в очередь. Запрос в ряде случаев может быть удовлетворен путем обращения к дисковому кэшу (см. п. 2.6.6), без выполнения чтения или записи на устройство. · Выполнение специальных функций. Набор этих функций зависит от конкретного устройства. Это может быть, например, опрос или установка текущего режима работы устройства, форматирование дорожек диска, перемотка ленты и т.п. 2.10.2. Устройство как специальный файл Интересной отличительной особенностью UNIX является то, что для работы с периферийными устройствами прикладные программы могут и должны использовать те же средства, что для работы с файлами. Вообще, устройства в UNIX представлены как специальные файлы
, вписанные в каталог файловой системы наравне с обычными файлами. Каждому драйверу устройства соответствует отдельный специальный файл, символьный или блочный, в зависимости от типа драйвера. Как правило, все специальные файлы размещаются в каталоге /dev. Чтобы начать работу с устройством, программа должна вызвать функцию открытия файла, указав ей имя специального файла. При этом происходит обращение к функции открытия из драйвера соответствующего устройства. С каждым специальным файлом связаны два числа, называемые старшим и младшим номерами устройства. Старший номер определяет номер строки в таблице символьных либо блочных драйверов. Младший номер передается драйверу как дополнительный параметр. Он может означать, например, номер конкретного дискового устройства. Старинный термин «управление данными» в настоящее время всегда понимается как управление файлами. Файл
есть набор данных, хранящийся на периферийном устройстве и доступный по имени. При этом конкретное расположение данных на устройстве не интересует пользователя и полностью передоверяется системе. До изобретения файлов пользователь должен был обращаться к своим данным, указывая их адреса на диске или на магнитной ленте. Понятие «файловая система
» означает стандартизованную совокупность структур данных, алгоритмов и программ, обеспечивающих хранение файлов и выполнение операций с ними. Мощная современная ОС обычно поддерживает возможность использования нескольких разных файловых систем. И наоборот, одна и та же файловая система может поддерживаться различными ОС. Среди задач, решаемых подсистемой управления данными, можно назвать следующие: · выполнение операций создания, удаления, переименования, поиска файлов, чтения и записи данных в файлы, а также ряда вспомогательных операций; · обеспечение эффективного использования дискового пространства и высокой скорости доступа к данным; · обеспечение надежности хранения данных и их восстановления в случае сбоев; · защита данных пользователя от несанкционированного доступа; · управление одновременным совместным использованием данных со стороны нескольких процессов. С каждым файлом связан набор атрибутов
(характеристик
), т.е. набор сведений о файле. Состав атрибутов может сильно различаться для разных файловых систем. Приведем примерный список возможных атрибутов, не привязываясь к какой-либо конкретной системе. · Имя файла
. В старых ОС длина имени была жестко ограничена 6 – 8 символами с целью экономии места для хранения имени и ускорения работы. В настоящее время максимальная длина имени составляет обычно около 250 символов, что позволяет при желании включить в имя файла подробное описание его содержимого. · Расширение имени
. По традиции, так принято называть правую часть имени, отделенную точкой. В MS-DOS, как и в некоторых более ранних системах, этот атрибут не является частью имени, он хранится отдельно и ограничивается по длине 3 символами. Однако сейчас возобладал подход, принятый в UNIX, где расширение – это чисто условно выделяемая часть имени после последней точки. Расширение обычно указывает тип данных в файле. · Тип файла
. Некоторые ОС выделяют несколько существенно различных типов файлов, например, символьные и двоичные, файлы данных и файлы программ и т.п. Ниже будут рассмотрены типы файлов, различаемые UNIX. · Размер файла
. Обычно указывается в байтах, хотя раньше часто задавался в блоках. · Временн
ые штампы
. Под этим термином понимаются различные отметки даты и, может быть, времени дня. Важнейшим из временных штампов является время последней модификации, позволяющее определить наиболее свежую версию файла. Полезными могут быть также время последнего доступа (т.е. открытия файла), время последней модификации атрибутов. · Номер версии
. В некоторых ОС при всяком изменении файла создавалась его новая версия, причем система могла хранить либо все версии, либо только несколько последних. Это давало немаловажное преимущество – возможность вернуться к старой версии файла, если изменения оказались неудачными. Тем не менее, этот атрибут не привился из-за большой избыточной траты дисковой памяти. При необходимости разработчики могут использовать специальные программные системы управления проектами, обеспечивающие в том числе и хранение старых версий файлов. · Владелец файла
. Этот атрибут необходим в многопользовательских системах для организации защиты данных. Как правило, владельцем является пользователь, который создал файл. Иногда, кроме индивидуального владельца, указывается еще и группа пользователей как коллективный владелец файла. · Атрибуты защиты
. Они указывают, какие именно права доступа к файлу имеют различные пользователи, в том числе и владелец файла. · Тип доступа
. В некоторых ОС (например, в OS/360) для каждого файла должен был храниться допустимый тип доступа: последовательный, произвольный или один из индексных типов, обеспечивающих быстрый поиск данных в файле. В настоящее время более распространен подход, при котором для всех файлов поддерживаются одни и те же типы доступа (последовательный и произвольный), а ускорение поиска должно обеспечиваться, например, системой управления базами данных. · Размер записи
. Если эта величина указана, то адресация нужных данных выполняется с помощью номера записи. Другой подход заключается в том, что данные адресуются их смещением (в байтах) от начала файла, а разбиение файла на записи возлагается на прикладные программы, работающие с файлом. · Флаги
(битовые атрибуты
). Их разнообразие ограничивается лишь фантазией разработчиков системы, но наиболее распространенным и важным является флаг «только для чтения» (readonly), защищающий файл от случайного изменения или удаления. В зависимости от возможностей конкретной файловой системы, файл может быть отмечен как «сжатый», «шифрованный» и т.п. · Данные о размещении файла на диске
. Пользователь, как правило, не знает и не хочет ничего знать о размещении файла (именно для этого и существует понятие файла). Для системы эти данные необходимы, чтобы найти файл. Записи, в которых содержатся атрибуты каждого файла, собраны в каталоги
(они же папки, директории). В ранних ОС (и даже в первой версии MS-DOS) на каждом дисковом томе имелся единственный каталог, содержащий полный список всех файлов этого тома. Такое решение было вполне естественным, пока количество файлов не превышало двух – трех десятков. Однако при увеличении объема дисков и, как следствие, числа файлов на них такой одноуровневый каталог становился все менее удобным. В некоторых ОС использовалась двухуровневая организация каталогов. При этом главный каталог содержал список каталогов второго уровня, закрепленных за отдельными пользователями или проектами. Однако позднее стала общепринятой иерархическая структура каталогов
, при которой каждый каталог может, помимо файлов, содержать вложенные подкаталоги, причем глубина вложения не ограничивается. Все хранящиеся в файловой системе служебные данные, описывающие атрибуты и размещение файлов, структуру каталогов, общую структуру дискового тома и т.п., принято называть метаданными
, в отличие от «просто данных», хранящихся в файлах. Помимо устройств произвольного доступа (дисков), файлы могут храниться и на таких устройствах последовательного доступа, как магнитные ленты. Однако для лент ведение каталогов затруднительно и польза от них невелика. Как правило, имя и прочие атрибуты файла записываются на ленту непосредственно перед данными этого файла. Область данных диска, отведенную для хранения файлов, можно представить как линейную последовательность адресуемых блоков (секторов). Размещая файлы в этой области, ОС должна отвести для каждого файла необходимое количество блоков и сохранить информацию о том, в каких именно блоках размещен данный файл. Существуют два основных способа использования дискового пространства для размещения файлов. · Непрерывное размещение
характеризуется тем, что каждый файл занимает непрерывную последовательность блоков. · Сегментированное размещение
означает, что файлы могут размещаться «по кусочкам», т.е. один файл может занимать несколько несмежных сегментов разной длины. Оба способа размещения показаны на рис. 3‑1. Рис.
3‑1 Непрерывное размещение имеет два серьезных достоинства. · Информация о размещении файла очень проста и занимает мало места. Фактически достаточно хранить два числа: номер начального блока файла и число занимаемых блоков (или размер файла в байтах, по которому легко вычислить число блоков). · Доступ к любой позиции в файле выполняется быстро, поскольку, зная смещение от начала файла, легко можно вычислить номер требуемого блока и прочитать сразу этот блок, не читая предыдущие блоки. К сожалению, недостатки непрерывного распределения еще более весомы. · При создании файла требуется заранее знать его размер, чтобы найти и зарезервировать на диске область достаточной величины. Последующее возможное увеличение файла весьма затруднено, т.к. после конца файла может не оказаться достаточно свободного места. Фактически вместо увеличения файла обычно приходится заново создавать файл большего размера в другом месте, переписывать в него данные и удалять старый файл. Но такое решение требует много времени на чтение и запись данных и, кроме того, снижает надежность хранения данных, поскольку ошибка при чтении или записи гораздо более вероятна, чем порча данных, «спокойно лежащих» на диске. · В ходе обычной эксплуатации файловой системы, после многократного создания и удаления файлов разной длины, свободное пространство на диске оказывается разбитым на небольшие кусочки. Суммарный объем свободного места на диске может быть достаточно большим, но создать файл приличного размера не удается, для него нет непрерывной области нужной длины. Это явление носит название фрагментации диска
. Для борьбы с ним приходится использовать специальную процедуру дефрагментации, которая перемещает все файлы, размещая их впритык друг к другу от начала области данных диска. Но такая процедура требует много времени, снижает, как сказано выше, надежность и усугубляет проблемы в случае, если позднее потребуется увеличить файл. Сегментированное размещение лишено первого из недостатков непрерывного: при создании файла ему обычно вообще не выделяют память, а потом, по мере возрастания размера файла, ему могут быть выделены любые свободные сегменты на диске, независимо от их длины. Не так просто с фрагментацией. Конечно, в отличие от непрерывного размещения, при сегментированном никакая фрагментация не помешает системе использовать все блоки, имеющиеся на диске. Однако последовательное чтение из сегментированного файла может выполняться существенно медленнее за счет необходимости переходить от сегмента к сегменту. Замедление особенно заметно, если файл оказался разбросан маленькими кусочками по нескольким цилиндрам диска. В результате, время от времени целесообразно выполнять дефрагментацию диска, чтобы повысить скорость доступа к данным. При сегментированном размещении дефрагментация означает не только объединение всех свободных участков диска, но и, главным образом, объединение сегментов каждого файла. Эта процедура выполняется значительно сложнее, чем дефрагментация при непрерывном размещении. Можете ли вы предложить хороший алгоритм дефрагментации? Учтите, что он должен эффективно работать, даже если на диске осталось всего несколько свободных блоков. Недостатком сегментированного размещения является то, что информация о размещении файла в этом случае намного сложнее, чем для непрерывного случая и, что наиболее неприятно, объем этой информации переменный: чем большее число сегментов занимает файл, тем больше нужно информации, ибо надо перечислить все сегменты. Имеется почти столько же способов решения этой проблемы, сколько вообще придумано разных файловых систем. Чтобы уменьшить влияние сегментации на скорость доступа к данным файла, в ОС, использующих сегментированное размещение, применяются различные алгоритмы выбора места для файла. Их целью является разместить файл по возможности в одном сегменте, и только в крайнем случае разбивать файл на несколько сегментов. В современных ОС для файловых систем на магнитных дисках практически всегда используют сегментированное размещение. Иное дело файловые системы на дисках, предназначенных только для чтения (например, CDROM). Нетрудно понять, что в этом случае недостатки непрерывного размещения не имеют никакого значения, а его достоинства сохраняются. Еще одной важной характеристикой размещения файлов является степень его «дробности». До сих пор мы предполагали, что файл может занимать любое целое число блоков, а под блоком фактически понимали сектор диска. Проблема в том, что для дисков большого объема число блоков может быть слишком большим. Допустим, в некоторой файловой системе размер блока равен 512 байт, а для хранения номеров блоков файла используются 16-разрядные числа. В этом случае размер области данных диска не сможет превысить 512 * 216
= 32 Мб, что нынче смешно. Конечно, можно перейти к использованию 32-разрядных номеров блоков, но тогда суммарный размер информации о размещении всех файлов на диске становится чересчур большим. Обычный выход из этого затруднения заключается в том, что минимальной единицей размещения файлов считают кластер
(называемый в некоторых системах блоком
или логическим блоком
), который принимается равным 2k
секторов, т.е., например, 1, 2, 4, 8, 16, 32 сектора, редко больше. Каждому файлу отводится целое число кластеров, и в информации о размещении файла хранятся номера кластеров, а не секторов. Увеличение размера кластеров позволяет сократить количество данных о размещении файлов «и в длину и в ширину»: во-первых, для каждого файла нужно хранить информацию о меньшем числе кластеров, а во-вторых, уменьшается число двоичных разрядов, используемых для задания номера кластера (либо при той же разрядности можно использовать больший диск). Так, при кластере размером 32 сектора и 16-разрядных номерах можно адресовать до 1 Гб дисковой памяти. Использование больших кластеров имеет свою плохую сторону. Поскольку размер файла можно считать случайной величиной (по крайней мере, этот размер никак не связан с размером кластера), то можно приближенно считать, что в среднем половина последнего кластера каждого файла остается незанятой. Это явление иногда называют внутренней фрагментацией
(в отличие от описанной выше фрагментации свободного пространства диска, которую называют также внешней
фрагментацией). Кроме того, если хотя бы один из секторов, входящих в кластер, отмечен как дефектный, то и весь кластер считается дефектным, т.е. не может быть использован. Очевидно, что при увеличении размера кластера возрастает и число неиспользуемых секторов диска. Оптимальный размер кластера либо вычисляется автоматически при форматировании диска, либо задается вручную. Для нормальной работы файловой системы требуется, чтобы, кроме информации о размещении файлов, система хранила в удобном для использования виде информацию об имеющихся свободных кластерах диска. Эта информация необходима при создании новых или увеличении существующих файлов. Используются различные способы представления информации о свободном месте, некоторые из них перечислены ниже. · Можно хранить все свободные кластеры как связанный линейный список, т.е. в начале каждого свободного кластера хранить номер следующего по списку. Недостаток такого способа в том, что затрудняется поиск свободного непрерывного фрагмента нужного размера, поэтому сложнее оптимизировать размещение файлов. · Названный недостаток можно преодолеть, если хранить список не из отдельных кластеров, а из непрерывных свободных фрагментов диска. Правда, работать с таким списком несколько сложнее. · В системах с непрерывным размещением часто каждый непрерывный фрагмент диска описывают так же, как файл, но отмечают его флажком «свободен». · Удобный и простой способ заключается в использовании битовой карты
(bitmap) свободных кластеров. Она представляет собой массив, содержащий по одному биту на каждый кластер, причем значение 1 означает «кластер занят», а 0 – «кластер свободен». Для поиска свободного непрерывного фрагмента нужного размера система должна будет просмотреть весь массив. В многопользовательских ОС первостепенное значение приобретает задача защиты данных пользователя от случайного или намеренного доступа со стороны других пользователей. Вопросы защиты данных и стандартизации требований к безопасности ОС заслуживают изучения в отдельном курсе, поэтому здесь они будут рассмотрены очень кратко. Как отмечалось в п. 1.6, для реализации многопользовательской защиты данных необходимо наличие аппаратных средств, таких как привилегированный режим работы процессора. В противном случае любая чисто программная система защиты могла бы быть нарушена с помощью достаточно изощренной программы взлома. Для любой системы защиты характерно наличие, по крайней мере, трех компонент. · Список пользователей системы, содержащий имена, пароли и привилегии, присвоенные пользователям. · Наличие атрибутов защиты у файлов и других защищаемых объектов. Эти атрибуты указывают, кто из пользователей имеет право доступа к данному объекту и какие именно операции ему разрешены. · Процедура аутентификации пользователя
, т.е. установление его личности при входе в систему. Такие процедуры чаще всего основаны на вводе пароля, хотя могут использоваться и более экзотические средства (отпечатки пальцев, специальные карточки и т.п.). Помимо отдельных пользователей, определенными правами доступа к объектам могут обладать группы пользователей
. Понятие группы облегчает администрирование прав доступа. Вместо того, чтобы индивидуально указывать набор прав для каждого пользователя, достаточно зачислить его в одну или несколько групп, права которых определены заранее. Нормальное обслуживание системы защиты невозможно без наличия администратора системы
(он же в различных системах именуется привилегированным пользователем
или суперпользователем
) или же группы пользователей, обладающих правами администратора. Администратор назначает права прочим пользователям, а также имеет возможность в чрезвычайных случаях получить доступ к объектам любого владельца. Однако при этом желательно, чтобы действия администратора, как минимум, фиксировались системой с целью выявления возможных злоупотреблений с его стороны. В многозадачных ОС, а также в сетевых системах, возможна ситуация, когда два или более процессов пытаются одновременно использовать один и тот же файл. Например, два пользователя могут одновременно работать с одной базой данных. Будем предполагать, что с правами доступа все в порядке, каждый процесс в отдельности имеет право читать и записывать файл. Вопрос в том, можно ли разрешить одновременную работу, не приведет ли это к нарушению целостности данных. Может привести. Если один процесс обновляет данные в файле, а другой в это время пытается читать эти же данные, то он может прочесть частично обновленные данные. Еще опаснее, когда два процесса пытаются одновременно изменить одни и те же данные. В этом случае трудно даже предсказать, что в результате будет сохранено в файле. В принципе, всегда безопасными являются лишь два крайних случая: · только один процесс работает с файлом, выполняя чтение и запись; · с файлом работает произвольное число процессов, но все они выполняют только чтение. ОС могла бы обеспечить безопасный доступ, разрешая процессу открывать файл только в этих двух случаях, т.е. если файл не открыт еще ни одним другим процессом либо если файл открыт кем-то только для чтения и данный процесс тоже открывает его для чтения. Однако такая суровость в ряде случаев существенно снизила бы производительность системы. Скажем, много пользователей хотели бы одновременно работать с одной базой данных. И в этом нет ничего плохого, пока они работают с разными записями базы. Опасность возникает только при одновременной работе с одной и той же записью. Но ОС не может сама отследить ситуацию так подробно, это может сделать программа, управляющая базой данных. Ввиду подобных ситуаций, большинство ОС позволяют программам процессов самим определять, допустим ли совместный доступ в различных конкретных ситуациях. Типичное решение заключается в следующем. Прикладная программа, вызывая системную функцию открытия файла, указывает два дополнительных параметра: режим доступа и режим разделения. Режим доступа
определяет, какие операции сам процесс собирается выполнять с файлом. Обычно различают доступ «только для чтения», «только для записи», «для чтения и записи». Режим разделения
определяет, какие операции данный процесс готов разрешить другим процессам, которые захотят открыть тот же файл. Примерный набор режимов разделения – «запрет записи», «запрет чтения», «запрет чтения и записи» и «без запретов». Первый процесс, открывающий файл, устанавливает по своему усмотрению режимы доступа и разделения. Когда второй процесс пытается открыть тот же файл, ОС проверяет два условия: · режим доступа второго процесса не должен противоречить режиму разделения, установленному первым процессом; · режим разделения, запрашиваемый вторым процессом, не должен запрещать тот режим доступа, который уже установил для себя первый процесс. В случае нарушения одного из этих условий система не открывает файл для второго процесса, функция открытия файла возвращает ошибку. Если же условия соблюдены, система открывает файл для второго процесса, как бы снимая с себя ответственность за последствия: вы этого хотели – получите. До сих пор речь шла только о поведении процессов и системы при открытии файла. Однако это не полностью решает проблему. Вернемся к примеру с базой данных. Пусть соответствующий файл открыт несколькими процессами. Когда один из процессов приступает к работе с конкретной записью, он должен иметь возможность временно запретить или ограничить доступ других процессов к этой же записи. Для этой цели служит блокировка
процессом фрагментов файла. Для установления блокировки процесс вызывает соответствующую системную функцию, указывая начало блокируемого фрагмента и его размер. Если другой процесс после этого попытается прочитать или записать данные, хотя бы частично попадающие в заблокированный фрагмент, то либо функция чтения (записи) выдаст ошибку, либо процессу придется ждать снятия блокировки. Как правило, блокировка устанавливается на как можно меньший интервал времени, чтобы не снижать производительность системы. Описанный выше тип блокировки называется эксклюзивной
или исключительной блокировкой: процесс разрешает себе и чтение, и запись, а другим процессам временно запрещает то и другое. Некоторые системы допускают также кооперативную
(не исключительную) блокировку: устанавливая ее, процесс запрещает только запись всем процессам, в том числе и себе самому, в то время как чтение остается разрешенным для всех. 3.6.1. Общая характеристика системы FAT Система FAT была разработана для ОС MS-DOS. Это простая файловая система с сегментированным размещением, без многопользовательской защиты. Структура каталогов – древовидная, причем на каждом дисковом томе создается отдельное дерево. Для указания местоположения файла может использоваться его полное имя
, содержащее букву диска, путь по дереву каталогов и собственно имя файла, например: «C:\UTILS\ARCH\RAR.EXE». В ОС Windows также возможно использование FAT, особенно оправданное для дискет. Для жестких дисков большого объема система FAT становится малоэффективной и постепенно вытесняется более мощной системой NTFS. 3.6.2. Структуры данных на диске При форматировании дискеты или раздела жесткого диска в системе FAT все дисковое пространство разбивается на следующие области, показанные на рис. 3‑2. Рис.
3‑2 · BOOT-сектор
содержит основные количественные параметры дискового тома и файловой системы, а также может содержать программу начальной загрузки ОС. · таблица FAT
(FileAllocationTable) – содержит информацию о размещении файлов и свободного места на диске. Ввиду критической важности этой таблицы она всегда хранится в двух экземплярах, которые должны быть идентичны[4]
. Каждая операция, изменяющая содержимое FAT, должна одинаковым образом изменять оба экземпляра. · ROOT
– корневой каталог системы, содержащий данные о файлах и о подкаталогах верхнего уровня, каждый из которых в свою очередь может содержать файлы и подкаталоги. · Область данных
– массив кластеров, содержащий все файлы и все каталоги (кроме корневого). Рассмотрим подробно, как хранится вся информация о файле, имеющаяся в системе FAT. При создании файла в одном из каталогов файловой системы создается запись, хранящая основной объем информации об этом файле. Каждый каталог, кроме корневого, также является файлом особого вида, и запись о нем содержится в родительском каталоге. Каталожная запись всегда занимает 32 байта, ее структура показана в табл. 3.1. Таблица 3.1 Структура записи каталога файловой системы FAT Как видно из таблицы, имя файла может занимать не более 8 символов плюс еще 3 символа расширения. В начале 80-х годов казалось, что этого вполне достаточно. Позднее это ограничение окрестили «проклятием 8 + 3», и избавить от него файловую систему FAT удалось только в Windows 95. Байт атрибутов содержит набор битов, характеризующих свойства файла. Наряду с практически бесполезными атрибутами «скрытый», «системный» и «архивный», там содержатся и важные: «только для чтения», «каталог» и «метка тома». Атрибут «только для чтения» запрещает системе удалять файл или открывать его для записи. Атрибут «каталог» означает, что данная запись описывает не обычный файл, а каталог. Атрибут «метка тома» может содержаться только в корневом каталоге, такая запись не описывает никакой файл, а вместо этого содержит в полях имени и расширения 11-символьную метку (имя), присвоенную данному дисковому тому. В целом, запись каталога содержит почти все, что системе известно о файле, а если размер файла не превышает одного кластера, то полностью все. Если же файл содержит более одного кластера, то номера остальных можно найти в таблице FAT. Таблица FAT состоит из записей, количество которых равно количеству кластеров в области данных, а размер одной записи может быть равен 12, 16 или 32 битам. Соответственно говорят о разновидностях файловой системы FAT-12, FAT-16 или FAT-32. Размер записи должен быть таким, чтобы в ней можно было записать максимальный номер кластера. Например, для стандартной трехдюймовой дискеты емкостью 1.44 Мб достаточно использовать FAT-12, поскольку это позволяет иметь 212
= 4096 кластеров (на самом деле, чуть меньше), и даже при кластерах размером в 1 сектор (512 байт) этого более чем достаточно: 4096 ´ 512 = 2 Мб. Записи FAT «по историческим причинам» нумеруются, начиная с 2 и кончая максимальным номером кластера, каждая запись FAT описывает соответствующий кластер с тем же номером. Запись может принимать следующие значения: · если кластер принадлежит некоторому файлу (или каталогу) и является последним (или единственным) в этом файле, то запись FAT содержит специальное значение – все единицы (FFF16
для FAT-12 или FFFF16
для FAT-16); · если кластер принадлежит некоторому файлу (или каталогу), но не является последним в файле, то запись FAT содержит номер следующего кластера того же файла; · если кластер свободен, то запись содержит все нули; · если кластер дефектный (т.е. при проверке диска выяснилось, что данный кластер содержит хотя бы один дефектный сектор), то запись содержит специальное значение FF716
для FAT-12 или FFF716
для FAT-16. Теперь мы знаем, каким образом в системе FAT хранится информация о размещении сегментированного файла. Номер первого кластера файла хранится в записи каталога, а остальные кластеры можно последовательно определить по записям таблицы FAT. В каждом каталоге, кроме корневого, первые две записи содержат специальные имена: имя «.» означает сам данный каталог, имя «..» – родительский каталог. 3.6.3. Создание и удаление файла Чтобы завершить изучение структур данных системы FAT, рассмотрим, как изменяются эти структуры при операциях создания и удаления файла. Когда ОС выполняет функцию создания файла с заданным именем в заданном каталоге, то она, прежде всего, находит данный каталог в дереве каталогов файловой системы. (Как она его находит – опустим для краткости. Попробуйте разобраться сами.) Прочитав каталог, система проверяет, нет ли в нем уже записи с заданным именем (т.е. нет ли уже такого файла). Если есть, то не установлен ли у этого файла атрибут «только для чтения»? Если установлен, то новый файл создан быть не может, предварительно надо снять атрибут. Если не установлен, то старый файл удаляется. Затем система находит в каталоге свободную запись. Если в каталоге нет свободного места, то он может быть увеличен еще на один кластер, этот факт отражается в таблице FAT. Наконец, найдя свободное место, система заполняет поля записи о новом файле: его имя и расширение, дату и время последнего изменения, атрибуты. Размер и номер первого кластера устанавливаются нулевыми, т.к. файл пока что не содержит данных. В дальнейшем, при выполнении первой операции записи в файл, система найдет любой свободный кластер по таблице FAT, отметит его в FAT как последний кластер файла, заполнит номер первого кластера в каталожной записи, выполнит запись и занесет количество записанных байт в поле размера файла в каталоге. При удалении файла прежде всего по каталожной записи проверяется, можно ли его удалить (не установлен ли атрибут «только для чтения»), а затем делаются две вещи: · первый байт имени удаляемого файла заменяется на специальный символ с кодом E516
(он отображается как русская буква «х»; вероятно, разработчики системы FAT считали, что этот код не может встретиться в имени файла); · все записи таблицы FAT, соответствующие кластерам удаляемого файла, заполняются нулями, т.е. кластеры объявляются свободными. Как видно из описанной процедуры, в момент удаления файла его данные не стираются с диска, однако информация о размещении файла портится. Если размер файла превышал один кластер, то нет гарантии, что его удастся восстановить в случае нечаянного удаления, даже если пользователь спохватится сразу же. 3.6.4. Работа с файлами в MS-DOS Для работы с файлами и каталогами системы FAT в MS-DOS предусмотрен достаточно богатый набор функций. Все они вызываются с помощью команды программного прерывания int 21h, а конкретная функция определяется числом, занесенным в регистр AH. Эти функции позволяют, в частности: · создавать файл, указывая его полное имя; · удалять файл; · изменять атрибуты файла; · переименовывать файл или перемещать его в другой каталог того же диска[5]
; · искать в заданном каталоге все файлы, имена которых соответствуют заданному шаблону (например, шаблону «XYZ??.C*» соответствуют все файлы, имена которых начинаются с «XYZ» и содержат ровно 5 символов, а расширение начинается с буквы «C»); · создавать и удалять каталоги; · задавать текущий диск и текущий каталог; · открывать файл, получая доступ к его данным, и закрывать файл. В MS-DOS существует два различных набора функций, позволяющих работать с данными файлов. Один из них, основанный на использовании блока управления файлом (FCB), вряд ли кем-то использовался в последние 20 лет, однако сохраняется из соображений совместимости с версией MS-DOS 1.0. Общепринятый метод работы с файлами основан на использовании хэндлов[6]
. Чтобы открыть существующий файл, следует вызвать соответствующую функцию, указав в качестве параметров имя файла и желаемый режим доступа (один из трех: только чтение, только запись, чтение и запись). В более поздних версиях MS-DOS появилась также возможность указывать режим разделения, как рассмотрено в п.3.5. Любой файл рассматривается как последовательность байт, а если программа предпочитает рассматривать файл как набор записей, то она должна сама вести пересчет номера записи в смещение (в байтах) от начала файла. Операции чтения и записи всегда выполняются от текущей позиции, которая называется указателем чтения/записи, и приводят к смещению указателя вперед на прочитанное или записанное количество байт. Возможность произвольного доступа к данным обеспечивается операциями перемещения указателя. Хэндл
– это некоторое число, которое система возвращает пользовательской программе при удачном выполнении операции открытия или создания файла. Значение этого числа не играет роли для программы. Важно лишь то, что при последующих обращениях к открытому файлу программа должна передавать этот хэндл системе как указатель на этот файл. MS-DOS предоставляет вполне достаточный набор функций для работы с открытыми файлами. Сюда включаются функции чтения и записи произвольного числа байт, функция перемещения указателя в произвольную точку файла, функции установки и снятия блокировки фрагментов файла, принудительной очистки кэш-буферов файла (обычно очистка выполняется только при закрытии файла или при нехватке буферов, см. п.2.6.6; принудительная очистка гарантирует немедленное сохранение изменений на диске). При вызове функции открытия файла можно вместо имени файла указать имя любого символьного устройства, например, «PRN:». При этом также возвращается хэндл, с которым можно выполнять операции записи так же, как если бы этот хэндл указывал на дисковый файл. Разумеется, нельзя открыть принтер для чтения, а также нельзя выполнять перемещение указателя назад. При запуске любой программы она получает «в подарок» от MS-DOS пять уже открытых хэндлов с номерами от 0 до 4. Из них наиболее важными являются хэндл 0, который по определению указывает на стандартный ввод программы, и хэндл 1 – стандартный вывод. Хэндл 2 означает стандартное устройство для вывода сообщений об ошибках, хэндл 3 – стандартное устройство последовательного ввода/вывода (COM-порт), хэндл 4 – стандартный принтер. Выше, в п. 2.2, давалось иное определение стандартного ввода и вывода, как устройств, используемых «по умолчанию». Здесь нет противоречия. Компиляторы языков программирования, встречая вызовы процедур ввода/вывода без указания файла, транслируют их в вызовы системных функций MS-DOS с хэндлами, соответственно, 0 или 1. Если программа запускается из командной строки MS-DOS, то обычно хэндл 0 указывает на клавиатуру (точнее, на устройство CON:), а хэндл 1 – на экран монитора (тоже устройство CON:, но работающее на вывод). Однако пользователь может использовать символы перенаправления стандартного ввода (знак «<») и вывода (знаки «>» и «>>»). Например, программа, запущенная при помощи команды «MY_PROG <INFILE.TXT >PRN» будет использовать в качестве стандартного ввода файл INFILE.TXT, а стандартный вывод направит на принтер. Знак «>>» означает добавление данных в конец файла стандартного вывода, знак «>» – перезапись файла заново. Чтобы выполнить указанное пользователем перенаправление стандартного ввода или вывода, система открывает заданный файл или устройство (а при знаке «>>» еще и выполняет перемещение указателя в конец файла) и обеспечивает доступ к нему из запускаемой программы через стандартный хэндл 0 или 1. Таким образом, работающая программа вообще не знает, какие именно устройства или файлы являются ее стандартным вводом и выводом. Перенаправление стандартного ввода и вывода может быть выполнено и программой пользователя. Обычно это делается перед тем, как данная программа запускает какую-либо другую программу, передавая ей перенаправленные стандартные хэндлы. Для обеспечения доступа к открытым файлам MS-DOS использует системные таблицы двух типов. Таблица SFT (SystemFileTable) содержит записи о всех файлах, в данный момент открытых программами пользователя и самой ОС. Эта таблица хранится в системной памяти, число записей в ней определяется параметром FILES в файле конфигурации CONFIG.SYS, но не может превышать 255. Если один и тот же файл был открыт несколько раз (неважно, одной и той же программ ой или разными программами), то для него будет несколько записей в SFT. Каждая запись содержит подробную информацию о файле, достаточную для выполнения операций с ним. В частности, в записи SFT содержатся: · копия каталожной информации о файле; · адрес каталожной записи (сектор и номер записи в секторе); · текущее положение указателя чтения/записи; · номер последнего записанного или прочитанного кластера файла; · адрес в памяти программы, открывшей файл; · режим доступа, заданный при открытии. Кроме того, в записи SFT содержится значение счетчика ссылок на данную запись из всех таблиц JFT, речь о которых пойдет ниже. Когда этот счетчик становится равным нулю, запись SFT становится свободной, поскольку файл закрыт. В отличие от единственной SFT, таблицы JFT (JobFileTable) создаются для каждой запускаемой программы, поэтому одновременно может существовать несколько таких таблиц. (А откуда в однозадачной MS-DOS могут взяться одновременно несколько программ? Простейший ответ: когда одна программа запускает другую, то в памяти присутствуют обе. Подробнее см. п. 4.4.3.) Таблица JFT имеет простейшую структуру: она состоит из однобайтовых записей, причем значение каждой записи представляет собой индекс (номер записи) в таблице SFT. Неиспользуемые записи содержат значение FF16
. Размер таблицы по умолчанию составляет 20 записей (байт), но может быть увеличен до 255. Теперь о хэндлах. Прикладная программа использует хэндлы как некоторые условные номера открытых файлов, конкретное значение хэндла при этом не играет никакой роли (за понятным исключением стандартных хэндлов с 0 по 4). На самом же деле значение хэндла представляет собой не что иное, как индекс записи в таблице JFT данной программы. Первая запись таблицы соответствует хэндлу 0. На рис. 3‑3 показана связь между хэндлами, таблицами JFT, таблицей SFT и открытыми файлами/устройствами. Рис.
3‑3 В примере, показанном на рисунке, стандартные хэндлы процесса A используются так, как это по умолчанию делает MS-DOS: хэндлы 0, 1 и 2 указывают на запись SFT, соответствующую консольному устройству CON, хэндл 3 – на запись об устройстве COM1, хэндл 4 –на запись о принтере. У процесса B стандартный вывод перенаправлен на принтер, что отражено в значении элемента 1 из JFT этого процесса. Хэндлы 3 и 4 для процесса B не показаны, чтобы не захламлять рисунок. Остальные показанные на рисунке элементы JFT обоих процессов указывают на записи SFT, описывающие открытые файлы на дисках. Заметим, что с файлом PICTURE.BMP связаны две записи в таблице SFT. Это означает, что данный файл был открыт в каждом процессе отдельно (но, очевидно, с использованием одного из режимов разделения файла). Когда программа вызывает какую-либо из системных функций и передает ей значение хэндла одного из открытых файлов, то система находит адрес таблицы JFT вызвавшей программы, читает указанную хэндлом запись этой таблицы, определяет соответствующий индекс в таблице SFT и получает таким образом доступ к информации, необходимой для выполнения операции с файлом. В чем смысл такой двухступенчатой схемы? Не проще ли было, чтобы хэндл указывал непосредственно на запись SFT? Можно привести, по крайней мере, два очевидных аргумента в пользу применения JFT. · Что происходит с файлами при завершении программы, которая их открыла? Правила хорошего программистского тона требуют, чтобы программа перед окончанием работы закрыла за собой все файлы. Однако программист может и не выполнить это требование, или программа может завершиться аварийно. В любом случае ОС должна при завершении программы закрыть все ее файлы. Как ОС узнает, какие файлы следует закрыть? Ответ очень простой: достаточно просмотреть таблицу JFT завершаемой программы и найти там все записи, отличные от FF16
. · Использование JFT дает возможность отделить логическое понятие стандартного устройства (в частности, стандартный ввод – хэндл 0 и стандартный вывод – хэндл 1) от конкретных устройств. Перенаправление стандартных устройств выполняется путем изменения значений соответствующих элементов JFT. 3.6.5. Новые версии системы FAT Структуры данных файловой системы являются одной из наиболее консервативных, плохо поддающихся изменениям характеристик ОС. Проблема заключается в том, что при изменениях структур данных трудно сохранить совместимость с более ранними версиями. Было бы катастрофой, если бы все множество накопленных в мире файлов в системе FAT вдруг перестало читаться в новой версии системы. Тем не менее, некоторые интересные изменения все же удалось ввести при выпуске версий Windows 95 и 98. В Windows 95 было преодолено досадное ограничение длины имени файла – знаменитое правило «8 + 3». Казалось бы, при размере записи каталога в 32 байта трудно надеяться на длинные имена файлов. Тем не менее, было найдено забавное решение этой проблемы. Разработчики из Microsoft обратили внимание, что те записи каталога, в которых встречается бессмысленная комбинация битовых атрибутов «скрытый + системный + только чтение + метка тома», просто-напросто игнорируются как системными программами MS-DOS, так и распространенными утилитами других разработчиков. Это дало возможность использовать записи с такой комбинацией для хранения длинного имени файла. По-прежнему для каждого файла в каталоге имеется основная запись в обычном, старом формате, содержащая атрибуты файла, номер первого кластера и обязательное «короткое» имя. Однако если пользователь при создании файла указывает имя, не укладывающееся в стандарт «8 + 3» или содержащее строчные буквы, то перед основной записью будет вставлено нужное количество дополнительных записей с разбитым на кусочки «длинным именем» в кодировке UNICODE (по 2 байта на символ, что позволяет использовать любой известный алфавит). Длина имени, согласно документации, может достигать 255 символов (на самом деле, чуть меньше). Начиная с Windows 98, появилась возможность использовать новую разновидность файловой системы – FAT-32. Ее отличие от FAT-12 и FAT-16 заключается не только в большей разрядности номера кластера (хотя и это очень важно для больших дисков), но и в том, что Microsoft наконец-то решилась использовать 10-байтовый резерв, который неизвестно для каких целей сохранялся незанятым в каждой записи каталога. Благодаря этому появилась возможность добавить к дате/времени последней модификации файла еще два временных штампа: дату/время создания (на самом деле, это дата/время последнего изменения каталожной записи) и дату последнего доступа к файлу. 3.7.1. Архитектура файловой системы UNIX Здесь рассматривается классическая файловая система UNIX, называемая иногда системой s5fs
и поддерживаемая всеми версиями UNIX. Современные усовершенствования файловой системы будут рассмотрены в п. 3.7.4. Структуру каталогов файловой системы UNIX называют иногда сетевой, чтобы подчеркнуть ее отличие от строго иерархической (древесной) структуры каталогов таких систем, как, например, FAT. Отличие это заключается в понятиях жестких и символических связей
файла. Жесткая связь означает связь между именем файла и самим файлом. Особенность UNIX в том, что любой файл может иметь несколько (точнее, неограниченное количество) жестких связей, т.е. неограниченное количество имен. Это могут быть разные имена в одном каталоге или даже имена, хранящиеся в разных каталогах одного дискового тома. Есть ли какая-нибудь польза от нескольких имен одного файла? Безусловно, есть. Предположим, пользователь часто использует какую-либо системную программу или файл данных, лежащий где-то глубоко в одной из ветвей дерева каталогов. Вместо того, чтобы каждый раз указывать длинный путь к нужному файлу, пользователь может просто создать новую жесткую связь, т.е. дать файлу удобное имя и поместить это имя в свой личный каталог. UNIX предоставляет для этого команду link, которая создает новое имя для указанного файла. Что произойдет, если один из пользователей удалит имя файла из каталога? Произойдет только обрыв одной из жестких связей. Пока у данного файла остаются другие имена, файл продолжает существовать. Только после того, как удалены все имена файла, система понимает, что файл перестал быть доступен кому-либо, и удаляет сам файл. Все жесткие связи (имена) одного файла абсолютно равноправны, среди них нельзя выделить какое-то «основное» имя. Несколько иным образом работает символическая связь. Такая связь представляет собой файл, который содержит только полное имя другого файла. Важно при этом то, что файл помечен в системе именно как символическая связь, а не просто текстовый файл, случайно хранящий имя файла. Когда файл символической связи используется как аргумент системной команды или функции, UNIX автоматически подставляет вместо него тот файл, на который указывает связь. Можно кратко сказать, что жесткая связь указывает на сам файл, а символическая – на имя файла. Оба типа связей проиллюстрированы на рис. 3‑4. Рис.
3‑4 В примере на рисунке показан файл данных, для которого имеются три жесткие связи, т.е. три имени в каталогах системы, обозначенные как «Имя 1», «Имя 2» и «Имя 3». Кроме того, в системе имеется файл типа «символическая связь», который содержит одно из имен файла данных. Файл символической связи, как и любой другой файл, доступен по имени и в данном случае имеет два имени (две жестких связи): «Имя 4» и «Имя 5». Таким образом, использование любого из пяти имен в качестве, например, имени открываемого файла приведет к открытию одного и того же файла. Предположим, администратор системы решил заменить некоторый файл его более свежей версией, оставив то же самое имя файла. Если некоторые пользователи хранили жесткие связи на прежнюю версию, то они так и будут ею пользоваться, пока явно не удалят ее имя и не создадут связи на новую версию. Если же пользователь хранил символическую связь, то она теперь будет указывать на новую версию. В Windows используется некоторый аналог понятия символической связи – ярлык файла (shortcut). Отличие в том, что с точки зрения файловой системы Windows ярлык не является каким-то особым типом файла, это обычный текстовый файл с расширением LNK. Ярлык распознается не файловой системой, а такими программами, как Проводник (Explorer). В UNIX нет понятия «буква диска», подобно буквам A:, C: и т.д., используемым в MS-DOS и в Windows. В системе может быть несколько дисковых томов, но, прежде чем получить доступ к файловой системе любого диска, кроме основного, пользователь должен выполнить операцию монтирования диска
. Она заключается в том, что данный диск отображается на какой-либо из каталогов основного тома. Как правило, для этого используются пустые подкаталоги каталога /mount или /mnt. Если представить файловую систему на дисковом томе в виде дерева, то монтирование тома – это как бы «прививка» одного дерева к какому-либо месту на другом, основном дереве. В отличие от этого, MS-DOS и Windows допускают использование нескольких отдельных деревьев. Для каждого файла в UNIX хранится его тип, который при выдаче каталога обозначается одним из следующих символов: Особенностью UNIX является то, что работа с разными типами объектов, перечисленными выше (файлами, устройствами, каналами, сокетами) организуется с использованием одного и того же набора функций файлового ввода/вывода. К числу атрибутов, описывающих файл, относятся его размер в байтах, число жестких связей и три «временных штампа»: дата/время последнего доступа к файлу, последней модификации файла, последней модификации атрибутов файла. Эту последнюю величину часто называют неточно «датой создания файла». Для специальных файлов вместо размера хранятся старший и младший номера устройства, см. п. 2.10.1. Кроме того, для каждого файла хранятся атрибуты управления доступом, описанные в следующем пункте, а также информация о размещении файла на диске, описанная в п. 3.7.2. Для каждого файла (в том числе каталога, специального файла) определены такие понятия, как владелец
(один из пользователей системы) и группа-владелец
. Их числовые идентификаторы (называемые, соответственно, UID и GID) хранятся вместе с другими атрибутами файла. Полные имена, пароли и другие характеристики пользователей и групп хранятся в отдельном системном файле. Владельцем файла обычно является тот пользователь, который создал этот файл. Кроме того, для файла задаются атрибуты защиты
, хранящиеся в виде 9 бит, которые определяют допустимость трех основных видов доступа – на чтение, на запись и на исполнение – для владельца, для членов группы-владельца и для прочих пользователей. При отображении каталога с помощью команды ls –l эти атрибуты показываются в виде 9 букв или прочерков, например: r w x r – x - - x В приведенном примере показано, что сам владелец файла имеет все права (r – чтение, w – запись, x – исполнение), члены группы-владельца могут читать файл и запускать на исполнение (если этот файл содержит программу), всем прочим разрешено только исполнение. Привилегированный пользователь (администратор системы) всегда имеет полный доступ ко всем файлам. В том случае, если файл является каталогом, права доступа на чтение и на исполнение понимаются несколько иначе. Право на чтение каталога позволяет получить имена файлов, хранящиеся в данном каталоге. Право на исполнение каталога означает возможность читать атрибуты файлов каталога, использовать эти файлы, а также право сделать данный каталог текущим. Возможны интересные ситуации: если текущий пользователь не имеет права на чтение каталога, но имеет право на его «исполнение», то он не может узнать имена файлов, хранящихся в каталоге; однако, если он все же каким-то образом узнал имя одного из файлов, то может открыть этот файл или запустить на исполнение (если этому не препятствуют атрибуты доступа самого файла). Чтобы удалить файл, не нужно иметь никаких прав доступа к самому файлу, но необходимо право на запись в соответствующий каталог (потому что удаление файла есть изменение не файла, а каталога). Впрочем, в современных версиях UNIX добавлен еще один битовый атрибут, при установке которого удаление разрешено только владельцу файла или пользователю, имеющему право записи в файл. Изменение атрибутов защиты, а также смена владельца файла, могут быть выполнены только самим владельцем либо привилегированным пользователем. Еще два битовых атрибута, имеющих отношение к защите данных, называются SUID и SGID. Они определяют, какие права (а точнее сказать, чьи идентификаторы владельца и группы) унаследует при запуске программа, хранящаяся в данном файле. Оба бита по умолчанию сброшены, при этом программа использует идентификаторы UID и GID того пользователя, который ее запустил. Программа как бы «действует от имени этого пользователя», и использует его права доступа к файлам. Если же для установлены атрибуты SUID и/или SGID, то запущенная программа будет использовать идентификаторы UID и/или GID своего владельца. Для чего такие тонкости? Представим себе, что пользователь хочет сменить свой пароль. С одной стороны – нормальное желание, которое следует удовлетворить. С другой стороны, пароль данного пользователя хранится в одном файле с паролями других пользователей, и доступ к этому файлу должен быть, очевидно, закрыт для всех рядовых пользователей. Можно подобрать и другие примеры ситуаций, когда обычному пользователю необходим ограниченный доступ к данным, которые система должна защищать. Решение, которое предлагает UNIX, заключается в следующем. Для работы с паролями имеется специальная программа, владельцем которой является администратор системы. Программа доступна для исполнения всем пользователям, но у нее установлен бит SUID. В результате этого запущенная программа работает от имени администратора, т.е. получает неограниченный доступ к файлам. Таким образом, ответственность за защиту системных данных перекладывается на работающую программу. Следует отметить, что в UNIX нет особых средств защиты для периферийных устройств. Как было описано выше, устройства (а также именованные каналы и сокеты) считаются особыми типами файлов, поэтому для них определены те же атрибуты защиты, что и для файлов. 3.7.2. Структуры данных файловой системы
UNIX Дисковый том UNIX состоит из следующих основных областей, показанных (не в масштабе) на рис. 3‑5: Рис.
3‑5 · блок начальной загрузки (BOOT-сектор); его структура определяется не UNIX, а архитектурой используемого компьютера; · суперблок – содержит основные сведения о дисковом томе в целом (размер логического блока и количество блоков, размеры основных областей, тип файловой системы, возможные режимы доступа), а также данные о свободном месте на диске; · массив индексных дескрипторов, каждый из которых содержит полные сведения об одном из файлов, хранящихся на диске (кроме имени этого файла); · область данных, состоящая из логических блоков (кластеров), которые используются для хранения файлов и каталогов (в UNIX используется сегментированное размещение файлов). В отличие от системы FAT, где основные сведения о файле содержались в каталожной записи, UNIX использует более изощренную схему. Запись каталога не содержит никаких данных о файле, кроме только имени файла и номера индексного дескриптора этого файла. В ранних версиях UNIX каждая запись имела фиксированную длину 16 байт, из которых 14 использовались для имени и 2 для номера. В более современных версиях запись имеет переменный размер, что позволяет использовать длинные имена файлов. Как и в системе FAT, в каждом каталоге первые две записи содержат специальные имена «..» (ссылка на родительский каталог) и «.» (ссылка на данный каталог). Точнее, это в FAT сделано по примеру UNIX. Нулевое значение номера соответствует удаленной записи каталога. Все сведения о файле, кроме имени, содержатся в его индексном дескрипторе
(inode
). Такая схема делает возможными жесткие связи, описанные выше: любое количество записей из одного каталога или из разных каталогов может относиться к одному и тому же файлу. Для этого надо только, чтобы эти записи содержали один и тот же номер inode. Индексные дескрипторы хранятся в массиве, занимающем отдельную область диска. Размер этого массива задается при форматировании, этот размер определяет максимальное количество файлов, которое можно разместить на данном томе. Дескриптор содержит, прежде всего, счетчик жестких связей файла, т.е. число каталожных записей, ссылающихся на данный дескриптор. Этот счетчик изменяется при создании и удалении связей, его нулевое значение говорит о том, что файл перестал быть доступным и должен быть удален. В дескрипторе содержатся тип и атрибуты файла, описанные выше. Наконец, здесь же содержатся данные о размещении файла, имеющие весьма оригинальную структуру (см. рис. 3‑6). Рис.
3‑6 Размещение блоков файла задается массивом из 13 (в некоторых версиях 14) элементов, каждый из которых может содержать номер блока в области данных. Пусть, для определенности, блок равен 1 Кб, а его номер занимает 4 байта (обе эти величины зависят от версии файловой системы). Первые 10 элементов массива содержат номера первых 10 блоков от начала файла. Если размер файла превышает 10 Кб, то в ход идет 11-й элемент массива. Он содержит номер косвенного блока
– такого блока в области данных, который содержит номера следующих 256 блоков файла. Таким образом, использование косвенного блока позволяет работать с файлами размером до 266 Кб, используя для этого один дополнительный блок. Если файл превышает 266 Кб, то в 12-ом элементе массива содержится номер вторичного
косвенного блока
, который содержит до 256 номеров косвенных блоков, каждый из которых… Ну, вы поняли. Наконец, для очень больших файлов будет задействован 13-й элемент массива, содержащий номер третичного косвенного блока
, указывающего на 256 вторичных косвенных. Подсчитайте, какой максимальный размер файла может быть достигнут при такой схеме адресации блоков. Недостатком описанной схемы является то, что доступ к большим файлам требует значительно больше времени, чем к маленьким. Если расположение первых 10 Кб данных файла записано непосредственно в индексном дескрипторе, то для того, чтобы прочитать данные, отстоящие, скажем, на 50 Мб от начала файла, придется сперва прочитать третичный, вторичный и обычный косвенные блоки. Еще один важный вопрос для любой файловой системы – способ хранения данных о свободном месте. Для UNIX следует различать два вида свободных мест – свободные блоки в области данных и свободные индексные дескрипторы, которые бывают нужны при создании новых файлов. Количество тех и других может быть очень большим. В суперблоке UNIX имеются массивы для хранения некоторого количества номеров свободных блоков и свободных дескрипторов. Если исчерпаны номера свободных дескрипторов в суперблоке, то UNIX просматривает массив дескрипторов, находит в нем свободные и выписывает их номера в суперблок. Сложнее обстоит дело со свободными блоками данных. Первый элемент размещенного в суперблоке массива номеров свободных блоков указывает на блок в области данных, который содержит продолжение этого массива и, в первом элементе, указатель на следующий блок продолжения. Когда системе нужны блоки дисковой памяти, она берет их из основного массива в суперблоке, а при исчерпании массива читает его продолжение в суперблок. При освобождении блоков происходит обратный процесс: их номера записываются в массив, а при переполнении массива все его содержимое переписывается в один из свободных блоков, номер которого заносится в первый элемент массива как адрес продолжения списка. На рис. 3‑7 показана структура списка свободных блоков. Рис.
3‑7 Как нетрудно понять, из сказанного вытекает, что блоки диска распределяются «по стековому принципу»: блок, освобожденный последним, будет первым снова задействован. 3.7.3. Доступ к данным в UNIX UNIX предоставляет в распоряжение прикладных программ набор системных вызовов, позволяющих выполнять основные операции с файлами и каталогами в целом (создание, удаление, поиск, изменение владельца и прав доступа), а также с данными, хранящимися в файлах (открытие и закрытие файла, чтение и запись данных, перемещение указателя в файле). В основе работы с данными, как и для MS-DOS, лежит понятие хэндла открытого файла. Программа получает значение хэндла при открытии или создании файла, а затем использует хэндл для ссылки на открытый файл при обращении к функциям чтения, записи, перемещения указателя и т.п. UNIX не имеет средств управления разделением доступа при открытии файла, т.е. всегда позволяет нескольким процессам открывать один и тот же файл. Для обеспечения корректной работы процессы могут использовать блокирование фрагментов файла. Можно установить блокировку для записи (эксклюзивную блокировку, см. п. 3.5) или для чтения (кооперативную блокировку). По умолчанию в UNIX используются рекомендательные
блокировки. Это означает, что система не препятствует процессу обращаться к заблокированному фрагменту файла. Процесс должен сам запрашивать (если считает нужным), не заблокирован ли данный фрагмент. В более поздних версиях UNIX стало возможным и обязательное
блокирование, при котором попытка обращения к заблокированному фрагменту приводит к ошибке. Для реализации доступа к файлу по значению хэндла в UNIX используются таблицы, аналогичные таблицам JFT и SFT в MS-DOS (см. п. 3.6.4.3). Однако, в отличие от MS-DOS, запись SFT не содержит копии всех атрибутов файла. Вместо этого UNIX хранит в памяти отдельную таблицу копий индексных дескрипторов (inode) всех открытых файлов. Запись SFT содержит ссылку на запись таблицы индексных дескрипторов, а сверх того – те параметры, которых нет в inode: режим доступа к открытому файлу, положение указателя в файле, количество хэндлов, указывающих на данную запись SFT. Если один и тот же файл был открыт несколько раз, то создается несколько записей SFT, указывающих на один и тот же inode. 3.7.4. Развитие файловых систем
UNIX Описанная выше классическая файловая система UNIX является по-своему весьма стройной и мощной, способной удовлетворить разнообразные требования пользователей. В то же время эта система давно уже подвергалась критике за два существенных недостатка, определяемых выбором описанных выше структур данных. Эти недостатки следующие: · ненадежность; · низкая производительность. Поговорим сначала о ненадежности. Можно назвать следующие опасные места в структуре файловой системы UNIX. · Широкое использование сцепленных списковых структур для хранения жизненно важной информации о размещении файлов и свободных блоков. Программистам известен основной недостаток сцепленных списков: при минимальном искажении хотя бы одного из указателей теряется, в лучшем случае, вся последующая часть списка. Возможна и потеря данных, не входящих в поврежденный список. Попробуйте представить себе, что произойдет на диске, если в качестве номера косвенного блока вследствие аппаратного сбоя будет записан номер ни в чем не повинного блока данных из совсем другого файла… · Интенсивное использование суперблока для хранения часто изменяющейся информации. Поскольку каждая операция записи связана с возможностью искажения данных, под угрозой оказываются жизненно важные параметры файловой системы, которые тоже хранятся в суперблоке, но не требуют частых изменений: размеры всей файловой системы и ее частей, размер блока и т.п. · Компактное размещение в начале дискового тома наиболее важных метаданных (суперблок, массив дескрипторов) приводит к тому, что при механическом повреждении начальных дорожек диска теряется возможность доступа ко всем данным на диске. Давно известны и факторы, влияющие на снижение производительности работы: · использование косвенных блоков приводит к тому, что для поиска нужного места в большом файле могут потребоваться дополнительные операции чтения с диска. · используемые алгоритмы выделения и освобождения дисковых блоков по принципу «последним освободился – первым занят» способствуют фрагментации дискового пространства, а это, как нам известно, приводит к снижению скорости доступа. Неудивительно, что в качестве замены системы s5fs были предложены различные более надежные и производительные файловые системы. К их числу относятся, например, система FFS, используемая в версии UNIX 4BSD, а также система ext2, поставляемая с Linux. Все эти системы поддерживают привычную архитектуру UNIX, включая структуру каталогов, жесткие и символические связи, типы файлов, набор атрибутов. Различия заключаются в реализующих эту архитектуру структурах дисковых данных и в алгоритмах работы с ними. Постараемся дать общее представление о направлениях усовершенствования файловых систем UNIX, не вдаваясь в детали конкретных систем. · Дисковый том разбивается на несколько групп цилиндров. Каждая группа содержит копию общего суперблока, а также отдельный массив дескрипторов и блоки данных. В случае повреждения основного экземпляра суперблока его содержимое может быть восстановлено по сохранившейся копии. Повреждение метаданных в одной из групп цилиндров не ведет к потере информации в остальных группах. · Данные о количестве и местонахождении свободных блоков вынесены из суперблока и хранятся отдельно в каждой группе цилиндров. · Для хранения данных о свободных блоках используется не списковая структура, а битовая карта, в которой каждый блок из группы цилиндров помечается как свободный или занятый. Это уменьшает тяжесть последствий в случае повреждения данных. · Алгоритм размещения файлов старается по возможности размещать все файлы одного каталога, а также их дескрипторы, в пределах одной группы цилиндров. Напротив, подкаталоги по возможности не размещаются в той же группе цилиндров, что родительский каталог. Таким способом обычно удается уменьшить количество перемещений головок при работе программы с файлами. Нужно отметить, что в современных версиях UNIX, как и в других современных ОС, поддерживается одновременное использование разных файловых систем на разных дисковых томах. Этой цели служит понятие виртуальной файловой системы
(VFS). Она позволяет подключать к единому дереву каталогов файловые системы различных типов, в том числе такие чужеродные для UNIX, как FAT или NTFS. Для работы с файлами используется единый набор файловых функций, однако при их вызове, в зависимости от того, к какой файловой системе принадлежит данный файл, будут вызываться различные подпрограммы. 3.8.1. Особенности файловой системы NTFS Файловая система NTFS была разработана специально для использования в ОС WindowsNT как замена для устаревшей системы FAT. NTFS является основной системой и для новых версий – Windows 2000/XP. Система NTFS спроектирована как очень мощная многопользовательская файловая система с большим количеством возможностей. Тем не менее, как утверждают разработчики, NTFS обеспечивает более быстрый доступ к данным, чем предельно простая система FAT, если объем диска превышает 600 Мб. Среди возможностей, отсутствующих в FAT, но реализованных в NTFS, можно назвать следующие. · Развитые средства защиты данных, предотвращающие возможность несанкционированного доступа к данным и при этом позволяющие весьма детально разграничить права доступа для различных пользователей и групп пользователей. · Быстрый поиск файлов в больших каталогах. · Обеспечение целостности данных в случае сбоев или отключения питания, основанное на механизме транзакций. Это означает, что любая операция с файлом рассматривается как неделимое действие (транзакция), которое должно быть либо выполнено до конца, либо не выполнено вовсе. В ходе операции система протоколирует в специальном журнале ход выполнения отдельных этапов транзакции: запись данных, внесение изменений в каталог и т.п. Если транзакция будет прервана на промежуточном этапе, то при следующей загрузке системы информация из журнала позволит «откатить» недовыполненную транзакцию, т.е. отменить выполненные этапы. · Возможность сжатия данных на уровне отдельных файлов (т.е. на одном дисковом томе могут храниться файлы как в сжатом, так и в несжатом формате). · Возможность хранения файлов в зашифрованном виде. · Механизм точек повторного анализа (reparsepoints), позволяющий для отдельных каталогов задать действия, которые должны выполняться всякий раз, когда система обращается к данному каталогу. В частности, этот механизм позволяет реализовать такие UNIX-подобные возможности, как символические связи и монтирование файловых систем. · Возможность протоколирования всех изменений, происходящих в файловой системе, таких как создание, изменение и удаление файлов и каталогов. · Расширяемость системы. Учтя трудный опыт, связанный с попытками модернизации FAT, разработчики NTFS заранее заложили в систему возможность добавления новых, не предусмотренных в настоящее время атрибутов файлов. Некоторые возможности, заложенные в файловую систему NTFS, даже опережают развитие ОС Windows и пока не могут быть использованы в этой системе. 3.8.2. Структуры дисковых данных Общую структуру хранения данных на диске в системе NTFS часто характеризуют двумя короткими фразами: На диске нет ничего, кроме файлов. В файле нет ничего, кроме атрибутов. Поговорим подробнее об этих загадочных утверждениях. Наиболее важной частью файловой системы на диске является главная таблица файлов
(MFT, MasterFileTable). Эта таблица содержит записи обо всех файлах и каталогах, расположенных на данном томе. Размер записи составляет один кластер, но не менее 1 Кб. Если метаданные о файле не помещаются в одной записи, то могут быть использованы дополнительные записи (не обязательно соседние). После форматирования дискового тома, когда на нем еще нет пользовательских файлов, MFT содержит 16 записей, из которых 11 содержат описания файлов метаданных, а 5 зарезервированы как дополнительные. Список файлов метаданных достаточно интересен. · Первая запись MFT описывает саму MFT, которая тоже считается файлом. Это отнюдь не формальность, поскольку MFT может, как и прочие файлы, состоять из нескольких сегментов, размещение которых задается в этой записи. · Копия первых 16 записей MFT, которая хранится как файл где-нибудь в середине диска. Это позволяет восстановить метаданные в случае повреждения основного экземпляра MFT. · Журнал протоколирования транзакций. · Файл информации о томе: имя тома, серийный номер, дата форматирования и т.п. · Файл с перечислением всех атрибутов, используемых для описания файлов на данном томе. Таким образом, список атрибутов не является жестко фиксированным и может быть расширен в последующих версиях NTFS. · Корневой каталог тома. · Битовая карта занятости кластеров тома. · BOOT-сектор. Он по-прежнему является первым сектором тома, но тоже считается файлом. · Файл, состоящий из всех дефектных кластеров на данном томе. Это дает основания пометить в битовой карте все дефектные кластеры как занятые. · Файл, содержащий все различные дескрипторы защиты, используемые для файлов и каталогов данного тома (см. п. 3.8.4.2). · Файл, задающий пары прописных / строчных букв для всех языков, поддерживаемых Windows. Такие данные необходимы, поскольку имена файлов могут содержать буквы обоих типов, но в Windows по традиции регистр букв в именах файлов не различается (в отличие, например, от UNIX). · Каталог, содержащий еще 4 файла метаданных, добавленных в Windows 2000. К ним относятся: - файл уникальных 16-байтовых идентификаторов, создаваемых Windows для каждого файла, на который имеется ярлык или OLE-связь; это позволяет автоматически исправить ярлык, если исходный файл был перемещен в другой каталог или даже на другой компьютер в пределах домена сети; - файл квот дискового пространства, выделяемых каждому пользователю; - файл точек повторного анализа, установленных для каталогов данного тома; - файл журнала изменений, происходящих на томе. Далее, начиная с 17-й позиции MFT, хранятся записи метаданных о файлах и каталогах, размещенных на данном томе. Система пытается сохранить MFT непрерывной, поскольку это ускоряет обращение ко всем описанным в ней файлам. Для этого система старается по возможности не занимать некоторую область в начале диска под размещение файлов, сохраняя свободное место для роста MFT. Каждая запись MFT содержит набор атрибутов, который может различаться для разных файлов и каталогов. Атрибут в NTFS состоит из заголовка и значения, а заголовок, в свою очередь, содержит тип атрибута, его имя, длину и данные о размещении атрибута. Имя атрибута может отсутствовать, остальные поля обязательны. Заголовок атрибута всегда хранится в самой записи MFT, а значение – либо тоже в самой записи (при этом атрибут называется резидентным
), либо в кластере области данных (нерезидентный
атрибут). Некоторые типы атрибутов обязаны быть резидентными, для других типов выбор размещения зависит от наличия достаточного свободного места в записи MFT. Если атрибут нерезидентный, то в заголовке указываются сведения о размещении его значения на диске. Рассмотрим наиболее важные типы атрибутов, используемых в записи о файле. · Имя файла
. Этот атрибут всегда резидентен. Допускается несколько атрибутов этого типа, например, «длинное» имя (до 255 символов, включая буквы любого языка) и имя «8 + 3» для того же файла. · Стандартная информация
. Это примерно та информация о файле, которая хранилась в записи каталога FAT: размер файла, временные штампы и битовые флаги. · Дескриптор защиты
. Он служит для задания прав доступа к данному файлу для различных пользователей и групп, подробнее см. п. 3.8.4.2. В новых версиях NTFS запись MFT содержит не сам дескриптор, а ссылку на его место в системном файле. Так получается компактнее, поскольку обычно на диске имеется много файлов с одинаковыми дескрипторами защиты и лучше хранить каждый дескриптор один раз, в специально отведенном для этого файле метаданных. · Данные
. Это самое неожиданное при первом знакомстве с NTFS: сами данные файла рассматриваются как один из типов атрибутов этого файла. Следующая неожиданность состоит в том, что атрибут данных небольшого файла может храниться резидентно в составе записи MFT. Напомним, что размер этой записи – от 1 Кб и больше, так что место для данных маленького файла может найтись. Безусловно, резидентное хранение данных позволяет ускорить доступ к ним, поскольку запись MFT так или иначе всегда читается при открытии файла. Еще одна интересная особенность NTFS заключается в том, что один файл может иметь несколько атрибутов данных, определяющих несколько потоков данных
(streams). Один из потоков безымянный, остальные должны иметь имена. Получается как бы целый каталог файлов внутри одного файла. Безусловно, для этой возможности можно придумать интересные применения, однако ни в одной версии Windows, включая XP, пока не предусмотрены API-функции, работающие с потоками данных. Если запись MFT описывает не файл, а каталог, то вместо атрибута данных в ней содержится другой атрибут, содержащий либо весь каталог, либо его часть. Если каталог слишком велик, то другие его части хранятся в нерезидентных атрибутах еще одного типа. Здесь мы не будем рассматривать этот вопрос детально, однако следует отметить, что атрибуты, описывающие большой каталог, образуют структуру данных, известную как Б-дерево (B-tree). Эта структура позволяет ускорить поиск файла в каталоге. Запись каталога содержит лишь имя файла, номер записи об этом файле в MFT и копию атрибута «стандартная информация». Эта копия позволяет отображать содержимое каталога без чтения записей MFT о каждом файле. При сравнении структуры NTFS с ранее рассмотренной структурой s5fs можно найти некоторую аналогию между таблицей MFT и массивом индексных дескрипторов, содержащих всю информацию о файле в s5fs. При этом NTFS имеет значительно более сложную структуру и предоставляет много дополнительных возможностей. 3.8.3. Доступ к данным Windows предоставляет прикладным программам API-функцию CreateFile, которая может использоваться как для создания нового файла, так и для открытия существующего. В любом случае эта функция создает в системной памяти объект типа «открытый файл», именно потому название функции начинается со слова «Create». Функция CreateFile может использоваться для работы с файлами любой файловой системы, поддерживаемой Windows (в частности, FAT и NTFS). Параметры этой функции многочисленны и дают достаточно хорошее представление о возможностях работы с файлами в Windows. Некоторые параметры имеют смысл только для NTFS (но не для FAT) или только для WindowsNT (но не для Windows 95). Список параметров включает в себя следующие параметры. · Имя файла (включая путь к каталогу, если файл расположен не в текущем каталоге). Вместо имени файла может также быть указано специальное имя устройства, в том числе даже имя физического или логического диска. · Режим доступа. Может быть указан доступ для чтения, для записи или их комбинация. · Режим разделения. Он может включать в себя разрешение другим процессам читать файл, записывать данные в файл, удалять файл или любую комбинацию этих разрешений, в том числе, разумеется, и отсутствие всех разрешений. · Атрибуты защиты. Их использование будет описано в п. 3.8.4.2. · Режим создания. Определяет действия функции в случаях, когда файл с заданным именем уже существует и когда не существует. Определены следующие режимы. - CREATE_NEW – Создается новый файл. Если файл уже существует, выдается ошибка. - CREATE_ALWAYS – Создается новый файл в любом случае, даже если файл с таким именем уже существует. - OPEN_EXISTING – Открывается существующий файл. Выдает ошибку, если файл не существует. - OPEN_ALWAYS – Если файл существует, то он открывается, если не существует – создается новый файл. - TRUNCATE_EXISTING – Открывается существующий файл, но все его содержимое удаляется. Если файл не существует, выдается ошибка. · Большой набор атрибутов и флагов, который следует рассмотреть подробнее. В данном случае атрибутами называются признаки файла, которые устанавливаются при его создании, а флагами – признаки, уточняющие режим работы с открытым файлом. К атрибутам файла относятся все те, которые Windows унаследовала от MS-DOS (только для чтения, скрытый, системный, архивный), а также атрибут «сжатый» (т.е. файл, создаваемый в NTFS, будет храниться в сжатом виде) и атрибут «временный». Этот атрибут означает, что файл, вероятно, будет скоро удален, а поэтому система должна попытаться удержать его данные в памяти, не тратя зря время на запись файла на диск. Флаги функции предоставляют, в частности, следующие возможности: · при операциях записи немедленно выполнять запись на диск (очищать кэш-буфера файла); · вообще исключить использование кэша для данного файла, всегда записывать и читать секторы данных непосредственно с диска; · указать системе желательность оптимальной буферизации для последовательного доступа или, наоборот, для произвольного доступа; · открыть файл для выполнения асинхронных операций; · указать системе, что файл должен быть автоматически удален сразу же, как только он будет закрыт. Функция
CreateFile возвращает хэндл открытого файла. Этот хэндл может затем использоваться при обращении к функциям чтения, записи, перемещения указателя, очистки буферов, блокирования фрагментов, закрытия фала и др. Чтение и запись данных при синхронных операциях начинается с текущей позиции указателя и сопровождается смещением указателя чтения/записи вперед на количество прочитанных/записанных байт. Однако если при открытии файла был указан флаг асинхронных операций, то указатель не используется. Вместо этого при каждом вызове функции чтения или записи должен задаваться дополнительный параметр – смещение от начала файла тех данных, которые следует прочитать или записать. Как вы думаете, почему при асинхронных операциях не используется указатель чтения/записи? Процесс, запустивший асинхронную операцию чтения/записи, может затем проверить ее результат с помощью вызова системной функции, которая, в зависимости от параметров, либо ожидает завершения операции, либо просто проверяет, завершилась ли она. Кроме того, есть возможность связать с завершением асинхронной операции либо событие (event), либо функцию завершения, которая будет вызвана, если операция завершена, а нить процесса, начавшая операцию, вызвала функцию ожидания (см. пп.4.5.5.2, 4.5.5.3 о событиях и функциях ожидания). Некоторые файловые функции не требуют хэндла, т.е. выполняются над закрытыми файлами. Сюда относятся удаление файла, копирование, переименование, перемещение файла, поиск файла по заданному пути и шаблону имени и т.п. В качестве интересных особенностей файловых операций Windows можно отметить следующие. · Операции копирования файла или перемещения его на другой диск можно выполнить вызовом одной системной функции, даже не открывая файл. В других ОС подобные операции требуют написания целой процедуры. · Специально для замены версий системных программ предусмотрен вариант переименования/перемещения файла с откладыванием фактического выполнения до перезагрузки системы. Иным способом невозможно было бы, например, установить новые версии системных библиотек, поскольку существующие версии постоянно открыты и потому не могут быть удалены иначе как при старте системы. 3.8.4. Защита данных Средства безопасности в WindowsNT/2000/XP представляют собой отдельную подсистему, которая обеспечивает защиту не только файлов, но и других типов системных объектов. Файлы и каталоги NTFS представляют собой наиболее типичные примеры защищаемых объектов. Как известно, Windows позволяет использовать различные файловые системы, при этом возможности защиты данных определяются архитектурой конкретной файловой системы. Например, если на дисковом томе используется система FAT (где, как нам известно, никаких средств защиты не предусмотрено), то Windows может разве что ограничить доступ ко всему тому, но не к отдельным файлам и каталогам. Важным элементом любой системы защиты данных является процедура входа в систему, при которой выполняется аутентификация пользователя. В WindowsNT для вызова диалога входа в систему используется известная «комбинация из трех пальцев» – Ctrl+Alt+Del. Как утверждают разработчики, никакая «троянская» программа не может перехватить обработку этой комбинации и использовать ее с целью коллекционирования паролей. Не хочет ли кто-нибудь попробовать? Система ищет введенное имя пользователя сначала в списке пользователей данного компьютера, а затем и на других компьютерах текущего домена локальной сети. В случае, если имя найдено и пароль совпал, система получает доступ к учетной записи
(account) данного пользователя. На основании сведений из учетной записи пользователя система формирует структуру данных, которая называется маркером доступа
(accesstoken). Маркер содержит идентификатор пользователя (SID, SecurityIDentifier), идентификаторы всех групп, в которые включен данный пользователь, а также набор привилегий
, которыми обладает пользователь. Привилегиями называются права общего характера, не связанные с конкретными объектами. К числу привилегий, доступных только администратору, относятся, например, права на установку системного времени, на создание новых пользователей, на присвоение чужих файлов. Некоторые скромные привилегии обычно предоставляются всем пользователям (например, такие, как право отлаживать процессы, право получать уведомления об изменениях в файловой системе). В дальнейшей работе, когда пользователю должен быть предоставлен доступ к каким-либо защищаемым ресурсам, решение о доступе принимается на основании информации из маркера доступа. Для любого защищаемого объекта Windows (файла, каталога, диска, устройства, семафора, процесса и т.п.) может быть задана специальная структура данных – атрибуты защиты. Основным содержанием атрибутов защиты является другая структура – дескриптор защиты
. Этот дескриптор содержит следующие данные: · идентификатор защиты (SID) владельца объекта; · идентификатор защиты первичной группы владельца объекта; · пользовательский («дискреционный», «разграничительный») список управления доступом (DACL, DiscretionaryAccessControlList); · системный список управления доступом (SACL, SystemAccessControlList). Пользовательский список управляет разрешениями
и запретами
доступа к данному объекту. Изменять этот список может только владелец объекта. Системный список управляет только аудитом
доступа данному объекту, т.е. задает, какие действия пользователей по отношению к данному объекту должны быть запротоколированы в системном журнале. Изменять этот список может только пользователь, имеющий права администратора системы. В Windows, в отличие от многих других ОС, администратор не всесилен. Он не может запретить или разрешить кому бы то ни было, даже самому себе, доступ к чужому файлу. Другое дело, что администратор имеет право объявить себя владельцем любого файла, но потом он не сможет вернуть файл прежнему хозяину. Подобные ограничения вытекают из понимания, что администратор тоже не всегда ангел и, хотя он должен иметь в системе большие права, его действия следует хоть как-то контролировать. Оба списка управления доступом имеют одинаковую структуру, их основной частью является массив записей управления доступом
(ACE, AccessControlEntity). Рассмотрим структуру записи ACE. Она содержит: · тип ACE, который может быть одним из следующих: разрешение, запрет, аудит; · флаги, уточняющие особенности действия данной ACE; · битовая маска видов доступа, указывающая, какие именно действия следует разрешить, запретить или подвергнуть аудиту; · идентификатор (SID) пользователя или группы, чьи права определяет данная ACE. Более интересен пользовательский список. Он может содержать только записи разрешения и запрета. В начале списка всегда идут запрещающие записи, затем разрешающие. Когда пользователь запрашивает доступ к объекту (т.е., например, программа, запущенная этим пользователем, вызывает функцию открытия файла), происходит проверка прав доступа. Она выполняется на основе сравнения маркера доступа пользователя со списком DACL. Система просматривает по порядку все записи ACE из DACL, для каждой ACE определяет записанный в ней SID и сверяет, не является ли он идентификатором текущего пользователя или одной из групп, куда входит этот пользователь. Если нет, то данная ACE не имеет к нему отношения и не учитывается. Если да, то выполняется сравнение прав, необходимых пользователю для выполнения запрошенной операции с маской видов доступа из ACE. При этом права анализируются весьма детально: например, открытие файла на чтение подразумевает наличие прав на чтение данных, на чтение атрибутов (в том числе владельца и атрибутов защиты), на использование файла как объекта синхронизации (см. п. 4.5.5.2). Если в запрещающейACE найдется хотя бы один единичный бит в позиции, соответствующей одному из запрошенных видов доступа, то вся операция, начатая пользователем, считается запрещенной и дальнейшие проверки не производятся. Если такие биты будут найдены в разрешающейACE, то проверка следующих ACE выполняется до тех пор, пока не будут разрешены и все остальные запрошенные виды доступа. Как выдумаете, почему в списке DACL сначала идут запрещающие ACE, а только потом разрешающие? Таким образом, говоря кратко, пользователь получит доступ к объекту только в том случае, если все запрошенные им виды доступа явным образом разрешены и ни один их них не запрещен. В годы перестройки много писалось о двух противоположных принципах: «запрещено все, что не разрешено» или «разрешено все, что не запрещено». В Windows все гораздо строже: запрещено все, что запрещено, и все, что не разрешено. Список DACL со всеми необходимыми разрешениями и запретами может быть установлен программно при создании файла, а впоследствии программно же может быть изменен владельцем. Можно также изменять разрешения в диалоге, воспользовавшись окном свойств файла. Имеются также два крайних случая. Список DACL может совсем отсутствовать (для этого достаточно, например, при создании файла указать NULL вместо атрибутов защиты), при этом права доступа не проверяются, все действия разрешены всем пользователям. Список DACL может присутствовать, но иметь нулевую длину (нет ни одной ACE). Как следует из общих правил, в этом случае в доступе будет отказано всем, в том числе и хозяину файла. Под управлением процессами понимаются процедуры ОС, обеспечивающие запуск системных и прикладных программ, их выполнение и завершение. В однозадачных ОС управление процессами решает следующие задачи: · загрузка программы в память, подготовка ее к запуску и запуск на выполнение; · выполнение системных вызовов процесса; · обработка ошибок, возникших в ходе выполнения; · нормальное завершение процесса; · прекращение процесса в случае ошибки или вмешательства пользователя. Все эти задачи решаются сравнительно просто. В многозадачном режиме добавляются значительно более серьезные задачи: · эффективная реализация параллельного выполнения процессов на единственном процессоре, переключение процессора между процессами; · выбор очередного процесса для выполнения с учетом заданных приоритетов процессов и статистики использования процессора; · исключение возможности несанкционированного вмешательства одного процесса в выполнение другого; · предотвращение или устранение тупиковых ситуаций, возникающих при конкуренции процессов за системные ресурсы; · обеспечение синхронизации процессов и обмена данными между ними. 4.2.1. Понятия процесса и ресурса
Согласно определению, данному в /7/, «последовательный процесс (иногда называемый «задача») есть работа, производимая последовательным процессором при выполнении программы с ее данными». Проанализируем это определение. Оно подчеркивает последовательный характер процесса, т.е. выполнение команд в определенном порядке. Термин «задача» мы будем понимать как синоним термина «процесс» (в некоторых ОС эти термины различаются). Далее, процесс – понятие динамическое. Программа – это текст, процесс – выполнение этого текста. Конечно, на практике мы часто говорим: «программа вызывает функцию», «программа ждет ввода» и т.п., однако, строго говоря, правильнее было бы «процесс, выполняющий программу, вызывает…». Еще один важный момент в определении – упоминание данных. В многозадачных системах зачастую одна и та же программа может запускаться несколько раз (например, можно несколько раз открыть текстовый редактор Notepad для разных файлов). Это означает, что несколько процессов могут использовать одну и ту же программу, но с разными данными. При описании работы многозадачных систем основное внимание уделяется вопросам, связанным с параллельным выполнением, т.е. с одновременной работой нескольких процессов. Однако общий термин «параллельное выполнение» объединяет два существенно различных способа организации выполнения процессов – синхронный и асинхронный параллелизм. Синхронный параллелизм предполагает наличие общей тактовой последовательности, управляющей шагами выполнения параллельно работающих процессов. Синхронная организация используется в некоторых типах многопроцессорных вычислительных систем. При асинхронном параллелизме никакого общего такта нет. Процессы выполняются независимо друг от друга, при этом не делается никаких предположений об их сравнительной скорости, о соотношении времени выполнения различных фрагментов программ и т.п. Сопоставить продвижение разных процессов можно только в явно заданных точках программы процессов, называемых точками синхронизации. Синхронизация обычно означает ожидание одним процессом какого-либо события, связанного с другим процессом. Например, после разветвления выполнения на две параллельные ветви и выполнения ветвями определенных задач может понадобиться свести ветви воедино: та ветвь, которая закончила свое выполнение раньше, должна дождаться завершения другой ветви. Другой пример: процесс, выполняющий обработку введенных строк, может ждать, пока другой процесс не прочтет очередную строку из файла или с клавиатуры. Точка синхронизации может быть связана также с обменом данными между процессами. Когда процесс-приемник завершает прием данных, то можно быть, по крайней мере, уверенным, что процесс-источник достиг того места в программе, где он должен был передать данные. В дальнейшем всюду будет рассматриваться только асинхронный параллелизм, поскольку он характерен для работы ОС. Другим основополагающим понятием, тесно связанным с управлением процессами, является понятие ресурса
. Под ресурсом понимается любой аппаратный или программный объект, который может понадобиться для работы процессов и доступ к которому может при этом вызвать конкуренцию процессов. Говоря упрощенно, ресурс – это нечто дефицитное в вычислительной системе. К важнейшим ресурсам любой системы относятся процессор (точнее сказать, процессорное время), основная память, периферийные устройства, файлы. В зависимости от конкретной ОС, к дефицитным ресурсам могут относиться места в таблице процессов или в таблице открытых файлов, буферы кэша, блоки в файле подкачки и другие системные структуры данных. Если два процесса никак не связаны логикой своей работы, то никакой синхронизации или обмена данными между ними нет, однако такие процессы все же могут оказывать косвенное влияние друг на друга вследствие конкуренции за ресурсы. Многозадачная ОС управляет доступом процессов к ресурсам. В некоторых случаях система временно закрепляет ресурс за одним процессом, отказывая другим процессам в доступе или заставляя их ждать освобождения ресурса. В других случаях оказывается возможным совместный доступ нескольких процессов к одному ресурсу. 4.2.2. Квазипараллельное выполнение процессов С точки зрения внешнего наблюдателя, в хорошей многозадачной ОС происходит одновременная, параллельная работа нескольких процессов. Однако понятно, что эта одновременность кажущаяся. На самом деле, если в системе работает лишь один процессор, то в каждый момент времени он выполняет команды, относящиеся только к одному из имеющихся процессов. Иллюзия параллельности создается за счет того, что процессы сменяют друг друга через малые интервалы времени, которые человек-наблюдатель не в силах отследить. Подобная организация работы называется квазипараллельным выполнением процессов. Разумеется, если в системе имеется несколько процессоров, то может быть организовано настоящее параллельное выполнение процессов, количество которых не превышает количества процессоров. При большем числе процессов может использоваться смешанная организация, сочетающая истинную параллельность и квазипараллельность. Важно отметить, что для большинства задач взаимодействия процессов нет разницы, какого рода параллельность используется в данной ОС. Вообще, основные проблемы управления процессами можно разбить на два уровня: · проблемы корректной и эффективной реализации параллельного (т.е. обычно квазипараллельного) выполнения процессов – это проблемы нижнего уровня; · проблемы корректного взаимодействия параллельных процессов – это проблемы верхнего уровня, при рассмотрении которых считается, что низкоуровневые проблемы реализации процессов так или иначе решены. Такое разбиение облегчает проектирование и отладку систем, а также позволяет лучше понять существо рассматриваемых проблем. Любой процесс в многозадачной ОС многократно испытывает переход из одного состояния в другое. Основных состояний всего три. · Работа (running) – в этом состоянии находится процесс, программу которого в данный момент выполняет процессор. Работающий процесс иногда удобно называть также текущим процессом. · Готовность (ready) – состояние, их которого процесс может быть переведен в состояние работы, как только это сочтет нужным сделать ОС. · Блокировка или, что то же самое, сон (sleeping, waiting) – состояние, в котором процесс не может продолжать выполнение, пока не произойдет некоторое внешнее по отношению к процессу событие. Первые два состояния часто объединяют понятием активного состояния процесса. Для состояний готовности и сна общее то, что процесс не работает. В чем разница между этими двумя «способами не работать»? Готовый к выполнению процесс не выполняется только потому, что есть другие не менее готовые процессы, по мнению системы более достойные занимать сейчас процессорное время. В каждый момент времени выбор одного из готовых процессов на роль работающего определяется логикой работы ОС. Этот выбор должен обеспечивать эффективную квазипараллельную работу готовых процессов. Как решается эта задача – будет рассмотрено ниже. В отличие от этого, спящий процесс – это всегда процесс, ожидающий некоторого конкретного события. Спящий процесс не сможет заработать, даже если процессор вдруг окажется свободным. Такой процесс, в соответствии со своей собственной логикой, ждет чего-то, что должно произойти. Чего он может ждать? Ну, например: · завершения начатой операции синхронного ввода/вывода (т.е., например, процесс ждет нажатия клавиши Enter или окончания записи на диск); · освобождения запрошенного у системы ресурса (например, дополнительной области памяти или открытого файла); · истечения заданного интервала времени («посплю-ка я минут десять!») или достижения заданного момента времени («разбудите меня ровно в полночь!») (в обоих случаях процесс ждет сигнала от запрограммированного таймера); · сигнала на продолжение действий от другого, взаимосвязанного процесса; · сообщения от системы о необходимости выполнить определенные действия (например, перерисовать содержимое окна). В любом из названных (и многих неназванных) случаев должно произойти некоторое событие, источник которого лежит вне данного процесса. Чисто условно можно сказать, что если бы в вычислительную систему вдруг было добавлено еще несколько процессоров, то «готовые» процессы могли бы сразу перейти в состояние «работа», но «спящие» продолжили бы свой сон. Разумеется, как мы видели в п. 2.5, процесс может выполнять ожидание путем циклической проверки ожидаемого условия. При этом он формально будет оставаться активным, растрачивая драгоценное процессорное время на то, что в п. 2.5.2 было названо активным ожиданием. Однако такое решение будет говорить лишь о вопиющей неквалифицированности программиста. Любая многозадачная ОС предоставляет в распоряжение прикладных программ набор функций, переводящих вызвавший их процесс в состояние сна, в котором процесс не пытается использовать процессорное время (другими словами, состояние сна есть состояние пассивного ожидания). Такие системные функции называются блокирующими. К их числу относятся функции синхронного ввода/вывода, запроса ресурсов, приостановки до заданного времени, получения сообщений и многие другие. Поскольку ОС берет на себя блокировку, «усыпление» процесса, она должна обеспечить и его разблокировку, «пробуждение». Чтобы это стало возможным, система должна для каждого спящего процесса помнить, «чего он ждет», т.е. помнить условия пробуждения процесса. Система отслеживает все события, способные разблокировать какой-либо процесс (во многих случаях используя для этого аппаратные прерывания) и, когда для одного или сразу нескольких процессов наступает ожидаемое событие, переводит эти события из состояния сна в состояние готовности. На рис. 4‑1 показаны основные состояния процесса и переходы между ними. Этот рисунок кочует из книги в книгу, поскольку он действительно наглядно отражает самую суть работы многозадачных систем. Рис.
4‑1 Рассмотрим возможные переходы между состояниями процесса, показанные на рисунке стрелками. Переход Работа - Сон представляет собой блокировку процесса, которая может произойти при вызове блокирующей системной функции. Переход Сон - Готовность – это пробуждение процесса, оно выполняется системой при возникновении соответствующего условия. Переход Работа - Готовность ранее не рассматривался. Он называется вытеснением процесса и выполняется системой, когда она принимает решение о смене текущего процесса. Для обратного перехода Готовность - Работа нет общепринятого термина. Будем называть его выбором процесса для выполнения. Отметим, что этот переход почти всегда связан либо с блокировкой, либо с вытеснением прежнего текущего процесса. Ответьте сами на вопрос: почему «почти всегда», а не «всегда»? Какие еще возможны варианты? Двух стрелок нет на диаграмме. Прямой переход от сна к работе нелогичен, т.к. он совмещал бы два совершенно разных действия. Каких именно? Переход от готовности ко сну невозможен в принципе. Кстати, почему? Помимо трех основных состояний, в различных ОС могут использоваться и другие состояния. Состояние старта означает, что процесс находится на этапе создания и пока не готов вступить в работу. Состояние завершения (в UNIX оно почти официально называется «зомби») означает, что процесс завершил свою работу, но пока присутствует в системе в виде записи о результатах и причине завершения. Состояние приостановки (suspended) означает, что выполнение процесса временно прервано оператором (или, может быть, другим процессом) и позднее должно быть им же возобновлено. В некоторых системах (например, в UNIX) основные состояния раздроблены на ряд более мелких: работа в системном и в пользовательском режиме, готовность в памяти и готовность на диске и т.п. Необходимый набор состояний определяется алгоритмами работы конкретной ОС. 4.2.4. Вытесняющая и невытесняющая многозадачность Все многозадачные ОС можно разделить на два класса, различающиеся по способам организации переключения процессов. В системах с невытесняющей диспетчеризацией (non-preemptivemultitasking) работа любого процесса может быть прервана только «по инициативе самого процесса», а точнее – только когда процесс вызывает определенные системные функции. К ним относятся, в частности, описанные выше блокирующие функции. Может также иметься функция, специально предназначенная для добровольной уступки процессом очереди на выполнение (Yield). Вызов такой функции не приводит к блокировке, но может привести к вытеснению процесса[7]
. Если работающий процесс не вызывает системных функций, а занимается, например, долгими расчетами, то все остальные процессы вынуждены простаивать. Когда же системная функция, наконец, вызвана, то система, прежде всего, проверяет, может ли эта функция быть выполнена сразу или предполагает ожидание некоторого события (требуемый ресурс может быть занят другим процессом; операция ввода/вывода обычно требует определенного времени на свое выполнение; очередь сообщений, требующих обработки, может быть пуста). Если требуется ожидание, то система блокирует процесс, выбирая какой-либо другой из готовых процессов для выполнения. Не исключена ситуация, когда заблокированными по разным причинам оказываются все пользовательские процессы. Но даже если действие, требуемое процессом, может быть выполнено без блокировки, система не обязательно спешит выполнить его и вернуть управление текущему процессу. На самом деле, момент вызова системной функции удобен для того, чтобы система могла решить, не пора ли процессу «отдохнуть», поскольку имеются другие процессы, давно претендующие на процессорное время или обладающие более высоким приоритетом. В этом случае система переводит процесс в состояние готовности к выполнению, а один из других готовых к выполнению процессов становится текущим. Что же касается вызванной системной функции, то ее выполнение будет завершено позднее, когда вызвавший процесс вновь станет текущим. В предыдущем п. 4.2.3 смена текущего процесса, не связанная с его блокировкой, была названа вытеснением процесса. Та часть ОС, которая по определенным в системе правилам выбирает, следует ли вытеснить текущий процесс и какой процесс должен стать следующим текущим, называется планировщиком (scheduler) или диспетчером процессов. В системе с невытесняющей диспетчеризацией планировщик получает управление при вызове процессом одной из блокирующих или вытесняющих функций. Планировщик проверяет, не выполнены ли условия активизации одного из спящих процессов, а затем принимает решение о выборе одного из активных процессов для выполнения. Не исключено, что будет опять выбран тот же процесс (если только он не блокируется). Использование невытесняющей диспетчеризации позволило разработать достаточно впечатляющие примеры ОС, из которых наиболее известной является Windows версий 1, 2 и 3. Обычно в таких системах большая часть процессов находится в спящем состоянии, ожидая, пока пользователь обратится к соответствующему приложению. Для пользователя это выглядит совершенно естественно. Главный недостаток многозадачности невытесняющего типа заключается в том, что любой процесс в принципе имеет возможность полностью и надолго захватить процессор. Это «многозадачность на честном слове», основанная на предположении, что программы всех процессов написаны так, чтобы достаточно часто вызывать блокирующие функции. Даже если программист пишет программу для выполнения сложных многочасовых вычислений, он должен искусственно вставлять в некоторых местах вызов системных функций, передающих управление планировщику. Если же это не сделано, то система фактически теряет многозадачность и будет выполнять один процесс, не реагируя на действия пользователя, до тех пор, пока либо «нахальный» процесс завершится, либо рассвирепевший пользователь снимет его по Ctrl+Alt+Del. Более сложным и совершенным типом многозадачных ОС являются системы с вытесняющей диспетчеризацией
процессов (preemptivemultitasking). Их отличие заключается в том, что планировщик вступает в работу не только (и не столько) при вызове системных функций, но и в следующих двух случаях (или хотя бы в одном из них): · когда активизируется (т.е. пробуждается или запускается) процесс, обладающий более высоким приоритетом, чем текущий; · когда истекает квант времени
, выделенный планировщиком для текущего процесса. Понятие приоритета
процесса будет подробно рассмотрено чуть ниже. Приоритет характеризует относительную важность или срочность данного процесса. Надо отметить, что немедленный вызов планировщика при активизации высокоприоритетного процесса характерен не для всех систем с вытесняющей диспетчеризацией, а только для одного их подкласса – систем с абсолютными приоритетами
. В системах с относительными приоритетами
процесс с высоким приоритетом будет все же вынужден подождать истечения кванта времени. Системы, в которых перепланировка процесса выполняется после истечения каждого кванта времени, называют системами с квантованием времени
[8]
(timeslicing). Если величина кванта достаточно мала, то для пользователя процесс периодической смены текущего процесса будет незаметен и создастся впечатление, что все активные процессы работают как бы одновременно. С другой стороны, чем меньше величина кванта, тем большую долю процессорного времени будет занимать процедура переключения текущего процесса. Вызов планировщика не обязательно означает смену процесса. Если нет других активных процессов с таким же или более высоким приоритетом, то планировщик может продолжить выполнение того же процесса. Принципиальной чертой систем с вытесняющей диспетчеризацией является то, что текущий процесс может быть прерван и вытеснен практически в любой точке своей программы. Это заметно усложняет реализацию таких систем по сравнению с невытесняющими системами, где смена текущего процесса может произойти только в момент вызова системной функции. 4.2.5. Дескриптор и контекст процесса
С каждым процессом связаны описывающие его данные в основной памяти, необходимые ОС для поддержки выполнения процесса. Все эти данные можно разбить на две большие структуры: дескриптор процесса и контекст процесса. Дескриптор процесса
включает в себя все те данные о процессе, которые могут понадобиться ОС при различных состояниях процесса. В число элементов дескриптора могут входить, например, идентификатор процесса (некое условное число, обозначающее данный процесс); текущее состояние процесса; его приоритет; владелец процесса (т.е. идентификатор пользователя, запустившего процесс); статистика затраченного процессом общего и процессорного времени; указатель местоположения контекста процесса и др. Дескрипторы всех процессов, существующих в системе, собраны в таблицу процессов. Контекст процесса
включает данные, необходимые только для текущего процесса. Суда относятся, прежде всего, значения всех регистров процессора, включая указатель текущей команды; таблица файлов, открытых процессом; указатели на области памяти, которые должен занимать процесс при его выполнении; значения системных переменных, используемых процессом (например, текущий диск и каталог, информация о последней ошибке при выполнении системных функций); другие системные флаги и режимы, которые могут иметь разные значения для разных процессов. Точный состав дескриптора и контекста сильно зависят от конкретной ОС. При переключении текущего процесса система должна каждый раз переключать и текущий контекст, т.е. сохранять в своей памяти или на диске контекст предыдущего выполнявшегося процесса и восстанавливать ранее сохраненный контекст того процесса, который будет выполняться. 4.2.6. Реентерабельность системных функций В многозадачной системе нельзя исключить возможность того, что переключение процессов произойдет во время выполнения вытесняемым процессом какой-либо из системных функций. При этом выполнение функции не будет завершено, оно будет прервано на середине. Предполагается, что выполнение функции будет завершено позднее, когда прерванный процесс снова будет выбран на выполнение. Проблема заключается в том, что новый текущий процесс может вызвать ту же самую системную функцию. Возникает вопрос: возможно ли корректное выполнение второго вызова функции, если к этому моменту не закончено выполнение первого вызова той же функции? Простой пример подобной ситуации – запуск в ОС нескольких программ, каждая из которых блокируется на ожидании клавиатурного ввода, вызвав для этого одну и ту же системную функцию ввода. Функция или процедура, для которой возможно корректное выполнение ее повторного вызова до завершения первого вызова, называется реентерабельной
или повторно-входимой
. Проблема реентерабельности функций возникает в программировании и по совершенно другому поводу, не связанному с реализацией ОС. Речь идет о рекурсивных функциях, т.е. функциях, которые могут прямо или косвенно вызывать сами себя. Давно известна и основная причина нереентерабельности функций. Она заключается в использовании одних и тех же ячеек памяти для формальных параметров и локальных переменных при разных вызовах функции. Действительно, если при первом вызове функции в ячейку локальной переменной X будет занесено, например, число 10, а при втором – число 20, то после возобновления выполнения первого вызова значение X будет неверным. Лекарство от этой формы нереентерабельности также давно известно и встроено во все уважающие себя языки программирования, начиная с C и Pascal. Оно заключается в том, что память для формальных параметров и локальных переменных должна выделяться в стеке программы, при этом каждый новый вложенный вызов получает свой набор ячеек для переменных. Для случая многозадачной системы использование единого стека неприемлемо, поскольку вызовы функций не являются вложенными, т.е. первый вызов может завершиться раньше, чем второй, что привело бы к неверному использованию стека. Каждый процесс получает свой собственный стек, являющийся частью контекста процесса. Еще одна причина нереентерабельности касается тех функций ввода/вывода, которые запускают операцию и затем дожидаются ее завершения. Повторное обращение к тому же устройству до завершения первого вызова может привести к ошибке. В данном случае система должна отслеживать состояние устройства и блокировать второй вызов до освобождения устройства. Проблема реентерабельности системных функций значительно острее стоит для ОС с вытесняющей диспетчеризацией, поскольку переключение процесса может случиться при выполнении любой функции. При невытесняющей диспетчеризации достаточно обеспечить реентерабельную реализацию лишь небольшого числа блокирующих функций. При переходе от невытесняющей Windows 3.x к вытесняющей Windows 95 одна из серьезных проблем состояла в сохранении кода большого количества нереентерабельных системных функций. Проблему «решили» путем введения семафора, блокирующего повторный вызов для большого числа функций. Неприятным следствием этого стало взаимное тормозящее влияние процессов. В WindowsNT этой проблемы нет, все функции реализованы реентерабельно. 4.2.7. Дисциплины диспетчеризации и приоритеты процессов Когда планировщик процессов получает управление, его основной задачей является выбор следующего процесса, который должен получить управление. Алгоритмы, лежащие в основе этого выбора, определяют дисциплину диспетчеризации
, принятую в данной ОС. Одной из самых очевидных дисциплин является простая круговая диспетчеризация
(roundrobinscheduling). Ее суть в следующем. Все активные процессы считаются равноправными и образуют круговую очередь. Каждый процесс получает от системы квант времени, по истечении которого планировщик выбирает для выполнения следующий процесс из очереди. Таким образом, если все процессы остаются активными, то система обеспечивает их равномерное продвижение, имитирующее параллельное выполнение всех процессов. Если текущий процесс блокируется, он выпадает из круга и попадает в список спящих процессов. Когда система активизирует один из спящих процессов, он включается в круговую очередь. В некотором смысле противоположной дисциплиной является фоново-оперативная диспетчеризация
(foreground/backgroundscheduling) – одна из самых старых форм организации многозадачной работы. В простейшем случае она включает два процесса: фоновый процесс и оперативный процесс (процесс переднего плана). Фоновый процесс выполняется только тогда, когда спит оперативный процесс. При активизации оперативного процесса происходит немедленное вытеснение фонового, т.е. оперативный процесс имеет более высокий абсолютный приоритет. Обычно при такой дисциплине предполагается, что активизация оперативного процесса не потребует много процессорного времени, так что выполнение фонового процесса будет скоро возобновлено. Одним из примеров эффективного использования фоново-оперативной диспетчеризации является так называемая «фоновая печать», которую позволяет выполнить даже однозадачная MS-DOS. При этом процесс вывода файла на принтер рассматривается как процесс переднего плана, а обычная диалоговая работа с ОС – как фоновый процесс. Поскольку обслуживание прерываний от принтера занимает лишь доли процента процессорного времени, пользователь не ощущает никакого замедления работы. Между описанными двумя крайностями лежит большое разнообразие дисциплин приоритетной диспетчеризации
. Все они основаны на приписывании каждому процессу при его создании некоторого числа – приоритета
. Более высокий приоритет должен давать процессу определенные преимущества перед низкоприоритетными процессами при работе планировщика. Назначение приоритетов выполняется пользователем либо администратором системы, возможно также программное изменение приоритета процесса. На выбор оптимального уровня приоритета влияют в основном два соображения: · важность, ответственность данного процесса либо привилегированное положение запускающего процесс пользователя; · количество процессорного времени, на которое будет претендовать процесс (как мы видели в примере с фоновой печатью, высокий приоритет процесса, мало загружающего процессор, почти не приводит к замедлению работы остальных процессов). Основной алгоритм приоритетного планирования напоминает простое круговое планирование, однако круговая очередь активных процессов формируется отдельно для каждого уровня приоритета. Пока есть хоть один активный процесс в очереди с самым высоким приоритетом, процессы с более низкими приоритетами не могут получить управление. Только когда все процессы с высшим приоритетом заблокированы либо завершены, планировщик выбирает процесс из очереди с более низким приоритетом. Приоритет, присваиваемый процессу при создании, называется статическим
приоритетом. Дисциплина планирования, использующая только статические приоритеты, имеет один существенный недостаток: низкоприоритетные процессы могут надолго оказаться полностью отлученными от процессора. Иногда это приемлемо (если высокоприоритетные процессы несравнимо важнее, чем низкоприоритетные), однако чаще хотелось бы, чтобы и на низкие приоритеты хоть что-нибудь перепадало, пусть даже реже и в меньшем количестве, чем на высокие. Для решения этой задачи предложено множество разных алгоритмов планирования процессов, основанных на идее динамического
приоритета. Динамический приоритет процесса – это величина, автоматически рассчитываемая системой на основе двух основных факторов: статического приоритета и степени предыдущего использования процессора данным процессом. Общая идея следующая: если процесс слишком долго не получал процессорного времени, то его приоритет следует повысить, чтобы дать процессу шанс на будущее. Наоборот, если процесс слишком часто и долго работал, есть смысл временно понизить его приоритет, чтобы пропустить вперед изголодавшихся конкурентов. Могут учитываться и другие соображения, влияющие на динамический приоритет. Например, если процесс ведет диалог с пользователем, то имеет смысл повысить его приоритет, чтобы сократить время реакции и избежать досадных задержек при нажатии клавиш. Если процесс в последнее время часто блокировался, не использовав до конца выделенный ему квант времени, то это тоже основание для повышения приоритета: вполне возможно, процесс и впредь будет так же неприхотлив. 4.3.1. Изоляция процессов и их взаимодействие Одна из важнейших целей, которые ставятся при разработке многозадачных систем, заключается в том, чтобы разные процессы, одновременно работающие в системе, были как можно лучше изолированы друг от друга. Это означает, что процессы (в идеале) не должны ничего знать даже о существовании друг друга. Для каждого процесса ОС предоставляет виртуальную машину
, т.е. полный набор ресурсов, имитирующий выполнение процесса на отдельном компьютере. Изоляция процессов, во-первых, является необходимым условием надежности и безопасности многозадачной системы. Один процесс не должен иметь возможности вмешаться в работу другого или получить доступ к его данным, ни по случайной ошибке, ни намеренно. Во-вторых, проектирование и отладка программ чрезвычайно усложнились бы, если бы программист должен был учитывать непредсказуемое влияние других процессов. С другой стороны, есть ситуации, когда взаимодействие необходимо. Процессы могут совместно обрабатывать общие данные, обмениваться сообщениями, ждать ответа и т.п. Система должна предоставлять в распоряжение процессов средства взаимодействия. Это не противоречит тому, что выше было сказано об изоляции процессов. Чтобы взаимодействие не привело к полному хаосу, оно должно выполняться только с помощью тех хорошо продуманных средств, которые предоставляет процессам ОС. За пределами этих средств действует изоляция процессов. Это как граница государств – пересекать ее в произвольных местах запрещено, но должна быть хорошо обустроенная система пропускных пунктов, где легко проконтролировать соблюдение правил пересечения границы. Понятие взаимодействия процессов включает в себя несколько видов взаимодействия, основными из которых являются: · синхронизация процессов, т.е., упрощенно говоря, ожидание одним процессом каких-либо событий, связанных с работой других процессов; · обмен данными между процессами. Набор средств, предназначенных для взаимодействия процессов, часто обозначают аббревиатурой IPC (InterProcessCommunication). Состав функций и методов обусловлен многолетним опытом как программистов-практиков, так и теоретиков, рассматривающих проблемы взаимодействия параллельных процессов. Следует еще раз отметить, что проблемы взаимодействия процессов не зависят от способа реализации параллельной работы процессов в конкретной ОС. Большая часть этих проблем имеет место в равной степени и для квазипараллельной реализации, и для истинной параллельности с использованием нескольких процессоров. Средства решения проблем, правда, могут зависеть от реализации. 4.3.2. Проблема взаимного исключения процессов Серьезная проблема возникает в ситуации, когда два (или более) процесса одновременно пытаются работать с общими для них данными, причем хотя бы один процесс изменяет значение этих данных. Проблему часто поясняют на таком, немного условном, примере. Пусть имеется система резервирования авиабилетов, в которой одновременно работают два процесса. Процесс A обеспечивает продажу билетов, процесс B – возврат билетов. Не углубляясь в детали, будем считать, что оба процесса работают с переменной N – числом оставшихся билетов, причем соответствующие фрагменты программ на псевдокоде выглядят примерно так: . . . R1 := N; R1 := R1 - 1; N := R1; . . . . . . R2 := N; R2 := R2 + 1; N := R2; . . . Представим себе теперь, что при квазипараллельной реализации процессов в ходе выполнения этих трех операторов происходит переключение процессов. В результате, в зависимости от непредсказуемых случайностей, порядок выполнения операторов может оказаться различным, например: 1) R1 := N; R2 := N; R2 := R2 + 1; N := R2;
R1 := R1 - 1; N := R1; 2)R2 := N; R2 := R2 + 1;
R1 := N; R1 := R1 - 1; N := R1; N := R2;
3) R1 := N; R1 := R1 - 1; N := R1; R2 := N; R2 := R2 + 1; N := R2;
Ну и что? А то, что в случае 1 значение N в результате окажется уменьшенным на 1, в случае 2 – увеличенным на 1, и только в случае 3 значение N, как и положено, не изменится. Можно привести менее экзотические примеры. · Если два процесса одновременно пытаются отредактировать одну и ту же запись базы данных, то в результате разные поля одной записи могут оказаться несогласованными. · Если один процесс добавляет сообщение в очередь, а другой в это время пытается взять сообщение из очереди для обработки, то он может прочесть не полностью сформированное сообщение. · Если два процесса одновременно пытаются обратиться к диску, каждый со своим запросом, то что именно каждый из них в результате прочтет или запишет на диск – сказать трудно. Ситуация понятна: нельзя разрешать двум процессам одновременно обращаться к одним и тем же данным, если при этом происходит изменение этих данных. То, что мы рассматривали квазипараллельную реализацию процессов, не столь существенно. Для процессов, работающих на разных процессорах, но одновременно обращающихся к одним и тем же данным, ситуация примерно та же. Задолго до создания многозадачных систем разработчики средств автоматики столкнулись с неприятным эффектом зависимости результата операции от случайного и непредсказуемого соотношения скоростей распространения разных сигналов в электронных схемах. Этот эффект они назвали «гонками». Мы здесь ведем речь, в сущности, о том же. Для более четкого описания ситуации было введено понятие критической секции
. Критической секцией процесса по отношению к некоторому ресурсу называется такой участок программы процесса, при прохождении которого необходимо, чтобы никакой другой процесс не находился в своей критической секции по отношению к тому же ресурсу. В примере с билетами приведенные три оператора в каждом из процессов составляют критическую секцию этого процесса по отношению к общей переменной N. Алгоритм работы каждого процесса в отдельности правилен, но правильная работа двух процессов в совокупности может быть гарантирована, только если они не сунутся одновременно каждый в свою критическую секцию. А как им это запретить? На первый взгляд кажется, что эта проблема (ее называют проблемой взаимного исключения
процессов) решается просто. Например, можно ввести булеву переменную Free, доступную обоим процессам и имеющую смысл «критическая область свободна». Каждый процесс перед входом в свою критическую область должен ожидать, пока эта переменная не станет истинной, как показано ниже: . . . while not Free do ; Free := false; (критическая секция A) Free := true; . . . . . . while not Free do ; Free := false; (критическая секция B) Free := true; . . . В обоих процессах цикл while не делает ничего, кроме ожидания, пока другой процесс выйдет из своей критической секции. А не нужно ли было что-нибудь сделать с переменной Free еще до запуска процессов A и B? Прежде всего, отметим, что предложенное решение использует такую неприятную вещь, как активное ожидание: процессорное время растрачивается на многократную проверку переменной Free. Но это полбеды. Беда в том, что такое решение ничего не решает. Если реализовать его на практике, то «неприятности» станут реже, но не исчезнут. В первом, бесхитростном варианте программы угрожаемыми участками были критические секции обоих процессов. Теперь же уязвимый участок сузился до одной точки, отмеченной в программе каждого процесса штриховой линией. Это точка между проверкой переменной Free и изменением этой переменной. Если переключение процессов произойдет, когда вытесняемый процесс будет находиться именно в этой точке, то сначала в критическую секцию войдет (с полным правом на это) другой процесс, а потом, когда управление вернется к первому процессу, он без дополнительной проверки тоже войдет в свою критическую секцию. Разработчики первых программных систем, использующих взаимодействие параллельных процессов, не сразу осознали сложность проблемы взаимного исключения. Были испробованы различные программные решения, прежде чем удалось найти такое, которое удовлетворяло трем естественным условиям: · в любой момент времени не более, чем один процесс может находиться в критической секции; · если критическая секция свободна, то процесс может беспрепятственно войти в нее; · все процессы равноправны. Попробуйте сами найти такое решение. В книгах /3/ и /4/ можно найти несколько вариантов решения с анализом их ошибок. В конце концов правильные алгоритмы решена задачи взаимного исключения предложили сначала Деккер (его алгоритм довольно запутанный, что часто случается с первыми решениями сложных задач), затем Питерсон, чей алгоритм проще и понятнее. Для любознательных приводим решение Питерсона. В нем используются булевы переменные flagA, flagB, изначально равные false, и переменная перечисляемого типа turn: A..B. . . . flagA := true; turn := B; while flagB and turn = B do ; (критическая секция A) flagA := false; . . . . . . flagB := true; turn := A; while flagA and turn = A do ; (критическая секция B) flagB := false; . . . Приведенный алгоритм действительно решает проблему, однако у него есть два существенных недостатка. Во-первых, если в конкуренции за критическую секцию участвуют не два процесса, а три или более, то программа становится очень громоздкой. Во-вторых, решение Питерсона основано на использовании активного ожидания. Еще одним направлением в реализации взаимного исключения стало включение специальных машинных команд в наборы команд новых процессоров. Поскольку опасность, как мы видели, связана с разделением по времени операций проверки и присваивания, то были предложены команды, выполняющие одновременно проверку и присваивание. Такие команды есть, например, у процессоров Pentium. С их помощью действительно можно проще реализовать взаимное исключение, но для этого все равно требуется активное ожидание. 4.3.3. Двоичные семафоры Дейкстры Совершенно иным образом подошел к проблеме взаимного исключения великий голландский ученый Э.Дейкстра (E.Dijkstra, 1966). Он предложил использовать новый вид программных объектов – семафоры
. Здесь мы рассмотрим их простейший вариант – двоичные семафоры
, они же мьютексы
(mutex, от слов MUTualEXclusion – взаимное исключение). Двоичным семафором называется переменная S, которая может принимать значения 0 и 1 и для которой определены только две операции. · P(S) – операция занятия (закрытия) семафора. Она ожидает, пока значение S не станет равным 1, и, как только это случится, присваивает S значение 0 и завершает свое выполнение. Очень важно: операция Pпо определению неделима, т.е. между проверкой и присваиванием не может вклиниться другой процесс, который бы изменил значение S. · V(S) – операция освобождения (открытия) семафора. Она просто присваивает S значение 0. Чем переменная-семафор отличается от обычной булевой переменной? Тем, что для нее недопустимы никакие иные операции, кроме P и V. Нельзя написать в программе S:=1 или if(S)then ... , если S определена как семафор. Чем операция P отличается от варианта с проверкой и присваиванием, который мы выше признали неудовлетворительным? Неделимостью. Но это «по определению», а как на практике добиться этой неделимости? Это отдельный, вполне решаемый вопрос. Заслуга Дейкстры как раз в том, что он разделил проблему взаимного исключения на две независимые проблемы разных уровней: · на уровне реализации: как обеспечить работу семафоров в соответствии с их определением; · на уровне взаимодействия процессов: как написать корректно работающую программу, если в распоряжении программиста имеются семафоры. Решать эти две задачи по отдельности легче, чем обе вместе, при этом решать их обычно должны разные люди: первую – разработчики ОС, а вторую – разработчики прикладной программы. Рассмотрим сначала реализацию. Очевидно, функции P и V удобнее и надежнее один раз реализовать в ОС, чем каждый раз по-новому – в прикладных программах. (Названия этих функций могут в конкретных системах быть и иными, более выразительными.) Системная функция P(S) должна проверить, свободен ли семафор S. Если свободен (S = 1), то система занимает его (S := 0) и на этом функция завершается. Если же семафор занят, то система блокирует процесс, вызвавший функцию P, и запоминает, что этот процесс блокирован по ожиданию освобождения семафора S. Таким образом, при реализации семафоров удается избежать активного ожидания. Неделимость операции обеспечивается тем, что во время выполнения системой функции P переключение процессов запрещено. В крайнем случае, ОС имеет возможность для этого на короткое время запретить прерывания. Системная функция V(S) – это, конечно, не просто присваивание S := 1. Кроме этого, система должна проверить, нет ли среди спящих процессов такого, который ожидает освобождения семафора S. Если такой процесс найдется, система разблокирует его, а переменная S в этом случае сохраняет значение 0 (семафор снова занят, теперь уже другим процессом). Может ли случиться так, что несколько спящих процессов ждут освобождения одного и того же семафора? Да, так вполне может быть. Какой из этих процессов должен быть разбужен системой? С точки зрения корректности работы и соответствия определениям функций P и V – любой, но только один. С точки зрения эффективности работы – вероятно, надо разбудить самый приоритетный процесс, а в случае равенства приоритетов… ну, видимо, тот, который спит дольше. Теперь, когда мы разобрались с реализацией семафоров, можно о ней забыть[9]
и помнить только, что семафоры существуют и могут быть использованы при необходимости. Рассмотрим теперь вторую половину задачи – использование семафоров для управления взаимодействием процессов. Как можно реализовать корректную работу процессов с критическими секциями, если использовать двоичный семафор? Да очень просто. . . . P(S); (критическая секция A) V(S); . . . . . . P(S); (критическая секция B) V(S); . . . И все. Сложности ушли в реализацию семафоров. Надо только проследить, чтобы до начала работы процессов семафор S был открыт. 4.3.4. Средства взаимодействия процессов Можно доказать, что использование двоичных семафоров позволяет корректно решить любые проблемы синхронизации процессов. Но вовсе не обязательно это решение окажется простым и удобным. В некоторых случаях использование семафоров должно все же сопровождаться нежелательным активным ожиданием. За десятилетия, прошедшие после изобретения семафоров, были предложены различные средства синхронизации, более приспособленные для различных типовых задач. Рассмотрим некоторые из них. В упомянутой работе Дейкстры, помимо двоичных семафоров, принимающих значения 0 и 1, был рассмотрен также более общий тип семафоров со значениями на интервале от 0 до некоторого N. Функция P(S) уменьшает положительное значение семафора на 1, а при нулевом значении переходит в ожидание, как и в случае двоичного семафора. Функция V(S) увеличивает значение семафора на 1, но не более N. Область применения целочисленных семафоров несколько иная, чем у двоичных. Целочисленные семафоры применяются в задачах выделения ресурсов из ограниченного запаса. Величина N характеризует общее количество имеющихся единиц ресурса, а текущее значение переменной – количество свободных единиц. При запросе ресурса процесс вызывает функцию V(S), при освобождении – P(S). Для целочисленных семафоров иногда удобно использовать модифицированную функцию V(S, k), вторым параметром которой является число одновременно запрашиваемых единиц ресурса. Такая функция блокирует процесс, если значение семафора меньше k. Возможна ситуация, когда процесс может выбрать один из нескольких путей дальнейшей работы, но на каждом пути он может быть заблокирован закрытым семафором. Разумно было бы ждать освобождения любого из семафоров и только тогда выбрать свободный путь. Но как это сделать? Вызвав P(S) для одного из семафоров, процесс обречен ждать освобождения именно этого семафора, а не любого из имеющихся. Житейская ситуация: покупатель в супермаркете, выбирающий, к какой из касс занять очередь. Хорошо бы угадать очередь, которая пройдет быстрее… Функция множественного ожидания
P(S1
, S2
, … Sn
) позволяет указать в качестве параметров несколько двоичных семафоров (или массив семафоров). Если хотя бы один из семафоров свободен, функция занимает его, в противном случае она ждет освобождения любого из семафоров. Другой, не менее полезный вариант множественного ожидания, это ожидание момента, когда все указанные семафоры окажутся свободны. Это означает, что процесс может работать дальше только в том случае, если одновременно выполнены несколько условий, каждое из которых задано в виде двоичного семафора. Сигнал
– это нечто, что может быть послано процессу системой или другим процессом. С сигналом не связано никакой информации, кроме номера (кода), указывающего, какой именно тип сигнала посылается. При получении сигнала процесс прерывает свою текущую работу и переходит на выполнение функции, определенной как обработчик сигналов данного типа. Таким образом, сигналы сильно похожи на прерывания, но только высокоуровневые, управляемые системой, а не аппаратурой. Механизм сигналов позволяет решить, например, проблему критической секции иным способом, чем семафоры. Подумайте самостоятельно, как это можно сделать. Сообщения
также посылаются процессу системой или другим процессом, однако отличаются от сигналов в двух отношениях. Во-первых, сообщения не прерывают работу процесса-получателя. Вместо этого они становятся в очередь сообщений. Процесс должен сам вызвать функцию приема сообщения. Если очередь пуста, эта функция блокирует процесс до получения какого-нибудь сообщения. Во-вторых, с сообщением, в отличие от сигнала, может быть связана информация, передаваемая получателю. Таким образом, сообщения – это средство не только синхронизации, но и обмена данными между процессами. Поговорим теперь еще об обмене данными. Самым простым и естественным способом такого обмена представляется возможность совместного доступа двух или более процессов к общей области памяти. Но поскольку обычно ОС стремится, наоборот, надежно разделить память разных процессов, то для выделения обшей памяти нужны специальные системные средства. Общая память служит только средством обмена данными, но никак не решает проблем синхронизации. Участки программы, где происходит работа с общей памятью, часто следует рассматривать как критические секции и защищать семафорами. Другое часто используемое средство обмена данными – программный канал (pipe; иногда переводится как «трубопровод»). В этом случае для выполнения обмена используются не команды чтения/записи в память, а функции чтения/записи в файл. Программный канал «притворяется файлом», для работы с ним используются те же операции, что для последовательного доступа к файлу: открытие, чтение, запись, закрытие. Однако источником читаемых данных служит не файл на диске, а процесс, выполняющий запись «в другой конец трубы». Данные, записанные одним процессом, но пока не прочитанные другим, хранятся в системном буфере. Если же процесс пытается прочесть данные, которые пока не записаны другим процессом, то процесс-читатель блокируется до получения данных. 4.3.5. Проблема тупиков Согласно определению из /7/, тупик – это состояние, в котором «некоторые процессы заблокированы в результате таких запросов на ресурсы, которые никогда не могут быть удовлетворены, если не будут предприняты чрезвычайные системные меры». Как это прикажете понимать? Прежде всего, давайте отметим, что процессу, действующему в одиночку, не под силам загнать приличную ОС в тупик. Требования процесса не будут удовлетворены, только если они превышают то, что есть у системы. Скажем, процесс требует 500 Мб оперативной памяти, когда у системы есть всего-то 256 Мб. Ну, так в этом случае процесс будет не блокирован, а беспощадно убит системой. Иное дело, если в деле замешаны два или более процессов. Согласно другому определению, данному в /2/, «Группа процессов находится в тупиковой ситуации, если каждый процесс из группы ожидает события, которое может вызвать только другой процесс из той же группы». Рассмотрим такой пример. Пусть каждый из процессов A и B собирается работать с двумя файлами, F1 и F2, причем не намерен разделять эти файлы с другим процессом. Программы же процессов слегка различаются, а именно: . . . Открыть(F1); Открыть(F2); (работа процесса A с файлами); Закрыть(F1); Закрыть(F2); . . . . . . Открыть(F2); Открыть(F1); (работа процесса B с файлами); Закрыть(F1); Закрыть(F2); . . . В этой ситуации все может пройти благополучно. Пусть, например, процесс A успеет открыть оба файла к тому моменту, когда процесс B попытается открыть F2. Эта попытка не увенчается успехом: процесс B либо будет заблокирован до освобождения файлов, либо получит сообщение об ошибке при открытии файла и, если процесс умный, через какое-то время попытается еще раз. В конце концов оба процесса получат требуемые ресурсы (в данном случае открытые файлы), хотя и не оба сразу. Совсем иное будет дело, если A успеет открыть только F1, после чего B откроет F2. Тут-то и получится тупик. Процесс A хочет открыть файл F2, но не сможет этого сделать раньше, чем B закроет этот файл. Но B не закроет F2 до того, как сумеет открыть файл F1, который занят процессом A. Каждый из процессов захватил один из ресурсов и не собирается его отдавать раньше, чем получит другой. Ситуация «двух баранов на мосту». Подчеркнем: тупик – это не просто блокировка процесса, когда необходимый ему ресурс занят. Занят – ну и что, со временем, авось, освободится. Тупик – это взаимная блокировка
, из которой нет выхода. Еще пример. Пусть в системе имеется 100 Мб памяти, доступной для процессов. Процесс A при своем старте занимает 40 Мб, но позднее на короткое время требует еще 30 Мб, после чего завершается, освобождая всю память. Процесс B ведет себя точно таким же образом. Каждый из процессов по отдельности не требует у системы ничего невозможного. В то же время понятно: если оба процесса сумеют стартовать и начать параллельную работу, то ни один из них никогда не получит дополнительные 30 Мб. Тупик. Совсем грубый пример. Процесс A на каком-то этапе работы ждет сообщения от процесса B, после чего собирается послать ответное сообщение. В то же время процесс B ждет сообщения от A, чтобы потом ответить на него. Тупик неизбежен. В данном случае, в отличие от предыдущих, возникновение тупика связано с явной ошибкой в логике программы. Может ли помочь в борьбе с тупиками использование семафоров и других подобных средств? Вряд ли, разве что в редких случаях. Семафор – это, скорее, дополнительный тормоз для процесса. Вещь полезная, но не способствующая продвижению. Все известные способы борьбы с тупиками можно разделить на три группы: · исключение возможности тупиков путем анализа исходного текста программ; · предотвращение возникновения тупиков при работе ОС; · ликвидация возникших тупиков. Что касается анализа текста – это, безусловно, нужная вещь, хотя и непростая. Определить по тексту программ процессов, могут ли они зайти в тупик – сложная задача. К тому же, если и могут, то совсем не обязательно зайдут, все может зависеть от конкретных исходных данных и от временных соотношений. Но главное – для анализа исходного текста программ нужно иметь в своем распоряжении этот текст. Реально ли это? Только в некоторых ситуациях. Например, при разработке встроенной системы исходные тексты всех прикладных программ обычно доступны разработчику ОС. Конечно, в этом случае анализ на возможность тупиков просто необходим. Другой пример – разработка сложного многопроцессного приложения, когда разработчик должен хотя бы выявить возможность взаимной блокировки между «своими» процессами. Если тексты недоступны, то можно попытаться предотвращать тупики уже в ходе работы программ, отслеживая их запросы на ресурсы и блокируя либо прекращая те процессы, которые, по-видимому, «лезут в тупик». Самый грубый из подобных подходов заключается в том, что каждый процесс должен захватывать все необходимые ему ресурсы сразу, при старте, после чего он может либо удерживать ресурсы в течение всего времени работы, либо освобождать ресурсы, которые больше не нужны. Такой подход, безусловно, в корне исключает возможность тупиков. К сожалению, на практике он почти исключает и многозадачную работу: многие ресурсы необходимы для работы большинства процессов (например, диски, принтер, системные файлы), поэтому пока один процесс удерживает все ресурсы, другие не смогут даже стартовать. Чуть получше алгоритм нумерованных ресурсов
. Он заключается в том, что все ресурсы, имеющиеся в системе, нумеруются целыми числами в произвольном порядке (хотя, вероятно, для повышения эффективности лучше всего пронумеровать их в порядке возрастания дефицитности ресурса). Далее применяется простое правило: запрос процесса на выделение ему ресурса с номером K удовлетворяется только в том случае, если процесс в данный момент не владеет никаким другим ресурсом с номером N³K. Другими словами, запрос ресурсов следует выполнять только в порядке возрастания номеров. Нетрудно показать, что это правило является достаточным условием отсутствия тупиков. Но это условие слишком ограничивающее, оно отсекает много ситуаций, когда тупик на самом деле не возник бы. Наиболее изящен алгоритм банкира
, предложенный тем же Дейкстрой. В нем предполагается, что каждый процесс при старте должен объявить системе, на какие ресурсы и в каком максимальном количестве он может в будущем претендовать. Далее, вводится понятие безопасного
(в отношении тупиков) состояния системы
. Текущее состояние, в котором имеется набор процессов, каждый из которых владеет некоторыми ресурсами, считается безопасным, если имеющихся в наличии свободных ресурсов достаточно для того, чтобы ОС смогла в определенной последовательности удовлетворить максимальные запросы каждого процесса. Это определение проще понять, если рассмотреть, как проверяется безопасность заданного состояния. Согласно алгоритму, среди имеющихся процессов ищется такой, чьи максимальные заявленные запросы система может удовлетворить, используя имеющиеся свободные ресурсы. Если хотя бы один такой процесс найден, то он вычеркивается из общего списка и все ресурсы, которые он уже успел занять, считаются свободными (т.е. считается, что система смогла завершить этот процесс). Далее, при увеличившихся свободных ресурсах, ищется следующий процесс, чьи запросы система может удовлетворить, и т.д. Если в результате удается вычеркнуть все процессы, то анализируемое состояние системы является безопасным. Сам же алгоритм банкира можно теперь сформулировать очень просто: любой запрос процесса на выделение ему дополнительных ресурсов должен удовлетворяться только в том случае, если состояние, в которое перейдет система после этого выделения, будет безопасным. Название алгоритма навеяно, видимо, образом осторожного банкира, который выдает кредит только в том случае, если после этого сможет выполнить все свои обязательства даже в худшем случае. Явно не российский банкир. Хотя данный алгоритм красив и логичен, у него есть, по меньшей мере, два недостатка. Во-первых, в современных ОС не принято требовать от процессов, чтобы те заранее объявляли свои будущие потребности в ресурсах. Во-вторых, выполнять проверку безопасности состояния при каждом запросе любого из процессов – слишком трудоемкое удовольствие. Рассмотрим, наконец, третий подход – ликвидацию уже возникших тупиков, без попыток предотвратить их возникновение. В книге /2/ этот подход назван «алгоритмом страуса». Здесь, прежде всего, возникает вопрос: как убедиться, что система действительно в тупике? Внешним признаком этого является длительное отсутствие какой-либо активности двух или более процессов. Но это недостоверный признак, процессы могли просто надолго задуматься над каким-нибудь трудоемким вычислением. Есть алгоритмы, которые анализируют текущее состояние процессов и ресурсов, наличие заблокированных запросов, и на этой основе ставят диагноз тупика. В принципе, такой алгоритм мог бы быть встроен в ОС. Однако в литературе нет сведений о том, чтобы это было осуществлено на практике. Обычно полагаются на волевое решение оператора или администратора системы. Но пусть даже точно известно, что тупик есть. Как можно его устранить? Как «растащить баранов с моста»? Как правило, для этого применяется радикальное решение: принудительно прекратить один из тупиковых процессов (сбросить одного барана в реку). Если не помогло – утопить следующего барана. И т.д. В литературе рассматриваются и более гуманные, но сложные способы. В принципе, можно регулярно запоминать состояние всех или только наиболее ответственных процессов в определенных контрольных точках или через определенные периоды времени. Тогда, вместо полного прекращения процесса, его можно вернуть к одной из последних контрольных точек и придержать там, пока другой баран не перейдет через реку. Завершая рассмотрение проблемы тупиков, следует признать, что в настоящее время ее практическое значение значительно меньше, чем хотелось бы теоретикам. Во-первых, совсем не легко загнать в тупик современную ОС, работающую на компьютере с огромными ресурсами. В примере мы рассмотрели тупик, возникший из-за 100 Мб памяти, но если учесть еще несколько гигабайт, которые можно использовать в файле подкачки, то запросы процессов должны быть уж очень велики, чтобы привести к тупику. А, скажем, такое устройство, как принтер, в современных ОС вообще не может стать причиной тупика, т.к. система не отдает его во владение ни одному процессу даже на время. Во-вторых, хотя тупик в принципе остается возможным, пользователь вряд ли даже заметит его. Скорее, он скажет «Опять Windows зависла!» и перезагрузит систему. Предотвращение тупиков остается действительно важным, например, при разработке встроенной системы, которая должна длительное время безотказно работать без вмешательства человека. 4.4.1. Процессы в MS-DOS Как говорилось выше, управление процессами в однозадачных ОС, к которым относится MS-DOS, является сравнительно тривиальной задачей. Загрузка ОС завершается запуском программы командного интерпретатора COMMAND.COM, в задачи которого входит: · чтение и анализ команд, вводимых пользователем с клавиатуры; · выполнение внутренних команд системы, таких, как команда выдачи содержания каталога, команды копирования, удаления и переименования файлов и т.п.; · запуск на выполнение системных и прикладных программ; · обработка критических ошибок, происшедших в ходе выполнения системных функций MS-DOS; · завершение работы программы с освобождением всех ресурсов, занимавшихся программой. Запуская программу пользователя, COMMAND.COM не завершает собственную работу, а фактически переходит в состояние сна. После завершения запущенной программы COMMAND.COM возобновляет работу, выдавая приглашение к вводу следующей команды. Таким же образом программа пользователя может запустить другую программу и ожидать ее завершения. Количество одновременно присутствующих в системе процессов ограничено только размером памяти системы (не более 640 Кб на всех), однако только последняя запущенная программа может быть в активном (работающем) состоянии. Если же и эта программа блокируется на выполнении системной функции (например, ожидает ввода с клавиатуры), то в системе не остается активных процессов. Таким образом, термин «однозадачная ОС» в данном случае следует понимать как «ОС, допускающая не более одной активной задачи». Системе не приходится заниматься разделением процессорного времени и другими «многозадачными» проблемами, за исключением только сохранения и восстановления контекста родительской программы. Некоторым исключением из правила «одна активная задача» являются резидентные программы MS-DOS, рассмотренные в п. 4.4.5. Среда
программы (environment; другой перевод – «окружение») представляет собой текстовый массив, состоящий из строк вида: "переменная=значение", 0 Здесь переменная и значение – любые (в разумных пределах) текстовые величины, байт 0 завершает каждую строку. Понятие среды было введено в системе UNIX и позаимствовано оттуда в MS-DOS и Windows без особых изменений. Имеется несколько стандартных (системных) переменных среды, из которых наиболее известны PATH (определяет пути к каталогам, в которых система ищет исполняемый файл) и PROMPT (задает вид подсказки при диалоге с ОС). Кроме того, многие прикладные программы требуют для правильной работы, чтобы были заданы специфические переменные среды, описывающие, например, размещение рабочих каталогов программы, способ работы с расширенной памятью или какие-то иные характеристики режима работы программы. Можно рассматривать переменные среды как своего рода параметры, передаваемые программе при ее запуске, аналогично тому, как подпрограмма получает параметры при вызове. Интерпретатор команд COMMAND.COM также имеет свою среду, которую называют корневой средой. Для создания переменных корневой среды, их удаления и изменения значений может использоваться системная команда SET. Когда COMMAND.COM запускает программу пользователя или одна программа запускает другую, создается порожденный процесс, который получает собственный экземпляр блока среды, при этом по умолчанию создается точная копия среды родителя, однако можно создать совершенно иную среду. Одной из основных задач, которые должна решать система, является запуск программ на выполнение. Для этого предназначена системная функция Exec, которая может быть вызвана либо программой COMMAND.COM, выполняющей команду пользователя, либо непосредственно программой пользователя, через программное прерывание int 21h. Функция Exec требует указания ряда параметров, из которых важны: · Имя файла запускаемой программы. Если имя не содержит пути к каталогу, то файл ищется в текущем каталоге, а также в каталогах, перечисленных в переменной PATH. · Командная строка. Так принято называть строку параметров, передаваемых программе. При запуске программы по команде пользователя командная строка задается после имени программы, она отделена от имени пробелом. Анализ содержимого командной строки полностью возлагается на запускаемую программу, система лишь передает эту строку программе. · Адрес массива, содержащего параметры среды программы. Если он не задан, то для запускаемой программы создается копия среды программы-родителя. В MS-DOS используются два формата выполняемых программ. Файл формата COM содержит только коды позиционно-независимой программы, которая может быть без изменения загружена для исполнения по любому свободному адресу памяти. Все программа должна помещаться в единственном сегменте, поэтому размер файла ограничен 64 Кб. Файл формата EXE представляет собой перемещаемую программу. Файл состоит из заголовка, словаря перемещений и собственно кода. Информация в заголовке позволяет указать размер части файла, которая должна загружаться в память при запуске программы, максимальный и минимальный размер памяти, дополнительно резервируемой для размещения данных, начальный адрес стека, адрес запуска программы. Размер файла практически не ограничен, но размер загружаемой части должен быть в пределах, предоставляемых DOS, т.е. примерно 500 – 550 Кб. Первые два байта EXE-файла содержат сигнатуру (признак) файла формата EXE, в качестве которой используются две буквы 'MZ'[10]
. Считается, что это инициалы программиста Марка Збиковского, который участвовал в разработке MS-DOS. При запуске программы система выполняет следующие действия: · Выделяет два непрерывных блока памяти: для параметров среды (блок среды) и для самой программы (блок PSP). Для программы, как правило, выделяется максимально возможный непрерывный блок памяти, если только в заголовке EXE-файла не задан меньший размер. · Определяет размер загружаемой части программы (для COM-файла это весь файл), и считывает из файла коды программы. · Для EXE-файла выполняет настройку программы на адрес загрузки, прибавляя этот адрес к тем местам программы, которые перечислены в словаре перемещений. · Формирует в начале блока программы массив, который называется PSP
(ProgramSegmentPrefix). В PSP содержатся, в частности, адрес блока среды, адрес возврата в родительскую программу, адрес и размер таблицы JFT, сама эта таблица, командная строка программы. · Заполняет первые 5 элементов таблицы JFT (стандартные хэндлы), копируя их из JFT родительской программы. · Заносит начальные значения в регистры процессора. · Запоминает адрес PSP программы в качестве идентификатора текущего процесса (PID, ProcessIDentifier). · Наконец, выполняет переход на адрес запуска программы. Для COM-файла этот адрес следует сразу за PSP, для EXE-файла в заголовке может быть указан любой адрес. 4.4.4. Завершение работы программы
Завершение программы обычно включает в себя следующие действия системы: · Закрываются все файлы, открытые программой. · Освобождаются все блоки памяти, отведенные для программы и ее среды. · Восстанавливаются стандартные обработчики описанных ниже прерываний int 23h и int 24h, которые могли быть изменены отработавшей программой. · Управление передается родительской программе. В MS-DOS определены 4 возможные причины, которые могут вызвать завершение работы программы. · Нормальное завершение
. Оно происходит, когда программа вызывает системную функцию Terminate. В качестве аргумента этой функции программа передает код завершения
– число, уточняющее причину завершения. Обычно код завершения 0 означает, что программа проработала благополучно, а ненулевые значения указывают на различные неприятности (отсутствие файла для обработки, неверный формат данных и т.п.). · Завершение по запросу пользователя
. Оно происходит, если пользователь нажимает одну из комбинаций клавиш Ctrl+C или Ctrl+Break. Система не торопится прекращать работу программы, пока не вызовет программное прерывание int 23h. В зависимости от результата, возвращаемого обработчиком этого прерывания, программа либо будет завершена, либо продолжит работу. По умолчанию система сама обрабатывает прерывание и сама себе отвечает: «Завершить программу». Однако программа может взять обработку прерывания на себя и ответить системе: «Продолжаем работать». Так обычно и поступают все серьезные программы MS-DOS. · Завершение по критической ошибке
. Критической считается ошибка, происшедшая в ходе выполнения какой-либо системной функции MS-DOS и имеющая аппаратный характер (точнее, обнаруженная драйвером устройства). Например, отсутствие файла не является критической ошибкой, а ошибка чтения с диска – является. Система вызывает программное прерывание int 24h, передавая как аргументы подробное описание ошибки (на каком устройстве, при какой операции и т.п.). В ответ система хочет получить от обработчика указание, как реагировать на ошибку. Имеется 4 вида реакции: Ignore – игнорировать ошибку; Retry – повторно выполнить операцию, вызвавшую ошибку; Abort – завершить программу; Fail – вернуть код ошибки программе пользователя. Системный обработчик прерывания запрашивает требуемую реакцию у пользователя. Однако программа и в данном случае может взять обработку прерывания на себя и попытаться автоматически выбрать желаемую реакцию на основании описания ошибки. · Завершение с установкой резидента
. Оно похоже на нормальное завершение, но отличается двумя важными особенностями. Во-первых, файлы, открытые программой, не закрываются. Во-вторых, системе возвращается не вся память, занимаемая завершившейся программой. Некоторая часть памяти остается скрытой от системы и может быть использована для размещения резидентных программ, описанных в следующем пункте. Имеется системная функция, с помощью которой родительская программа может проверить причину и код завершения программы-потомка. 4.4.5. Перехват прерываний и резидентные программы
Большая часть всех функциональных возможностей MS-DOS заключается в обработке разнообразных аппаратных и особенно программных прерываний. В частности, обращение к многочисленным системным функциям MS-DOS выполняется с помощью вызова программного прерывания int 21h. Тем важнее оказывается тот факт, что в MS-DOS программа пользователя имеет возможность перехватить любое прерывание, т.е. установить свой обработчик этого прерывания. Фактически для этого достаточно записать адрес нового обработчика по соответствующему адресу памяти. Имеются системные функции для запоминания адреса прежнего обработчика и установки нового. Перехват аппаратных прерываний позволяет программе оперативно реагировать на различные события. Особенно часто перехватываются прерывания от таймера, что позволяет выполнять некоторое действие регулярно, через заданный интервал времени, (скажем, отображать текущее время) или же выполнить его один раз в заранее запланированный момент, а также прерывания от клавиатуры, позволяющие выполнить действие при нажатии определенной комбинации клавиш. Например, одно время были популярны резидентные калькуляторы, которые появлялись на экране при нажатии заданных клавиш. Еще один пример такого рода – программы, переключающие русский/латинский регистры клавиатуры. Перехват программных прерываний позволяет программе модифицировать выполнение любой функции MS-DOS. Выше говорилось об использовании перехвата прерываний для определения реакции программы на нажатие Ctrl+Break и на критические ошибки. Еще одним примером может служить системная программа SHARE.EXE, которая обеспечивает корректное разделение файлов между процессами. Эта программа перехватывает основные файловые функции MS-DOS, чтобы отследить все открытия и закрытия файлов и установку/снятие блокировок. На основании этой информации модифицированные функции открытия, чтения и записи файла определяют, разрешена ли запрошенная операция. Программы, использующие перехват прерываний, можно разбить на два класса. · Нерезидентные программы
, которые после завершения своей работы возвращают управление и всю занимаемую память системе. Такие программы перехватывают прерывания только на время своей работы и должны обязательно восстановить стандартную обработку прерываний при своем завершении. Это требование касается не только нормального завершения, но и завершения по Ctrl+Break и по критической ошибке. В противном случае при последующем возникновении прерывания управление будет передано по адресу уже не существующего в памяти обработчика, а это крах. · Резидентные программы
представляют собой обработчики прерываний, остающиеся в памяти и после завершения загрузившего их процесса, вплоть до перезагрузки системы. Таким образом, резидентные программы могут оказывать влияние на работу MS-DOS и всех запускаемых программ. К какому классу должна принадлежать упомянутая выше программа SHARE.EXE? Не будет ошибкой сказать, что резидентные программы в некоторой степени превращают однозадачную MS-DOS в многозадачную систему. В данном случае реализуется примитивная форма фоново-оперативной диспетчеризации, в которой резидентные программы играют роль оперативных процессов, а обычная работа MS-DOS осуществляется в фоновом режиме. К сожалению, в MS-DOS нет надежных, поддерживаемых системой средств для создания оперативных процессов. Вместо этого есть только возможность перехвата прерываний и еще некоторые полезные, но разрозненные функции, которые дают прикладному программисту возможность «вручную» реализовать многозадачность, но не гарантируют корректности результата. Среди проблем, которые приходится решать разработчику резидентных программ, можно назвать несколько наиболее типичных. · При установке резидентной программы следует проверить, не была ли она уже установлена, поскольку двукратный перехват прерываний одной и той же программой обычно приводит к неверной работе программы. Такую проверку можно выполнить различными способами. Чаще всего используют вызов определенного программного прерывания, которое должно вернуть характерный результат, если оно уже перехвачено. · В MS-DOS нет понятия контекста программы и тем более нет средств переключения контекста. Если работа резидентной программы может привести к изменению таких системных данных, как текущие диск и каталог, информация о последней случившейся ошибке, идентификатор текущего процесса и т.п., то эта программа должна позаботиться о сохранении и восстановлении этих данных, чтобы не помешать нормальной работе фонового процесса. · Почти все функции MS-DOS нереентерабельны, причем даже не по отдельности, а в совокупности, т.е. вызов одной из этих функций при незавершенном выполнении другой может привести к краху системы. Это не вызывает затруднений, пока MS-DOS работает как однозадачная система. Однако активизация резидентной программы может произойти во время выполнения функции DOS, вызванной из фоновой программы. Если резидентная программа также вызовет какую-либо системную функцию (а без этого невозможно, например, работать с файлами), то последствия будут плачевны. Способы обойти это затруднение существуют, но по своей запутанности они больше похожи на рецепты алхимиков. В отличие от «полуторазадачной» MS-DOS, которая оставляет прикладному программисту всю работу (и весь риск) организации параллельного функционирования процессов, многозадачные ОС предоставляют программисту более или менее удобный и богатый набор системных функций, позволяющих запустить несколько параллельных процессов и организовать их взаимодействие (синхронизацию процессов, обмен данными, взаимное исключение и т.п.). При этом ОС обязана гарантировать корректную и эффективную организацию переключения процессов, разделения между ними процессорного времени, памяти и других ресурсов. Сложность проблемы организации взаимодействия параллельных процессов существенно разная для систем, использующих вытесняющую и невытесняющую диспетчеризацию процессов. При вытесняющей диспетчеризации процесс может быть прерван диспетчером практически в любой момент. Помимо задачи сохранения и последующего восстановления контекста процесса (см. п. 4.2.5), которая должна решаться самой ОС, возникают еще и задачи обеспечения взаимного исключения при выполнении критических секций в многозадачных приложениях. Только разработчик программы может решить, какие части текста его программы являются критическими секциями и должны быть защищены семафорами. В системе с невытесняющей диспетчеризацией программисту достаточно проверить, что критические секции не содержат вызовов блокирующих и вытесняющих функций. При этом можно гарантировать, что в ходе выполнения критической секции не произойдет переключения процессов. Все версии Windows от 1.0 до 3.11 представляли собой достаточно мощные многозадачные системы с невытесняющей диспетчеризацией. Версии, начиная с WindowsNT и Windows 95, используют вытесняющую диспетчеризацию. 4.5.1. Понятие объекта в Windows В ОС Windows широко используется понятие системного объекта
. По сути, любой объект представляет собой некоторую структуру данных, расположенную в адресном пространстве системы. Поскольку приложения не могут иметь доступа к этой памяти, то для работы с объектом приложение должно получить хэндл
объекта – некоторое условное число, которое будет представлять данный объект при обращении к API-функциям. Процесс получает хэндл, как правило, при вызове функции CreateXxx (здесь Xxx – название объекта), которая может либо создать новый объект, либо открыть существующий объект, созданный другим процессом. Функции вида OpenXxx позволяют только открыть существующий объект. Объекты Windows делятся на объекты ядра (KERNEL), позволяющие управлять процессами, объекты USER, описывающие работу с окнами, и объекты GDI, задающие графические ресурсы Windows. В данном курсе рассматриваются только объекты ядра. Процессы, нити и открытые файлы являются примерами объектов ядра. Одной из отличительных особенностей объектов ядра являются атрибуты защиты
, которые можно указать при создании объекта. Эти атрибуты определяют права доступа к объекту для различных пользователей и групп. Кроме того, при создании объекта ядра можно задать его имя, которое используется для того, чтобы другие процессы могли открыть тот же объект, зная его имя. Хэндл объекта может быть использован только тем процессом, который создал или открыл этот объект. Нельзя просто переслать значение хэндла другому процессу, оно не будет действовать в другом контексте. Имеется, однако, функция DuplicateHandle, которая создает корректную копию хэндла, требуя указать для этого, какой процесс создает копию, какого именно хэндла и для какого процесса предназначена копия. Если хэндл объекта больше не нужен данному процессу, его следует закрыть с помощью функции CloseHandle, общей для разных типов объектов. Объект существует до тех пор, пока не будут закрыты все хэндлы, указывающие на него. 4.5.2. Процессы и нити
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||