Text
                    СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ

А.В. Рудаков

ОПЕРАЦИОННЫЕ

СИСТЕМЫ
И СРЕДЫ

УЧЕБНИК

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

2.09.02.01 «Компьютерные системы и комплексы»,
2.09 02 05 «Прикладная информатика (по отраслям)»

Москва
КУРС
ИНФРА-М
2027

УДК 004.75(075.8) фз Издание не подлежит маркировке ББК 32.973 2 № 436-Ф3 в соответствии с п. 1 ч. 4 ст. 11 Р83 Рецензенты: П.А Шепелев — заместитель начальника отдела ОАО «Санкт-Петер- бургская судостроительная компания (СПСК)»; Д.В. Охринский — начальник отделения ИМТ АО «Научно-произ- водственная фирма (НПФ) “Меридиан”» Рудаков А.В. Р83 Операционные системы и среды : учебник// Рудаков А.В. — Москва: КУРС' ИНФРА М.2027. — 304 с. — (Среднее профессиональное обра- зование). ISBN 978 5 906923 85 1 (КУРС) ISBN 978-5-16-013639-4 (ИНФРА-М, print) ISBN 978-5-16-106301-9 (ИНФРА-М, online) В учебнике рассматривается история возникновения, современное со- стояние, архитектура, основные принципы организации и перспективы раз- вития операционных систем. Также в учебнике содержится материал, посвя- щенный сервисному программному обеспечению, работе по обслуживанию компьютера и действиям в нештатных ситуациях. Учебник предназначен для студентов средних профессиональных учебных заведений, обучающихся по специальностям 2.09.02.01 (230113) «Компьютерные системы и комплексы», 2.09.02.05 (230701) «Прикладная информатика (по отраслям). Может быть полезен всем, кто интересуется операционными системами и вопросами, связанными с обслуживанием компьютеров. УДК 004.75(075.8) ББК 32.973.2 ISBN 978-5-906923-85-1 (КУРС) ISBN 978 5 16-013639-4 (ИНФРА-М, print) ISBN 978-5-16-106301-9 (ИНФРА-М, online) © Рудаков А.В , 2017 ©КУРС, 2017 Подписано в печать 26.10.2017. Формат 60x90/16. Бумага офсетная. Гарнитура Newton. Печать цифровая. Усл. печ. л. 19,0. Тираж 50 экз. Заказ № 0 ТК 678060-946815-261017 ООО Издательство «КУРС» 127273, Москва, ул. Олонецкая, д. 17А, офис 104. Тел.: (495) 203-57 83. E-mail: kursizdat@gmail.com http://kursizdat.ru Отпечатано в типографии ООО «Научно-издательский центр ИНФРА-М» 127282, Москва, ул. Полярная, д. 31В, стр. 1 Тел.: (495) 280-15-96, 280-33-86. Факс: (495) 280-36-29
ПРЕДИСЛОВИЕ Предложенный вашему вниманию учебник — это первая попытка систематизировать накопленный автором опыт по преподаванию одноименной дисциплины в Петровском колледже города Санкт- Петербурга. При отборе материала для учебника автор руководствовался Го- сударственными образовательными стандартами среднего профес- сионального образования по специальностям 09.02.01 (230113) «Ком- пьютерные системы и комплексы», 09.02.05 (230701) «Прикладная информатика (по отраслям)», 09.02.02 (230111) «Компьютерные сети», 09.02.03 (230115) «Программирование в компьютерных сис- темах», 09.02.04 (230401) «Информационные системы (по отраслям)», а также личным опытом по работе с различными программными продуктами и операционными системами. Основная цель учебника — постараться заполнить пробел, име- ющийся в отечественной учебной литературе по данной дисциплине, особенно после выхода новых стандартов для средних профессио- нальных заведений. Книга состоит из восьми глав. В главе 1 дано описание процесса эволюции операционных систем. Рассмотрена их классификация и особенности развития операционных систем на современном этапе. Глава 2 посвящена рассмотрению назначения и основных функций, реализуемых операционными системами. Материал изло- жен в применении к операционным системам автономных компью- теров и сетевым операционным системам. В главе 3 рассмотрены вопросы, связанные с архитектурой совре- менных операционных систем. Даны сравнительные характеристики разных способов организации архитектур операционных систем и рассмотрены вопросы переносимости операционных систем и со- вместимости программного обеспечения Глава 4 посвящена вопросам организации и планирования выпол- нения процессов и потоков в современных операционных системах, в том числе организации мультипрограммирования и синхронизации выполняемых процессов и потоков. Глава 5 посвящена вопросам управления памятью Рассмотрены основные функции операционной системы по управлению памятью, различные типы адресов, возможные алгоритмы распределения па- мяти и ее организация
В главе 6 рассмотрены вопросы, связанные с организацией под- системы ввода-вывода и файловой системы компьютера. Рассмот- рена многослойная модель подсистемы ввода-вывода и различные, наиболее распространенные файловые системы, такие как FAT, NTFS, ufs. Глава 7 посвящена дисковой операционной системе MS DOS. Рассмотрена ее организация, последовательность ее загрузки, спо- собы перезапуска и основные команды. Также рассмотрены назна- чения и правила написания командных и конфигурационных фай- лов, программная модель микропроцессора и системные функции MS DOS. В главе 8 рассмотрены вопросы, связанные с назначением, опи- санием, классификацией и правилами работы с сервисными про- граммными средствами.. Все главы, кроме главы 8, сопровождены вопросами для контроля знаний.
ВВЕДЕНИЕ Несмотря на то чго на данный момент существует большое число различных операционных систем, между7 ними очень много общего, а различия нс так уж существенны. В основу каждой из них поло- жены определенные концепции и принципы построения, и наиболее удачные встречаются в подавляющем числе операционных систем, мигрируя из одной системы в другую. В результате в большинстве операционных систем используются одни и те же принципы управ- ления ресурсами компьютера, алгоритмы управления памятью, спо- собы планирования и организации выполнения процессов и потоков и т.д. Это позволяет при изучении операционных систем использо- вать подход «от общего к частному», отделяя при этом детали реали- зации от основополагающих идей. В связи с этим в данном учебнике операционные системы рас- сматриваются с самых общих позиций, а списываемые концепции и принципы построения и организации операционных систем спра- ведливы для большинства операционных систем. Целью данного учебника является знакомство читателей с осно- вами операционных систем, сервисным программным обеспече- нием, необходимыми профилактическими работами по обслужива- нию компьютера и оказанием посильной помощи при возникнове- нии нештатных ситуаций во время работы за компьютером.
Глава 1 ЭВОЛЮЦИЯ ОПЕРАЦИОННЫХ СИСТЕМ И ИХ КЛАССИФИКАЦИЯ 1.1. Системное программное обеспечение Системное программное обеспечение (System Software) включает в себя программы и комплексы программ, являющиеся общими для пользователей, кто совместно использует технические средства ком- пьютера, и применяемые как для автоматизации разработки (созда- ния) новых программ, так и для организации процесса выполнения существующих программ. Системное программное обеспечение может быть разделено на следующие пять основных групп: 1) операционные системы (ОС); 2) системы управления файлами; 3) интерфейсные оболочки; 4) системы программирования; 5) утилиты. Рассмотрим вкратце назначение каждой группы системных прог- рамм. Операционные системы. Под операционной системой обычно по- нимают комплекс взаимосвязанных управляющих и обрабатыва- ющих программ, которые, с одной стороны, организуют интерфейс между аппаратурой компьютера и пользователем и запущенными приложениями, а с другой стороны — предназначены для органи- зации наиболее эффективного использования ресурсов компьютера и организации выполнения программ. На рис. 1.1 изображена об- общенная структура программного обеспечения компьютера. Из рисунка видно, что ни один из компонентов программного обеспечения, за исключением самой ОС, не имеет непосредствен- ного доступа к аппаратуре компьютера, а следовательно, любой из компонентов прикладного программного обеспечения обяза- тельно работает под управлением ОС. Пользователи также взаимо- действуют со своими программами и компьютером через интер- фейс ОС.
Рис. 1.1. Обобщенная структура программного обеспечения компьютера Системы управления файлами. Назначение системы управления файлами — организация более удобного доступа к данным, органи- зованным в виде файлов. Благодаря системе управления файлами вместо низкоуровневого доступа к данным с указанием конкретных физических адресов нужной нам записи на физическом носителе используется логический доступ с указанием полного пути и имени файла. Подавляющее большинство современных ОС имеют системы управления файлами, а ряд ОС позволяет работать с несколькими системами управления файлами (либо с одной из нескольких, либо сразу с несколькими одновременно), что позволяет выделить этот вид системного программного обеспечения в отдельную группу. В этом случае говорят о монтируемых системах управления файлами (дополнительную систему управления файлами можно установить), и в этом смысле они самостоятельны. Кроме того, можно назвать примеры простейших ОС, которые вообще могут работать и без систем управления файлами либо могут работать с одной из выбран- ных систем. Однако любая система управления файлами не суще- ствует сама по себе — она разработана для работы в конкретной ОС и с конкретной файловой системой. Другими словами, для работы с файлами, организованными в соответствии с некоторой файловой системой, для каждой ОС должна быть разработана соответствующая
система управления файлами; и эта система управления файлами будет работать только в той ОС, для которой она создана. Интерфейсные оболочки. Для удобства взаимодействия с ОС могут использоваться дополнительные интерфейсные оболочки. Их основ- ное назначение — расширение или изменение возможностей по управлению ОС. В качестве примера интерфейсных оболочек можно указать разнообразные варианты интерфейсов для семейства ОС Windows компании «Microsoft», которые заменяют Explorer и мо- гут напоминать либо UNIX с его графическим интерфейсом, либо OS/2, либо MAC OS. Системы программирования. Системы программирования предна- значены для разработки различного программного обеспечения, в том числе и системного Не бывает самостоятельных (оторванных от ОС) систем прог- раммирования. Любая система программирования может работать только с ОС, под которую она и создана, однако при этом она может позволять разрабатывать программное обеспечение и под другие ОС. Утилиты. Утилиты — это специальные системные программы, с помощью которых можно как обслуживать саму операционную систему, так и подготавливать для работы носители данных, выпол- нять перекодирование данных, осуществлять оптимизацию разме- щения данных на носителе и производить некоторые другие работы, связанные с обслуживанием компьютера. Например, к утилитам относится комплекс программ от фирмы «Symantec», носящий имя Питера Нортона (создателя этой фирмы и соавтора популярного на- бора утилит для первых IBM PC). Утилиты могут работать только в соответствующей операционной среде, под которую они разраба- тывались. 1.2. Появление первых операционных систем Эволюция системного программного обеспечения и операцион- ных систем, в частности, напрямую связана с эволюцией аппаратных средств вычислительной техники, а именно с появлением новой эле- ментной базы, на которой строилось каждое новое поколение ком- пьютеров. В середине 1940-х гг. были созданы первые ламповые вычисли- тельные устройства. Для этих устройств характерно то, что одна и та же группа людей участвовала и в их проектировании, и в даль- нейшей их эксплуатации, и в программировании. Это была скорее научно-исследовательская работа в области вычислительной техники,
а нс использование компьютеров в качестве инструмента решения каких-либо практических задач из других прикладных областей. Программирование осуществлялось исключительно в машинных ко- дах (кодах операций, выполняемых определенным компьютером). Не было никакого системного программного обеспечения, кроме библиотек математических и служебных подпрограмм, которые прог- раммист мог использовать для того, чтобы не писать каждый раз коды, вычисляющие значение какой-либо математической функции или управляющие стандартным устройством ввода-вывода. Опера- ционных систем еще не было, все задачи организации вычислитель- ного процесса решались вручную с пульта управления. Компьютеры выпускались единичными опытными экземплярами и были крайне громоздкими и ненадежными. С середины 1950-х гг., с появлением новой элементной базы — полупроводниковых приборов, начался новый период в развитии вычислительной техники. Это позволило повысить быстродействие процессоров, увеличить объемы оперативной и внешней памяти. Компьютеры стали более надежными, время их непрерывной работы существенно увеличилось, что дало возможность возложить на них выполнение практически важных задач. Компьютеры стали выпус- каться малыми сериями. Наряду с совершенствованием аппаратуры, появились успехи в области автоматизации программирования и организации вычис- лительных работ. Появились первые алгоритмические языки, и к су- ществующим библиотекам математических и служебных подпрог- рамм добавился новый тип системного программного обеспечения — трансляторы, которые предназначались для перевода программ, написанных на алгоритмическом языке (языке высокого уровня), в машинные коды, понятные компьютеру. Выполнение каждой программы стало включать большое количе- ство вспомогательных работ, набивку текста программы; загрузку нужного транслятора (АЛГОЛ, ФОРТРАН, КОБОЛ и т.п.); запуск транслятора и получение результирующей программы в машинных кодах; связывание программы с библиотечными подпрограммами и другими, если это необходимо, оттранслированными частями прог- раммы (компоновка); загрузку программы в оперативную память; запуск программы и вывод полученных результатов на периферийное устройстве. Для организации эффективной работы компьютеров и их эффективного использования произошло разделение труда между сотрудниками вычислительного центра: кто-то писал программы; кто-то занимался вопросами, связанными с обслуживанием вычис-
лительной техники и ее эксплуатацией, а организацией вычислитель- ного процесса занимался специальный сотрудник — оператор ЭВМ, Но как бы быстро и надежно ни работали операторы, они никак не могли состязаться в производительности с работой устройств ком- пьютера. Большую часть времени процессор простаивал в ожидании, пока оператор запустит очередную задачу. А поскольку процессор представлял собой весьма дорогое устройство, то низкая эффектив- ность его использования означала низкую эффективность исполь- зования компьютера в целом. Для решения этой проблемы были разработаны первые системы пакетной обработки, которые автома- тизировали всю последовательность действий оператора по органи- зации вычислительного процесса. Оператор составлял пакет заданий, которые в дальнейшем без его участия последовательно запускались на выполнение управляющей программой — монитором. Кроме того, монитор был способен са- мостоятельно обрабатывать наиболее часто встречающиеся при ра- боте пользовательских программ аварийные ситуации, такие как отсутствие исходных данных, переполнение регистров, деление на ноль, обращение к несуществующей области памяти и т.д. Ранние системы пакетной обработки явились прообразом совре- менных операционных систем, они стали первыми системными про- граммами, предназначенными не для обработки данных, а для управ- ления вычислительным процессом. Системы пакетной обработки значительно сократили затраты времени на вспомогательные действия по организации вычислитель- ного процесса, и тем самым была повышена эффективность исполь- зования компьютера в целом. Однако при этом программисты-поль- зователи лишились непосредственного доступа к компьютеру, что снижало эффективность их работы, — внесение любого исправления требовало значительно больше времени, чем при интерактивной ра- боте за пультом управления компьютера. 1.3. Появление первых мультипрограммных операционных систем В период с 1965 по 1975 г. в технической базе вычислительных ма- шин произошел переход от отдельных полупроводниковых элемен- тов к интегральным микросхемам, что открыло путь к появлению следующего поколения компьютеров. Для этого периода характерно создание семейств программно- совместимых вычислительных машин. Первым семейством про
граммно-совместимых машин, построенных на интегральных мик- росхемах, явилась серия больших машин 1ВМ/360 и IBM/370 (ана- логи этих семейств советского производства — машины серии ЕС), PDP-11 — серия малых машин (советские аналоги — СМ-3, СМ-4, СМ-1420). Построенное в течение этого периода семейство больших и малых машин значительно превосходило машины предыдущего поколения по критерию цена/производительность, и благодаря этому идея создания программно-совместимых машин стала обще- признанной. Программная совместимость требовала и совместимости опера- ционных систем. Такие операционные системы должны были рабо- тать и на больших, и на малых вычислительных машинах, с большим и с малым количеством разнообразной периферии, в коммерческой области и в области научных исследований. Операционные системы, построенные с намерением удовлетворить всем этим противоречи- вым требованиям, оказались чрезвычайно сложными. Однако, несмотря на большую сложность и множество проблем, OS/360 (ОС ЕС для машин серии ЕС) и другие ей подобные опера- ционные системы машин этого поколения действительно удовлетво- ряли большинству требований потребителей. Важнейшим достиже- нием операционных систем данного поколения явилась реализация мультипрограммирования. Мультипрограммирование — это способ организации вычислительного процесса, при котором на одном про- цессоре попеременно выполняются несколько программ. Пока одна программа выполняет операцию ввода-вывода, процессор не про- стаивает, как это происходило при последовательном выполнении программ (однопрограммный режим), а выполняет другую прог- рамму (многопрограммный режим). При этом каждая программа загружается в свой участок оперативной памяти, называемый разде- лом. Другое нововведение — спулинг (spooling). Спулинг в то время определялся как способ организации вычислительного процесса, в соответствии с которым задания считывались с перфокарт на диск в том темпе, в котором они поступали на вычислительный центр, а затем, когда очередное задание завершалось, новое задание с диска загружалось в освободившийся раздел оперативной памяти. В этот период были реализованы практически все основные ме- ханизмы, присущие современным ОС. В эти годы начинается рас- цвет системного программирования. Мультипрограммирование было реализовано в двух вариантах — в системах пакетной обработки и в системах с разделением времени.
Мультипрограммные системы пакетной обработки, так же как и их однопрограммные предшественники, имели своей целью обес- печение максимальной загрузки аппаратуры компьютера, однако решали эту задачу более эффективно. В мультипрограммном пакет- ном режиме процессор нс простаивал, пока одна программа выпол- няла операцию ввода-вывода (как это происходило при последова- тельном выполнении программ в системах ранней пакетной обра- ботки), а переключался на другую готовую к выполнению программу. В результате достигалась сбалансированная загрузка всех устройств компьютера, а следовательно, увеличивалось число задач, решаемых в единицу времени. В мультипрограммных системах пакетной обра- ботки пользователь по-прежнему был лишен возможности интерак- тивно взаимодействовать со своими программами. Вариант мультипрограммирования, применяемый в системах раз- деления времени, рассчитан на многотерминальные системы, когда каждый пользователь работает за своим терминалом, а работа сис- темы нацелена на создание для каждого отдельного пользователя иллюзии единоличного использования вычислительной машины за счет периодического выделения каждой программе своей доли процессорного времени. В системах разделения времени эффектив- ность использования оборудования ниже, чем в системах пакетной обработки, что является своеобразной платой за удобства работы пользователя. Многотерминальный режим использовался не только в системах разделения времени, но и в системах пакетной обработки. При этом не только оператор, но и все пользователи получали возможность фор- мировать свои задания и управлять их выполнением со своего терми- нала. Такие операционные системы получили название систем уда- ленного ввода заданий. Терминальные комплексы могли располагаться на большом расстоянии от процессорных стоек, соединяясь с ними с помощью различных глобальных связей — модемных соединений, телефонных сетей или выделенных каналов. Для поддержания удален- ной работы терминалов в операционных системах появились специ- альные программные модули, реализующие различные (в то время, как правило, нестандартные) протоколы связи. Такие вычислительные системы с удаленными терминалами, сохраняя централизованный характер обработки данных, в какой-то степени являлись прообразом современных сетей, а соответствующее системное программное обес- печение — прообразом сетевых операционных систем. К этому времени можно констатировать существенное изменение в распределении функций между аппаратными и программными
средствами компьютера. Операционные системы становились не- отъемлемыми элементами компьютеров, играя роль «продолжения» аппаратуры. В первых вычислительных машинах программист, на- прямую взаимодействуя с аппаратурой, мог выполнить загрузку программных кодов, используя пульт управления, а затем вручную запустить программу на выполнение, нажав кнопку «пуск». В ком- пьютерах 1960-х гг. большую часть действий по организации вычис- лительного процесса взяла на себя операционная система. В боль- шинстве современных компьютеров нс предусмотрено даже теоре- тической возможности выполнения какой-либо вычислительной работы без участия операционной системы. После включения пита- ния автоматически происходит поиск, загрузка и запуск операцион- ной системы, а в случае ее отсутствия компьютер просто останавли- вается. Реализация мультипрограммирования потребовала внесения очень важных изменений в аппаратуру компьютера, непосред- ственно направленных на поддержку нового способа организации вычислительного процесса. 1.4. Появление первых операционных систем для глобальных сетей В начале 1970- х гг. появились первые сетевые операционные сис- темы, которые, в отличие от многотерминальных ОС, позволяли не только рассредоточить пользователей, но и организовать распре- деленное хранение и обработку данных между несколькими компью- терами, связанными электрическими связями. Любая сетевая опе- рационная система, с одной стороны, выполняет все функции ло- кальной операционной системы, а с другой стороны, обладает некоторыми дополнительными средствами, позволяющими ей взаи- модействовать по сети с операционными системами других компью теров. Программные модули, реализующие сетевые функции, появ- лялись в операционных системах постепенно, по мере развития се тевых технологий, аппаратной базы компьютеров и возникновения новых задач, требующих сетевой обработки. Хотя теоретические работы по созданию концепций сетевого взаимодействия велись почти с самого появления вычислительных машин, значимые практические результаты по объединению ком- пьютеров в сети были получены в конце 1960-х гг., когда с помощью глобальных связей и техники коммутации пакетов удалось реализо- вать взаимодействие машин класса мэйнфреймов и суперкомпьюте-
ров. Эти дорогостоящие компьютеры часто хранили уникальные данные и программы, доступ к которым необходимо было обеспе- чить широкому кругу пользователей, находившихся в различных городах на значительном расстоянии от вычислительных центров. В 1969 г Министерство обороны США инициировало работы по объединению суперкомпьютеров оборонных и научно-исследо- вательских центров в единую сеть. Эта сеть получила название ARPANET и явилась отправной точкой для создания самой из- вестной ныне глобальной сети — Интернета. Сеть ARPANET объе- диняла компьютеры разных типов, работавшие под управлением различных ОС с добавленными модулями, реализующими коммуни- кационные протоколы, общие для всех компьютеров сети. В 1974 г. компания «IBM» («International Business Machines Cor- poration») объявила о создании собственной сетевой архитектуры для своих компьютеров, получившей название SNA (System Network Ar- chitecture). Эта многоуровневая архитектура, во многом подобная стандартной модели OSI (Open System Interconnection), появившейся несколько позже, обеспечивала взаимодействие типа «терминал— терминал», «терминал—компьютер» и «компьютер—компьютер» по глобальным связям. Нижние уровни архитектуры были реализо- ваны специализированными аппаратными средствами. Функции верхних уровней SNA выполнялись программными модулями. Мо- дули работали на центральном процессоре в составе стандартной операционной системы для компьютеров IBM В это же время в Европе велись активные работы по созданию и стандартизации сетей на основе протокола Х.25. Эти сети с комму- тацией пакетов не были привязаны к какой-либо конкретной опера- ционной системе. После получения статуса международного стан- дарта в 1974 г. протоколы Х.25 стали поддерживаться многими опе- рационными системами. С 1980 г компания «1ВМ» включила поддержку протоколов Х.25 в архитектуру SNA и в свои операцион- ные системы. 1.5. Операционные системы мини-компыотеров и первые локальные сети К середине 1970-х гг. наряду с большими компьютерами широкое распространение получили мини-компьютеры, например такие, как PDP-11 (семейство компьютеров, выпускаемых фирмой «DEC» («Digital Equipment Corporation»)). Мини-компьютеры первыми ис- пользовали преимущества больших интегральных схем, позволившие
реализовать достаточно мощные функции при сравнительно невы- сокой стоимости компьютера. Архитектура мини-компьютеров была значительно упрощена по сравнению с большими компьютерами, что нащло отражение и в их операционных системах. Многие функции мультипрограмм- ных многопользовательских ОС больших машин были усечены, учи- тывая ограниченность ресурсов мини-компьютеров. Операционные системы мини-компьютеров часто стали делать специализирован- ными, например только для управления в реальном времени (ОС RT-11 для мини-компьютеров PDP-11) или только для поддер- жания режима разделения времени (RSX-11М для тех же компьюте- ров). Эти операционные системы не всегда были многопользователь- скими. что во многих случаях оправдывалось невысокой стоимостью компьютеров. Важной вехой в истории мини-компьютеров и вообще в истории операционных систем явилось создание ОС UNIX. Первоначально эта ОС предназначалась для поддержания режима разделения вре- мени в мини-компьютере PDP-7. С середины 1970-х гг. началось массовое использование ОС UNIX. К этому времени программный код для UNIX был па 90% написан на языке высокого уровня Си. Широкое распространение эффективных Си-компиляторов сделало UN IX уникальной для того времени операционной системой, обла- дающей возможностью сравнительно легкого переноса на различные типы компьютеров. Поскольку эта ОС поставлялась вместе с исход- ными кодами, то она стала первой открытой ОС, которую могли со- вершенствовать простые пользователи-энтузиасты. Хотя UNIX была первоначально разработана для мини-компьютеров, гибкость, эле- гантность, мощные функциональные возможности и открытость позволили ей занять прочные позиции во всех других классах ком- пьютеров. Доступность мини-компьютеров и вследствие этого их распро- страненность на предприятиях послужили мощным стимулом для создания локальных сетей. Предприятие могло себе позволить иметь несколько мини-компьютеров, находящихся в одном здании или даже в одной комнате. Естественно, возникала потребность в обмене информацией между ними и в совместном использовании дорогого периферийного оборудования. Первые локальные сети строились с помощью нестандартного коммуникационного оборудования, в простейшем случае — путем прямого соединения последовательных портов компьютеров. Прог- раммное обеспечение также было нестандартным и реализовывалось
в виде пользовательских приложений. Первое сетевое приложение для ОС UNIX — программа UUCP (UNIX-to-UNIX Copy program) появилась в 1976 г. и начала распространяться с версией 7 AT&T UN IX с 1978 г. Эта программа позволяла копировать файлы с одного компьютера на другой в пределах локальной сети через различные аппаратные интерфейсы — RS-232, токовую петлю и т.п., а кроме того, могла работать через глобальные связи, например модемные. 1.6. Развитие операционных систем в конце XX века К наиболее важным событиям этого периода можно отнести раз- работку стека TCP/IP (Transmission Control Protocol/ Internet Proto- col), становление Интернета, стандартизацию технологий локальных сетей, появление персональных компьютеров и операционных систем дитя них. Рабочий вариант стека протоколов TCP/IP был создан в конце 1970 -х гг. Этот стек представлял собой набор общих протоколов для разнородной вычислительной среды и предназначался для связи экс- периментальной сети ARPANET с другими «сателлитными» сетями. В 1983 г. стек протоколов TCP/IP был принят Министерством обо- роны США в качестве военного стандарта. Переход компьютеров сети ARPANET на стек TCP/IP ускорила его реализация для опера- ционной системы BSD UNIX. С этого времени началось совместное существование UNIX и прот околов TCP/IP, а практически все мно- гочисленные версии UNIX стали сетевыми. Внедрение протоколов TCP/IP в ARPANET придало этой сети все основные черты, которые отличают современный Интернет. В 1983 г. сеть ARPANET была разделена на две части: MILNET, поддержива- ющую военные ведомства США, и новую ARPANET Для обозна- чения составной сети ARPANET и MILNET стало использоваться название Internet, которое в русском языке со временем преврати- лось в Интернет. Интернет стал отличным полигоном для испытаний многих сетевых операционных систем, позволившим проверить в ре алъных условиях возможности их взаимодействия, способность ра- боты при экстремальной нагрузке, создаваемой сотнями и тысячами пользователей. Стек протоколов TCP/IP также ждала завидная судьба. Независимость от производителей, гибкость и эффектив- ность, доказанные успешной работой в Интернете, а также откры- тость и доступность стандартов сделали протоколы TCP/IP не только главным транспортным механизмом Интернета, но и основным сте- ком большинства сетевых операционных систем.
Начало 1980-х гг. связано с еще одним знаменательным для исто- рии операционных систем событием — появлением персональных компьютеров. С точки зрения архитектуры персональные компью- теры ничем не отличались от класса мини-компьютерсв типа PDP-11, но их стоимость была существенно ниже. Если мини-ком- пьютер позволил иметь собственную вычислительную машину от- делу предприятия или университету, то персональный компьютер дал такую возможность отдельному человеку. Компьютеры стали широко использоваться неспециалистами, что потребовало разработки «дру- жественного» программного обеспечения, и предоставление этих «дружественных» функций стало прямой обязанностью операцион- ных систем. Персональные компьютеры послужили также мощным катализатором для бурного роста локальных сетей, создав для этого отличную материальную основу в виде десятков и сотен компьюте- ров, принадлежащих одному предприятию и расположенных в пре- делах одного здания. В результате поддержка сетевых функций стала для ОС персональных компьютеров необходимым условием. Однако и дружественный интерфейс, и сетевые функции появи- лись у операционных систем персональных компьютеров нс сразу. Первая версия наиболее популярной операционной системы раннего этапа развития персональных компьютеров — MS DOS компании «Microsoft» — была лишена этих возможностей. Это была однопро- граммная однопользовательская ОС с интерфейсом командной строки, способная стартовать с дискеты. Основными задачами для нее были управление файлами, расположенными на гибких и жестких дисках в UNIX-подобной иерархической файловой сис- теме, а также поочередный запуск программ. MS DOS не была за- щищена от программ пользователя, так как процессор Intel 8088 не поддерживал привилегированного режима. Разработчики первых персональных компьютеров считали, что при индивидуальном ис- пользовании компьютера и ограниченных возможностях аппаратуры нет смысла в поддержке мультипрограммирования, поэтому в про- цессоре не были предусмотрены привилегированный режим и другие механизмы поддержки мультипрограммных систем. Недостающие функции для MS DOS и подобных ей ОС компенси- ровались внешними программами, предоставлявшими пользователю удобный графический интерфейс (например, Norton Commander) или средства тонкого управления дисками (например, PC Tools). Наи- большее влияние на развитие программного обеспечения для персо- нальных компьютеров оказала операционная среда Windows компании «Microsoft», представлявшая собой надстройку над MS DOS.
Сетевые функции также реализовывались в основном сетевыми оболочками, работавшими поверх ОС. При сетевой работе всегда необходимо поддерживать многопользовательский режим, при ко- тором один пользователь — интерактивный, а остальные получают доступ к ресурсам компьютера по сети. В таком случае от операци- онной системы требуется хотя бы некоторый минимум функцио- нальной поддержки многопользовательского режима. История сете- вых средств MS-DOS началась с версии 3.1. Эта версия MS DOS добавила к файловой системе необходимые средства блокировки файлов и записей, которые позволили более чем одному пользова- телю иметь доступ к файлу. Пользуясь этими функциями, сетевые оболочки могли обеспечить разделение файлов между сетевыми пользователями. Вместе с выпуском версии MS-DOS3.1 в 1984 г. компания «Micro- soft» также выпустила продукт, называемый Microsoft Networks, ко- торый обычно неформально называют MS-NET. Некоторые концеп- ции, заложенные в MS-NET, успешно перешли и в более поздние сетевые продукты «Microsoft»: LAN Manager, Windows for Workgroups, а затем и в Windows NT. Сетевые оболочки для персональных компьютеров выпускали и другие компании. Иной путь выбрала компания «Novell». Она изначально сделала ставку на разработку операционной системы со встроенными сете- выми функциями и добилась на этом пути выдающихся успехов. Ее сетевые операционные системы NetWare на долгое время стали эта- лоном производительности, надежности и защищенности для ло- кальных сетей. Первая сетевая операционная система компании «Novell» появи- лась на рынке в 1983 г. и называлась OS-Net. Эта ОС предназначалась для сетей, имевших звездообразную топологию, центральным эле- ментом которых был специализированный компьютер на базе мик- ропроцессора Motorola 68000. Немного позже, когда фирма «1ВМ» выпустила персональные компьютеры PC XT, компания «Novell» разработала новый продукт — N etWare 86, рассчитанный на архитек- туру микропроцессоров семейства Intel 8088. С самой первой версии ОС NetWare распространялась как опера- ционная система для центрального сервера локальной сети, которая за счет специализации на выполнении функций файл-сервера обес- печивает максимально возможную для данного класса компьютеров скорость удаленного доступа к файлам и повышенную безопасность данных.
В 1987 г в результате совместных усилий «Microsoft» и «1ВМ» по- явилась первая многозадачная операционная система для персональ- ных компьютеров с процессором Intel 80286, в полной мере исполь- зующая возможности защищенного режима, — OS/2. Эта система была хорошо продумана. Она поддерживала вытесняющую много- задачность, виртуальную память, графический пользовательский интерфейс (не с первой версии) и виртуальную машину для выпол- нения DOS-приложений. Фактически она выходила за пределы про- стой многозадачности с ее концепцией распараллеливания от- дельных процессов, получившей название многопоточности. OS/2 с ее развитыми функциями многозадачности и файловой системой со встроенными средствами многопользовательской за- щиты оказалась хорошей платформой для построения локальных сетей персональных компьютеров Наибольшее распространение получили сетевые оболочки LAN Manager компании «Microsoft» и LAN Server компании «IBM», разработанные этими компаниями на основе одного базового кода. Сетевые разработки компаний «Microsoft» и «1ВМ» привели к по- явлению NetBIOS — очень популярного транспортного протокола и одновременно интерфейса прикладного программирования для локальных сетей, получившего применение практически во всех се- тевых операционных системах для персональных компьютеров. Этот протокол и сегодня применяется для создания небольших локальных сетей. Нс очень удачная рыночная судьба OS/2 не позволила системам LAN Manager и LAN Server захватить заметную долю рынка, но принципы работы этих сетевых систем во многом нашли свое воплощение в более удачливой операционной системе 1990-х гг. — Microsoft Windows NT, содержащей встроенные сетевые компо- ненты, некоторые из которых имеют приставку’ LM — от LAN Mana- ger. В 1980-е гг. были приняты основные стандарты на коммуникаци- онные технологии для локальных сетей: в 1980 г. — Ethernet; в 1985 — Token Ring; в конце 1980-х гг. — FDDI (Fiber Distributed Data Inter- face). Это позволило обеспечить совместимость сетевых операцион- ных систем на нижних уровнях, а также стандартизовать интерфейс ОС с драйверами сетевых адаптеров. В 1990-е гг. практически все операционные системы, занимающие заметное место на рынке, стали сетевыми. Сетевые функции сегодня встраиваются в ядро ОС, являясь ее неотъемлемой частью. Операци- онные системы получили средства для работы со всеми основными
технологиями локальных и глобальных сетей. В операционных сис- темах используются средства мультиплексирования нескольких сте- ков протоколов, за счет которого компьютеры могут поддерживать одновременную сетевую работу' с разнородными клиентами и серве- рами. Появились специализированные ОС, которые предназначены исключительно для выполнения коммуникационных задач. Во второй половине 1990-х гг. все производители операционных систем резко усилили поддержку средств работы с Интернетом (кроме производителей UNIX-систем, в которых эта поддержка всегда была существенной). Кроме самого стека TCP/IP, в комплект поставки начали включать утилиты, реализующие такие популярные сервисы Интернета, как telnet, ftp, DNS и Web. Влияние Интернета проявилось и в том, что компьютер превратился из чисто вычисли- тельного устройства в средство коммуникаций с развитыми вычи- слительными возможностями. Особое внимание в течение всего последнего десятилетия уделя- лось корпоративным сетевым операционным системам. Их дальней- шее развитие представляет одну из наиболее важных задач и в обо- зримом будущем. Корпоративная операционная система отличается способностью хорошо и устойчиво работать в крупных сетях, кото- рые характерны для больших предприятий, имеющих отделения в де- сятках городов и, возможно, в разных странах. К этому времени до- статочно явно определилась тройка лидеров в классе корпоративных ОС — это Novell NetWare 4.x и 5.0, Microsoft Windows NT 4.0 и Win- dows 2000, а также UNIX-системы различных производителей аппа- ратных платформ. Для корпоративной ОС очень важно наличие средств централи- зованного администрирования и управления, позволяющих в единой базе данных хранить учетные записи о десятках тысяч пользователей, компьютеров, коммуникационных устройств и модулей программ- ного обеспечения, имеющихся в корпоративной сети. В совре- менных операционных системах средства централизованного адми- нистрирования обычно базируются на единой справочной службе. Первой успешной реализацией справочной службы корпоративного масштаба была система StreetTalk компании «Banyan». Наибольшее признание получила справочная служба NDS компании «Novell», выпущенная впервые в 1993 г. для первой корпоративной версии NetWare 4.0. Роль централизованной справочной службы настолько велика, что именно по качеству справочной службы оценивают при- годность операционной системы для работы в корпоративном мас- штабе. Длительная задержка выпуска Windows NT 2000 во многом
была связана с созданием для этой ОС справочной службы Active Directory, без которой этому семейству ОС трудно было претендовать на звание истинно корпоративной ОС. Создание многофункциональной масштабируемой справочной службы является стратегическим направлением эволюции ОС. От успехов этого направления во многом зависит и дальнейшее раз- витие Интернета. Такая служба нужна для превращения Интернета в предсказуемую и управляемую систему, например для обеспечения требуемого качества обслуживания графика пользователей, под- держки крупных распределенных приложений, построения эффек- тивной почтовой системы и т.п. 1.7- Особенности современного этапа развития операционных систем На современном этапе развития операционных систем на пе- редний план вышли средства обеспечения безопасности. Это связано с возросшей ценностью информации, обрабатываемой компьюте- рами, а также с повышенным уровнем угроз, существующих при пе- редаче данных по сетям, особенно по публичным, таким как Интер- нет. Многие операционные системы обладают сегодня развитыми средствами защиты информации, основанными на шифрации дан- ных, аутентификации и авторизации. Современным операционным системам присуща многоплатфор- менность, т.е. способность рабогать на совершенно различных типах компьютеров. В последние годы получила дальнейшее развитие долговременная тенденция повышения удобства работы человека с компьютером. Эффективность работы человека становится основным фактором, определяющим эффективность вычислительной системы в целом. Усилия человека не должны тратиться на настройку параметров вы- числительного процесса, как это происходило в ОС предыдущих поколений. Современная операционная система берет на себя выполнение задачи выбора параметров операционной среды, используя для этой цели различные адаптивные алгоритмы. Даже в процессе установки большинство ОС предлагают режим выбора параметров по умолча- нию, который гарантирует пусть не оптимальное, но всегда прием- лемое качество работы систем. Постоянно повышается удобство интерактивной работы с ком- пьютером путем включения в операционную систему развитых гра
фических интерфейсов, использующих наряду с графикой звук и ви- деоизображение. Это особенно важно для превращения компьютера в терминал новой публичной сети, которой постепенно становится Интернет, так как для массового пользователя терминал должен быть почти таким же понятным и удобным, как телефонный аппарат. Пользовательский интерфейс операционной системы становится все более интеллектуальным, направляя действия человека в типовых ситуациях и принимая за него рутинные решения. Уровень удобств в использования ресурсов, которые сегодня пре- доставляют пользователям, администраторам и разработчикам при- ложений операционные системы изолированных компьютеров, для сетевых операционных систем является только заманчивой перспек- тивой. Пока пользователи и администраторы сети тратят значитель- ное время на попытки выяснить, где находится тот или иной ресурс, разработчики сетевых приложений прилагают много усилий для определения местоположения данных и программных модулей в сети. Операционные системы будущего должны обеспечить высо- кий уровень прозрачности сетевых ресурсов, взяв на себя задачу ор- ганизации распределенных вычислений, превратив сеть в виртуаль- ный компьютер. Именно этот смысл вкладывают в лаконичный ло- зунг «Сеть — это компьютер» специалисты компании «Sun», но для превращения лозунга в жизнь разработчикам операционных систем нужно пройти еще немалый путь. 1.8. Классификация операционных систем Операционные системы могут различаться особенностями реа лизации внутренних алгоритмов управления основными ресурсами компьютера (процессорами, памятью и т.д.), особенностями исполь- зованных методов проектирования, типами аппаратных платформ, областями использования и многими другими свойствами. Ниже приведена классификация операционных систем по не- скольким наиболее основным признакам. 1.8.1. Особенности алгоритмов управления ресурсами От эффективности алгоритмов управления локальными ресур- сами компьютера во многом зависит эффективность операционной системы в целом. Поэтому, характеризуя операционную систему, часто приводят важнейшие особенности реализации функций опе- рационной системы по управлению процессором, памятью, внеш-
ними устройствами компьютера. Так, например, в зависимости от особенностей использованного алгоритма управления процессо- ром операционные системы делят на многозадачные и однозадач- ные, многопользовательские и однопользовательские, на системы, поддерживающие многонитевую обработку и не поддерживающие ее, на многопроцессорные и однопроцессорные системы. Поддержка многозадачности. По числу одновременно выполня- емых задач операционные системы могут быть разделены на два класса: • однозадачные (например, MS DOS, PC DOS); • многозадачные (ОС ЕС, OS/2, UNIX, Windows 9х и т.д.). Однозадачные операционные системы в основном выполняют функцию предоставления пользователю виртуальной машины, делая более простым и удобным процесс взаимодействия пользователя с компьютером. Однозадачные операционные системы включают средства управления периферийными устройствами, средства управ- ления файлами, средства общения с пользователем. Многозадачные операционные системы, кроме вышеперечислен- ных функций, управляют разделением между' одновременно выпол- няемыми задачами (процессами) совместно используемых ресурсов, таких как процессор, оперативная память, файлы и внешние устрой- ства. Поддержка многопользовательского режима. По числу одновре- менно работающих пользователей операционные системы де- лятся: • на однопользовательские (MS DOS, Windows 3.x, ранние версии OS/2 и т.д.); • многопользовательские (UNIX, Windows NT и т.д.). Главным отличием многопользовательских систем от однополь- зовательских является наличие средств защиты информации каждого пользователя от несанкционированного доступа других пользовате- лей. Следует заметить, что не всякая многозадачная система является многопользовательской и не всякая однопользовательская операци- онная система является однозадачной. Вытесняющая и невытесняющая многозадачность. Важнейшим раз- деляемым ресурсом является процессорное время. Способ распре- деления процессорного времени между несколькими одновременно выполняемыми в системе процессами (или нитями) во многом опре- деляет специфику операционной системы. Среди множества суще- ствующих вариантов реализации многозадачности можно выделить две группы алгоритмов:
• невытесняющая многозадачность (NetWare, Windows 3.x и т.д.); • вытесняющая многозадачность (Windows NT, OS/2, UNIX и т.д.). Основным различием между вытесняющим и невытесняющим вариантами многозадачности является степень централизации меха- низма планирования процессов. В первом случае механизм плани- рования процессов целиком сосредоточен в операционной системе, а во втором — распределен между системой и прикладными програм- мами. При невытесняющей многозадачности активный процесс (за- дача в процессе выполнения) выполняется до тех пор, пока он сам, по собственной инициативе, не отдаст управление операционной системе для того, чтобы та выбрала из очереди другой готовый к вы- полнению процесс. При вытесняющей многозадачности решение о переключении процессора с одного процесса на другой принима- ется операционной системой, а не самим активным процессом. Поддержка многонитевости. Важным свойством операционных систем является возможность распараллеливания вычислений в рам- ках одной задачи. Многонитсвая операционная система разделяет процессорное время не между задачами, а между их отдельными вет- вями (нитями). Многопроцессорная обработка. Другим важным свойством опера- ционной системы является отсутствие или наличие в ней средств поддержки многопроцессорной обработки — мультипроцессирование. Мультипроцессирование приводит к усложнению всех алгоритмов управления ресурсами. В наши дни становится общепринятым введение в операционную систему функций поддержки многопроцессорной обработки данных. Такие функции имеются в операционных системах Solaris 2.x фирмы «Sun», Open Server 3.x компании «Santa Crus Operations», OS/2 фирмы «IBM», Windows NT фирмы «Microsoft» и NetWare 4.1 фирмы «Novell». Многопроцессорные операционные системы могут классифици- роваться по способу организации вычислительного процесса в сис- теме с многопроцессорной архитектурой: асимметричные операци- онные системы и симметричные операционные системы. Асиммет- ричная операционная система целиком выполняется только на одном из процессоров системы, распределяя прикладные задачи по осталь- ным процессорам. Симметричная операционная система полностью децентрализована и использует все процессоры, разделяя их между системными и прикладными задачами. Выше были рассмотрены характеристики операционных систем, связанные с управлением только одним типом ресурсов — процес- сором. Важное влияние на облик операционной системы в целом,
на возможности ее использования в той или иной области оказывают особенности и других подсистем управления локальными ресур- сами — подсистем управления памятью, файлами, устройствами ввода-вывода. Специфика операционной системы проявляется и в том, каким образом она реализует сетевые функции: распознавание и перена- правление в сеть запросов к удаленным ресурсам; передачу сообще- ний по сети; выполнение удаленных запросов. При реализации се- тевых функций возникает комплекс задач, связанных с распределен- ным характером хранения и обработки данных в сети ведение справочной информации о всех доступных в сети ресурсах и серве- рах; адресация взаимодействующих процессов; обеспечение прозрач- ности доступа; тиражирование данных; согласование копий; под- держка безопасности данных. 1 8.2. Особенности аппаратных платформ На свойства операционной системы непосредственное влияние оказывают аппаратные средства, на которые она ориентирована. По типу аппаратуры различают операционные системы персональ- ных компьютеров, мини-компьютеров, мэйнфреймов, кластеров и сетей ЭВМ. Среди перечисленных типов компьютеров могут встре- чаться как однопроцессорные варианты, так и многопроцессорные. В любом случае специфика аппаратных средств, как правило, отра- жается на специфике операционных систем. Очевидно, что операционная система большой машины является более сложной и функциональной, чем операционная система пер- сонального компьют ера. Так, в операционной системе больших ма- шин функции по планированию потока выполняемых задач, оче- видно, реализуются путем использования сложных приоритетных дисциплин и требуют большей вычислительной мощности, чем в операционных системах персональных компьютеров. Аналогично обстоит дело и с другими функциями. Сетевая операционная система имеет в своем составе средства пе- редачи сообщений между компьютерами по линиям связи, которые совершенно не нужны в операционной системе автономно] о ком- пьютера. На основе этих сообщений сетевая операционная система поддерживает разделение ресурсов компьютера между удаленными пользователями, подключенными к сети. Для поддержания функций передачи сообщений сетевые операционные системы содержат спе- циальные программные компоненты, реализующие популярные ком- муникационные протоколы, такие как IP, IPX, Ethernet и др.
Многопроцессорные системы требуют от операционной системы особой организации, с помощью которой сама операционная сис- тема, а также поддерживаемые ею приложения могли бы выпол- няться параллельно отдельными процессорами системы. Параллель- ная работа отдельных частей операционной системы создаст допол- нительные проблемы для разработчиков операционной системы, так как в этом случае гораздо сложнее обеспечить согласованный доступ отдельных процессов к общим системным таблицам, исключить эф- фект гонок и прочие нежелательные последствия асинхронного вы- полнения работ. Другие требования предъявляются к операционным системам кластеров. Кластер — слабо связанная совокупность нескольких вы- числительных систем, работающих совместно для выполнения об- щих приложений и представляющихся пользователю единой систе- мой. Наряду со специальной аппаратурой, для функционирования кластерных систем необходима и программная поддержка со сто- роны операционной системы, которая сводится в основном к син- хронизации доступа к разделяемым ресурсам, обнаружению отказов и динамической реконфигурации системы. Одной из первых разра- боток в области кластерных технологий были решения компании «Digital Equipment» на базе компьютеров VAX. Недавно этой компа- нией заключено соглашение с корпорацией «Microsoft» о разработке кластерной технологии, использующей Windows NT. Несколько ком- паний предлагают кластеры на основе UNIX-машин. Наряду с операционными системами, ориентированными на со- вершенно определенный тип аппаратной платформы, существуют операционные системы, специально разработанные таким образом, чтобы они могли быть легко перенесены с компьютера одного типа на компьютер другого типа, так называемые мобильные операционные системы. Наиболее ярким примером такой операционной системы является популярная система UNIX. В этих системах аппаратно-зави- симые места тщательно локализованы, так что при переносе системы на новую платформу переписываются только они. Средством, облег- чающим перенос остальной части операционной системы, является написание ее на машинно-независимом языке, например на Си, ко- торый и был разработан для программирования операционных систем. 1.8.3. Особенности областей использования Многозадачные операционные системы подразделяются на три типа в соответствии с использованными при их разработке критери- ями эффективности:
• системы пакетной обработки (например, ОС ЕС); • системы разделения времени (С NIX, VM S); • системы реального времени (QNX, RT/11). Системы пакетной обработки предназначались для решения задач в основном вычислительного характера, нс требующих быстрого по- лучения результатов. Главной целью и критерием эффективности систем пакетной обработки является максимальная пропускная спо- собность, т.е. решение максимального числа задач в единицу времени. Для достижения этой цели в системах пакетной обработки использу- ется следующая схема функционирования: в начале работы форми- руется пакет заданий, каждое задание содержит требование к систем- ным ресурсам; из этого пакета заданий формируется мультипро- граммная смесь, т.е. множество одновременно выполняемых задач. Для одновременного выполнения выбираются задачи, предъявля- ющие отличающиеся требования к ресурсам, так. чтобы обеспечива- лась сбалансированная загрузка всех устройств вычислительной ма- шины; так, например, в мультипрограммной смеси желательно одно- временное присутствие вычислительных задач и задач с интенсивным вводом-выводом. Таким образом, выбор нового задания из пакета заданий зависит от внутренней ситуации, складывающейся в системе, т.е. выбирается «выгодное» задание. Следовательно, в таких операци- онных системах невозможно гарантировать выполнение того или иного задания в течение определенного периода времени. В системах пакетной обработки переключение процессора с вы- полнения одной задачи на выполнение другой происходит только в случае, если активная задача сама отказывается от процессора, на- пример из-за необходимости выполнить операцию ввода-вывода. По- этому одна задача может надолго занять процессор, что делает невоз- можным выполнение интерактивных задач. Таким образом, взаимо- действие пользователя с вычислительной машиной, на которой установлена система пакетной обработки, сводится к тому, что он приносит задание, отдаст его диспетчеру-оператору, а в конце дня после выполнения всего пакета заданий получает результат. Очевидно, что такой порядок снижает эффективность работы пользователя. Системы разделения времени призваны исправить основной недо- статок систем пакетной обработки — изоляцию пользователя-про- граммиста от процесса выполнения его задач. Каждому пользователю системы разделения времени предоставляется терминал, с которого он может вести диалог со своей программой. Так как в системах раз- деления времени каждой задаче выделяется только квант процессор- ного времени, ни одна задача не занимает процессор надолго,
и время ответа оказывается приемлемым. Если квант выбран доста- точно небольшим, то у всех пользователей, одновременно работа- ющих на одной и той же машине, складывается впечатление, что каждый из них единолично использует машину. Ясно, что системы разделения времени обладают меньшей пропускной способностью, чем системы пакетной обработки, так как на выполнение принима- ется каждая запущенная пользователем задача, а не та, которая «вы- годна» системе, и, кроме того, имеются накладные расходы вычис- лительной мощности на более частое переключение процессора с задачи на задачу. Критерием эффективности систем разделения времени является нс максимальная пропускная способность, а удоб- ство и эффективность работы пользователя. Системы реального времени применяются для управления различ- ными техническими объектами, такими, например, как станок, спут- ник, научная экспериментальная установка, или технологическими процессами, такими как гальваническая линия, доменный процесс и т.п. Во всех этих случаях существует предельно допустимое время, в течение которого должна быть выполнена та или иная программа, управляющая объектом, в противном случае может произойти ава- рия: спутник выйдет из зоны видимости; экспериментальные дан- ные, поступающие с датчиков, будут потеряны; толщина гальвани- ческого покрытия не будет соответствовать норме. Таким образом, критерием эффективности для систем реального времени является их способность выдерживать заранее заданные интервалы времени между запуском программы и получением результата (управляющего воздействия). Это время называется временем реакции системы, а со- ответствующее свойство системы — реактивностью. Для этих систем мультипрограммная смесь представляет собой фиксированный на- бор заранее разработанных программ, а выбор программы на выпол- нение осуществляется исходя из текущего состояния объекта или в соответствии с расписанием плановых работ. Некоторые операционные системы могут совмещать в себе свой- ства систем разных типов, например часть задач может выполняться в режиме пакетной обработки, а часть — в режиме реального времени или в режиме разделения времени. В таких случаях режим пакетной обработки часто называют фоновым режимом. 1.8.4. Особенности методов построения При описании операционной системы часто указываются осо- бенности ее структурной организации и основные концепции, по- ложенные в ее основу.
К таким базовым концепциям относятся: способы построения ядра системы — монолитное ядро или ми- кроядерный подход. Большинство операционных систем исполь- зуют монолитное ядро, которое компонуется как одна программа, работающая в привилегированном режиме и использующая быстрые переходы с одной процедуры на другую, не требующие переключения из привилегированного режима в пользователь- ский и наоборот. Альтернативой является построение операци- онной системы на базе микроядра, работающего также в приви- легированном режиме и выполняющего только минимум функций по управлению аппаратурой, в то время как функции операционной системы более высокого уровня выполняют спе- циализированные компоненты операционной системы — сер- веры, работающие в пользовательском режиме. При таком по- строении операционная система работает более медленно, так как часто выполняются переходы между привилегированным режи- мом и пользовательским, зато система получается более гибкой — ее функции можно наращивать, модифицировать или сужать, добавляя, модифицируя или исключая серверы пользовательского режима. Кроме того, серверы хорошо защищены друг от друга, как и любые пользовательские процессы; построение операционных систем на базе объектно-ориентиро- ванного подхода дает возможность использовать все его достоин- ства, хорошо зарекомендовавшие себя на уровне приложений, внутри операционной системы, а именно: аккумуляцию удачных решений в форме стандартных объектов; возможность создания новых объектов на базе имеющихся с помощью механизма насле- дования; хорошую защиту данных за счет их инкапсуляции во внутренние структуры объекта, что делает данные недоступ- ными для несанкционированного использования извне; структу- ризованность системы, состоящей из набора хорошо опреде- ленных объектов; наличие нескольких прикладных сред даст возможность в рамках одной операционной системы одновременно выполнять прило- жения, разработанные для нескольких операционных систем. Многие современные операционные системы поддерживают од- новременно прикладные среды MS DOS, Windows, UNIX (POSIX), OS/2 или хотя бы некоторого подмножества из этого популярного набора. Концепция множественных прикладных сред наиболее просто реализуется в операционных системах на базе микроядра, над которым работают различные серверы,
часть которых реализуют прикладную среду той или иной опера- ционной системы; • распределенная организация операционной системы позволяет упростить работу пользователей и программистов в сетевых средах. В распределенной операционной системе реализованы механизмы, которые дают возможность пользователю представлять и воспри- нимать сеть в виде традиционного однопроцессорного компью- тера. Характерными признаками распределенной организации операционной системы являются: наличие единой справочной службы разделяемых ресурсов, единой службы времени; использо- вание механизма вызова удаленных процедур (RPC) для прозрач- ного распределения программных процедур по машинам, много- нитевой обработки, позволяющей распараллеливать вычисления в рамках одной задачи и выполнять эту задачу сразу на нескольких компьютерах сети, а также наличие других распределенных служб Выводы Эволюция ОС во многом определялась и определяется развитием элементной базы и вычислительной аппаратуры. Первые вычислительные машины появились в 1940 -х гг, рабо- тали без операционных систем, все задачи организации вычисли- тельного процесса решались вручную каждым программистом с пульта управления. Прообразом современных операционных систем явились прог- раммы мониторы, которые автоматизировали действия оператора по выполнению пакета заданий, В 1965—1975 гг. переход к интегральным микросхемам открыл путь к появлению следующего поколения компьютеров. В этот пе риод были реализованы практически все основные концепции, при- сущие современным ОС: мультипрограммирование, мультипроцес- сирование, мнототерминальный режим, виртуальная память, фай- ловые системы, разграничение доступа и сетевая работа. Реализация мультипрограммирования потребовала внесения очень важных изменений в аппаратуру компьютера. В конце 1960-х гг. были начаты работы по созданию глобальной сети ARPANET, явившейся отправной точкой для Интернета, — гло бальной общедоступной сети, которая стала для многих сетевых ОС испытательным полигоном, позволившим проверить в реальных условиях возможности их взаимодействия, степень масштабируемо- сти, способность работы при экстремальной нагрузке.
К середине 1970-х гг. широкое распространение получили мини- компьютеры. Архитектура мини-компьютеров была значительно упрощена по сравнению с большими вычислительными машинами, что нашло отражение и в их ОС. Экономичность и доступность мини-компьютеров послужили мощным стимулом для создания ло- кальных сетей. Предприятие, которое теперь могло позволить себе иметь несколько мини-компьютеров, нуждалось в организации со- вместного использования данных и дорогого периферийного обору- дования. Первые локальные сети строились с помощью нестандарт- ного коммуникационного оборудования и нестандартного прог- раммного обеспечения. С середины 1970-х гг. началось массовое использование UNIX, уникальной для того времени ОС, которая сравнительно легко пере- носилась на различные типы компьютеров. Хотя ОС UNIX была первоначально разработана для мини-компьютеров, ее гибкость, элегантность, мощные функциональные возможности и открытость позволили ей занять прочные позиции во всех классах компьютеров. В конце 1970-х гг. был создан рабочий вариант стека протоколов TCP/IP. В 1983 г. стек протоколов TCP/IP был стандартизован. Не- зависимость от производителей, гибкость и эффективность, дока- занные успешной работой в Интернете, сделали протоколы TCP/IP не только главным транспортным механизмом Интернета, но и ос- новным стеком большинства сетевых ОС. Начало 1980-х гг. связано со знаменательным для истории опера- ционных систем событием — появлением персональных компьюте- ров, которое послужило мощным катализатором для бурного роста локальных сетей, создав для этого отличную материальную основу в виде десятков и сотен компьютеров, расположенных в пределах одного здания. В результате поддержка сетевых функций стала для ОС персональных компьютеров необходимым условием. В 1980-е гг. были приняты основные стандарты на коммуникаци- онные технологии для локальных сетей: в 1980 г. — Ethernet; в 1985 — Token Ring; в конце 1980-х гг. — FDDI. Это позволило обеспечить совместимость сетевых ОС на нижних уровнях, а также стандарти- зовать интерфейс ОС с драйверами сетевых адаптеров. К началу 1990-х гг. практически все ОС стали сетевыми, способ- ными поддерживать работу' с разнородными клиентами и серверами. Появились специализированные сетевые ОС, предназначенные ис- ключительно для выполнения коммуникационных задач Особое внимание в течение всего последнего десятилетия уделя- лось корпоративным сетевым ОС, для которых характерны высокая
степень масштабируемости, поддержка сетевой работы, развитые средства обеспечения безопасности, способность работать в гетеро- генной среде, наличие средств централизованного администрирова- ния и управления. Вопросы для самоконтроля 1. Какие события в развитии технической базы вычислительных машин стали вехами в истории операционных систем? 2. Может ли компьютер работать без операционной системы? 3. Когда были разработаны первые операционные системы? 4. Что явилось прообразом первых операционных систем? 5. Какие функции выполняла программа монитор? 6. Какой язык использовался при программировании первых вычисли- тельных машин? 7. Какое назначение программы компилятор? 8. Приведите пример любого языка высокого уровня. 9. Объясните понятие «программная совместимость». 10. Объясните принцип работы спулинга. 11. Объясните различия между однопользовательской и многопользова- тельской операционными системами. 12. Объясните различия между многозадачными и однозадачными опера- ционными системами. 13. Объясните различия между операционными системами, поддержива- ющими многонитевую обработку, и операционными системами, не поддерживающими такую обработку. 14. Объясните различия между многопроцессорными и однопроцессор- ными операционными системами. 15. Объясните принципы вытесняющей и невытесняющей многозадачно- сти. 16. Объясните принцип работы операционной системы с пакетной обра- боткой заданий. 17. Объясните принцип работы операционной системы с разделением вре- мени. J 8. Объясните принцип работы операционной системы реального времени. 19. В чем отличие операционной системы с монолитным ядром от опера- ционной системы с микроядром? 20. Какие базовые концепции построения операционных систем вы зна- ете?
Глава 2 НАЗНАЧЕНИЕ И ФУНКЦИИ ОПЕРАЦИОННОЙ СИСТЕМЫ На сегодняшний день существует большое число различных опе- рационных систем, которые отличаются друг от друга областями ис- пользования, методами своей реализации, а также аппаратными плат- формами, на которых они могут работать. Такое разнообразие опера- ционных систем обусловливает их значительные функциональные различия, тем более что даже одна и та же операционная система в своей новой версии уже может содержать новые дополнительные функции, которые ранее были реализованы в виде внешних по отно- шению к операционной системе компонентов. Несмотря на такое разнообразие, всем операционным системам присущ целый ряд оди- наковых функций, которые и делают их операционными системами. В данной главе мы попытаемся разобраться с общими для всех опе- рационных систем функциями на примере операционных систем для автономного компьютера и сетевых операционных систем. 2.1. Операционные системы автономного компьютера Операционная система компьютера представляет собой комплекс взаимосвязанных программ, которые обеспечивают интерфейс между приложениями и пользователями, с одной стороны, и аппа- ратурой компьютера, с другой стороны (рис. 2.1). Рис 2.1. Взаимодействие пользователя и программ между собой и аппаратурой компьютера
В соответствии с этим определением операционной системы можно выделить две основные группы функций, реализуемых опе- рационной системой: • предоставление пользователю или программисту расширенной виртуальной машины вместо реальной аппаратуры конкретного компьютера; • повышение эффективности использования компьютера за счет рационального управления его ресурсами. 2 1.1 Расширенная виртуальная машина Любой реальный компьютер способен выполнить только неболь- шой набор команд, определяемый типом используемого в нем мик- ропроцессора. Работа с компьютером на уровне машинного языка очень трудоемка, особенно если она связанна с выполнением задач ввода-вывода Например, для организации чтения блока данных с диска программист может использовать более десяти различных команд, каждая из которых требует множества параметров. Когда выполнение операции с диском завершается, контроллер диска воз- вращает большое число значений, отражающих результат выполне- ния операции, все эти значения надо проанализировать. Не менее трудоемкой была бы и работа пользователя, если бы ему при чтении файла потребовалось задавать числовые адреса данных на диске. На самом деле при работе с диском программисту или пользова- телю достаточно представлять его в виде некоторого набора файлов, каждый из которых имеет свое имя. Работа с файлом в этом случае заключается в его открытии, выполнении чтения или записи, а затем в закрытии файла. Вопросы, связанные с работой конкретной аппа- ратуры, отвечающей за выполнение этих операций, не должны вол- новать программиста или пользователя. Программа, которая скры- вает от программиста или пользователя все нюансы конкретной реализации аппаратуры и предоставляет им возможность простого, удобного просмотра указанных файлов, чтения или записи, — это операционная система. Операционная система берет на себя все ру- тинные операции, связанные с управлением и другими аппаратными устройствами компьютера: физической памятью, таймерами, прин- терами и т.д. Благодаря операционной системе современный поль- зователь или протраммист может обойтись без досконального знания аппаратного устройства компьютера. Для этого операционная сис- тема предоставляет большой набор мощных высокоуровневых функций, скрывающих от пользователя или протраммиста аппарат- ную реализацию конкретного компьютера.
В каждом случае та абстрактная, воображаемая машина, с кото- рой благодаря операционной системе теперь может иметь дело поль- зователь, гораздо проще и удобнее в обращении, чем реальная аппа- ратура, лежащая в основе этой абстрактной машины. С этой точки зрения функцией операционной системы является предоставление пользователю некоторой расширенной или вирту- альной машины, которую легче программировать и с которой легче работать, чем непосредственно с аппаратурой, составляющей реаль- ную машину. 2,1.2. Управление ресурсами Управление ресурсами компьютера с целью наиболее эффектив- ного их использования является одной из основных задач операци- онной системы. Таким образом, операционная система не только обеспечивает пользователям и программистам удобный интерфейс к аппаратным средствам компьютера, но и является механизмом, распределяющим ресурсы компьютера. К числу основных ресурсов компьютера могут быть отнесены та- кие ресурсы, как процессорное время, операт ивная память, магнит- ные диски, принтеры и т.д. Ресурсы распределяются между процес- сами. Процесс (задача) является базовым понятием современных опе- рационных систем и определяется как программа в стадии выполне- ния. Сама программа — это статический объект, представляющий собой файл с кодами про] раммы и исходными данными. Процесс — это динамический объект, который возникает в операционной сис- теме, после того как пользоват ель или сама операционная система решит «запустить программу на выполнение», т.е. создать новую единицу вычислительной работы. Все современные операционные системы мультипрограммные, т.е. операционная система организует одновременное выполнение сразу нескольких процессов на одном компьютере, поочередно пе- реключая процессор с одного процесса на другой, тем самым исклю- чая простои процессора, вызываемые обращением процесса к вводу- выводу. Операционная система также отслеживает и разрешает кон- фликты, возникающие при обращении нескольких процессов к одному и тому же устройству ввода-вывода или к одним и тем же данным. Критерием эффективности, в соответствии с которым операци- онная система организует управление ресурсами компьютера, могут быть разные показатели. Выбор критерия эффективности зависит
от области применения операционной системы, например про- пускная способность или время реакции. Управление ресурсами включает решение следующих общих, не- зависящих от типа ресурса задач: • планирование ресурса, т.е. определение, кому, когда, а для дели- мых ресурсов, и в каком количестве необходимо выделить данный ресурс; • удовлетворение запросов на ресурсы; • отслеживание состояния ресурса, т.е. поддержание оперативной информации о том, занят или не занят ресурс, а для делимых ре- сурсов — какое количество ресурса уже распределено, а какое свободно; • разрешение конфликтов между процессами. Для решения этих общих задач управления ресурсами разные опе- рационные системы используют различные алгоритмы, что в конеч- ном счете и определяет их облик в целом, включая характеристики производительности, область применения и даже пользовательский интерфейс. Так, например, алгоритм управления процессором в зна- чительной степени определяет, является ли операционная система системой разделения времени, системой пакетной обработки или системой реального времени. 2.2. Основные функции операционной системы автономного компьютера Основные функции операционной системы автономного ком- пьютера можно разделить на следующие группы или подсистемы: • подсистема управления процессами; • подсистема управления памятью; • подсистема управления файлами и внешними устройствами; • подсистема управления защитой данных и администрирования; • подсистема интерфейса прикладного программирования; • подсистема пользовательского интерфейса. 2.2.1. Управление процессами Подсистема управления процессами является важнейшей частью операционной системы, непосредственно влияющей на функциони- рование компьютера. Процесс (или, по-другому, задача) — абстракция, описывающая выполняемую программу. Для операционной системы процесс пред- ставляет собой единицу работы, заявку на потребление системных
ресурсов. Подсистема управления процессами планирует выполне- ние процессов, т.е. распределяет процессорное время между не- сколькими одновременно существующими в системе процессами, а также занимается созданием новых и уничтожением завершенных процессов, обеспечивает процессы необходимыми системными ре- сурсами, поддерживает взаимодействие между различными процес- сами. В операционной системе нет однозначного соответствия между программами и процессами. Один и тот же программный файл мо- жет породить несколько процессов, а процесс может в ходе своего выполнения сменить программный файл и начать выполнять другую программу. Чтобы процесс мог быть выполнен, операционная система должна назначить ему область оперативной памяти, в которой будут располагаться коды и данные процесса. А также для каждого вновь создаваемого процесса операционная система создает системные информационные структуры, которые содержат данные о потреб- ностях процесса в системных ресурсах. В мультипрограммной операционной системе одновременно мо- гут существовать несколько процессов. Так как часто различные про- цессы могут претендовать на одни и те же ресурсы, то в обязанности операционной системы входит поддержание очередей заявок про- цессов на ресурсы. Предоставление ресурса процессу осуществляется в соответствии с очередностью его заявки и с учетом степени приви- легированности (приоритета) процесса. Можно выделить два класса процессов: процессы, порожденные по инициативе пользователей, и их приложения — пользовательские процессы и процессы, порож- денные самой операционной системой для выполнения каких-либо своих функций. — системные процессы. Системные процессы всегда имеют более высокий приоритет. Важнейшей задачей операционной системы в управлении про- цессами является защита ресурсов, выделенных данному процессу, от остальных процессов. Также операционная система может не только защищать ресурсы, выделенные одному процессу, но и ор- ганизовывать их совместное использование, например разрешить доступ к некоторой области памяти нескольким процессам. При работе многих современных программных комплексов их работа реализуется в виде параллельной работы нескольких процес- сов, которые периодически взаимодействуют и обмениваются неко- торыми данными. Операционная система должна защищать ресурсы одного процесса от другого, поэтому для организации взаимодей-
ствия между процессами операционная система должна содержать особые средства — средства межпроцессорного взаимодействия, Во время существования процесса его выполнение может быть многократно прервано, а затем продолжено. Для того чтобы возоб- новить выполнение прерванного процесса, операционная система перед его остановкой запоминает всю необходимую системную ин- формацию. Эта информация называется контекстом процесса. Гово- рят, что при смене процесса происходит переключение контекстов, При управлении процессами операционная система также выпол- няет задачу по синхронизации процессов, позволяя процессу при- остановить свое выполнение до наступления какого-либо события в системе, например завершения операции ввода-вывода. Таким образом, подсистема управления процессами выполняет следующие основные задачи: • создает и уничтожает процессы; • планирует выполнение процессов; • обеспечивает процессы необходимыми системными ресурсами; • поддерживает синхронизацию процессов; • обеспечивает взаимодействие между процессами. 2.2.2. Управление памятью Память является важнейшим ресурсом, требующим тщательного управления со стороны операционной системы, так как процесс мо- жет выполняться процессором только в том случае, если его коды и данные (не обязательно все) находятся в оперативной памяти. Рас- пределению подлежит вся оперативная память, не занятая операци- онной системой. Функциями операционной системы по управлению памятью яв- ляются: отслеживание свободной и занятой памяти; выделение па- мяти процессам и освобождение памяти при завершении процессов; защита памяти одного процесса от несанкционированного доступа других процессов; вытеснение процессов из оперативной памяти на диск, когда размеры основной памяти недостаточны для разме- щения в ней всех процессов, и возвращение их в оперативную па- мять, когда в ней освобождается место, а также настройка адресов программы на конкретную область физической памяти. Одним из наиболее распространенных способов управления па- мятью в современных операционных системах является так называ- емая виртуальная память. Наличие в операционной системе меха- низма виртуальной памяти позволяет программисту писать прог- раммы так, как будто в его распоряжении имеется однородная
оперативная память большого объема, зачастую превышающего объем имеющейся физической памяти. В действительности все коды и данные программы хранятся на магнитном диске и по мерс необ- ходимости частями отображаются в оперативную память. При пере- мещении программы между оперативной памятью и диском подсис- тема виртуальной памяти выполняет трансляцию виртуальных адре- сов, полученных в результате компиляции и компоновки программы, в физические адреса ячеек оперативной памяти. 2.2,3. Управление файлами и внешними устройствами Способность операционной системы к сокрытию от пользовате- лей или программистов сложностей реальной аппаратуры особенно хорошо проявляется в подсистеме управления файлами и внешними устройствами. Подсистема управления файлами также называется файловой системой, а подсистема управления внешними устрой- ствами — подсистемой ввода-вывода. Операционная система виртуализирует отдельный набор данных, хранящихся на внешнем накопителе, в виде файла — простой не- структурированной последовательности байтов, имеющих символь- ное имя. Для удобства работы файлы группируются в каталоги, а те, в свою очередь, в каталоги более высокого уровня. С помощью опе- рационной системы пользователь или программист может выпол- нять над файлами и каталогами различные действия, например: со- здание, копирование, удаление, запись, чтение и т.д. При выполнении своих функций файловая система тесно взаи- модействует с подсистемой ввода-вывода, которая по запросам фай- ловой системы осуществляет передачу данных между оперативной памятью и дисками. Подсистема ввода-вывода выполняет роль интерфейса ко всем устройствам, подключенным к компьютеру. Управление устрой- ствами осуществляется с помощью специальных программ, называ- емых драйверами. Для каждого устройства существует своя про1рамма управления — драйвер. Для пользователей важно, чтобы операцион- ная система включала как можно больше разнообразных драйверов, так как это позволит подключить к компьютеру большое количество внешних устройств различных производителей. Поддержание высокоуровневого унифицированного интерфейса прикладного программирования к различным устройствам ввода- вывода является одной из наиболее важных задач операционной системы. Эта задача заключается в том, чтобы обмен с любым внешним устройством вытлядел как обмен с файлом, имеющим имя
и представляющим собой неструктурированную последовательность байтов. 2.2.4. Защита данных и администрирование Безопасность данных обеспечивается средствами от казоустойчи- вости операционной системы. Они обеспечивают выполнение сле- дующих основных задач: • защиту от сбоев и отказов аппаратуры; • защиту от ошибок программного обеспечения; • защиту от несанкционированного доступа (защита данных от ошибочного или злонамеренного поведения пользователей). Функции защиты операционной системы очень тесно связаны с функциями администрирования, так как именно администратор определяет права пользователей при их обращении к разным ресур- сам системы — файлам, каталогам, принтерам и т.п. Кроме того, администратор ограничивает возможности пользователей в выпол- нении тех или иных системных действий. Например, запрет на уста- новку системного времени, запрет на выполнение процедуры завер- шения работы, запрет на изменение прав доступа к некоторым фай- лам или каталогам и т.д. Администратор может также урезать возможности пользовательского интерфейса, убрав, например, не- которые пункты из меню операционной системы, выводимого на дисплей пользователя. Защита данных от несанкционированного доступа начинается с процедуры логического входа в систему. Операционная система должна убедиться, что в систему пытается войти пользователь, вход которого разрешен администратором. Также важным средством за- щиты данных являются функции аудита операционной системы, заключающиеся в фиксировании всех событий, от которых зависит безопасность системы. Список событий, которые необходимо отсле- живать, определяет администратор операционной системы. Поддержка отказоустойчивости реализуется операционной сис- темой, как правило, на основе резервирования. Чаще всего в функции операционной системы входит поддержание нескольких копий данных на разных дисках или разных дисковых накопителях. Резервируются также принтеры и другие устройства ввода-вывода. При отказе одного из избыточных устройств операционная система должна быстро произвести реконфигурацию системы и продолжить работу с резервным устройством. В обязанности администратора также входят действия по поддержке отказоустойчивости системы. С помощью специальных утилит, входящих в состав операционной
системы, администратор должен регулярно выполнять операцию резервного копирования, что в дальнейшем позволит быстро восста- новить необходимые данные. 2.2.5. Интерфейс прикладного программирования Возможности операционной системы доступны прикладному программисту в виде набора функций, называющегося интерфейсом прикладного программирования (Application Programming Interface — API). От обычного пользователя эти функции скрыты за оболочкой пользовательского интерфейса. Для программистов все особенности конкретной операционной системы представлены особенностями ее интерфейса прикладного программирования (API). Поэтому операционные системы с различ- ной внутренней организацией, но с одинаковым набором функций API представляются им одной и той же операционной системой, что значительно упрощает стандартизацию операционных систем и обеспечивает переносимость приложений между различными опе- рационными системами, соответствующими определенному стан- дарту на API. Приложения выполняют обращения к функциям API с помощью системных вызовов. Способ, которым приложения получают услуги операционной системы, очень похож на вызов подпрограмм. Ин- формация, необходимая операционной системе для выполнения вызываемой функции, заранее помещается в определенное место памяти, в регистры процессора и/или стек. Затем управление пере- дается операционной системе, которая выполняет необходимую функцию и возвращает результаты через память, регистры или стек. Каждая выполняемая функция, кроме значений результатов, возвра- щает код ошибки, по которому можно судить о корректности выпол- ненной операции. 2.2.6. Пользовательский интерфейс Операционная система должна обеспечивать удобный интерфейс не только для прикладных программ, но и для пользователя, работа ющего за компьютером, независимо от того, является он програм- мистом, администратором или обычным пользователем. Современные операционные системы поддерживают развитые функции пользовательского интерфейса для интерактивной работы за терминалами двух типов: алфавитно-цифровыми и графическими. При работе за алфавиты)- цифровым терминалом пользователь имеет в своем распоряжении систему команд, мощность которой
отражает функциональные возможности данной операционной сис- темы. Обычно командный язык операционной системы позволяет запускать и останавливать приложения, выполнять различные опе- рации над файлами и каталогами, получать информацию о со- стоянии операционной системы, администрировать систему. Ко- манды могут вводиться не только в интерактивном режиме с терми- нала, но и считываться из так называемого командного файла, содержащего некоторую последовательность команд. Программный модуль операционной системы, отвечающий за чте- ние отдельных команд или же последовательности команд из команд- ного файла, обычно называется командным интерпретатором. Ввод команд может быть упрощен, если операционная система поддерживает графический пользовательский интерфейс. В этом слу- чае пользователь для выполнения нужного действия с помощью мыши выбирает на экране нужный пункт меню или графический символ. 2.3. Сетевые операционные системы Операционная система компьютерной сети во многом аналогична операционной системе автономного компьютера — она также пред- ставляет собой комплекс взаимосвязанных программ, который обес- печивает удобство работы пользователям и программистам путем предоставления им некоторой виртуальной вычислительной сис- темы, реализующей эффективный способ разделения ресурсов между множеством выполняемых в сети процессов. Компьютерная сеть — это набор компьютеров, связанных ком муникационной системой и снабженных соответствующим прог- раммным обеспечением, позволяющим пользователям сети получать доступ к ресурсам этого набора компьютеров. Сеть могут образовы- вать компьютеры разных типов. Коммуникационная система — это набор кабелей и любого дру- гого оборудования, посредством которого осуществляется передача сообщений между любой парой компьютеров. Компьютерная сеть позволяет пользователю работать со своим компьютером как с автономным и добавляет к этому возможность доступа к информационным и аппаратным ресурсам других компью теров сети. При организации сетевой работы операционная система играет роль интерфейса, экранирующего от пользователя все детали низкоуровневых программно-аппаратных средств сети. Сеть превра- щается в достаточно понятный набор разделяемых ресурсов.
В зависимости от того, какой виртуальный образ создает опера- ционная система для того, чтобы подменить им реальную аппаратуру компьютерной сети, различают сетевые операционные системы и распределенные операционные системы. Сетевая операционная система предоставляет пользователю некую виртуальную вычислительную систему, но эта вычислительная сис- тема не полностью скрывает от пользователя распределенную при- роду своего реального прототипа, т.е. является виртуальной сетью. При работе с ресурсами компьютерной сети пользователь сетевой операционной системы всегда помнит, что он имеет дело с сетевыми ресурсами и что для доступа к ним нужно выполнить некоторые осо- бые операции, например перед именем каталога поставить еще и имя компьютера, на котором тот расположен Работая в среде сетевой операционной системы, пользователь хотя и может запустить зада- ние на любом сетевом компьютере, но всегда знает, на каком ком- пьютере будет выполняться его задача. По умолчанию задание всегда выполняется на том компьютере, где пользователь вошел в сеть, иначе надо воспользоваться специальной командой удаленного вы- полнения, в которой необходимо указать информацию, идентифи- цирующую удаленный компьютер. Распределенная сетевая операционная система все ресурсы сети предоставляет пользователю в виде ресурсов единой централизо- ванной виртуальной машины. Распределенная сетевая операционная система, динамически и автоматически распределяя работы по раз- личным машинам системы для обработки, заставляет набор сетевых компьютеров работать как единый виртуальный процессор. Пользо- ватель, вообще говоря, не имеет сведений о том, на каком компью- тере выполняется его работа. В настоящее время практически все сетевые операционные сис- темы еще очень далеки от идеала распределенной операционной системы. Степень автономности каждого компьютера в сети, рабо- тающей под управлением сетевой операционной системы, значи- тельно выше по сравнению с компьютерами, работающими под управлением распределенной операционной системы. В результате сетевая операционная система может рассматри- ваться как набор операционных систем отдельных компьютеров, составляющих сеть. На разных компьютерах сети могут быть уста- новлены одинаковые или различные операционные системы. Но в любом случае операционные системы компьютеров, работа- ющих в сети, должны включать взаимно согласованный набор ком- мутационных протоколов для организации взаимодействия процес-
сов, выполняющихся на разных компьютерах сети, и разделения ресурсов этих компьютеров между пользователями сети. Если операционная система отдельного компьютера позволяет ему работать в сети, т.е. предоставлять свои ресурсы в общее пользо- вание и/или потреблять ресурсы других компьютеров сети, то такая операционная система отдельного компьютера также называется сетевой. Таким образом, термин «сетевая операционная система» исполь- зуется в двух значениях: во-первых, как совокупность операционных систем всех компьютеров сети; во-вторых, как операционная сис- тема отдельного компьютера, способного работать в сети. 2.3.1. Функциональные компоненты сетевой операционной системы В сетевой операционной системе отдельного компьютера можно выделить две части (рис. 2.2): • средства управления локальными ресурсами компьютера реализуют все функции операционной системы автономного компьютера: функции распределения оперативной памяти между процессами, планирования и диспетчеризации процессов, управления процес- сорами в мультипроцессорных машинах, управления периферий- ными устройствами и другие функции управления ресурсами локальных операционных систем; Сетевая операционная система Средства управления локальными ресурсами Сетевые средства Серверная часть Клиентская часть Транспортная часть Сеть Рис. 2.2. Функциональные компоненты сетевой ОС
• сетевые средства, которые, в свою очередь, можно разделить на три компонента: — средства предоставления собственных ресурсов и услуг в общее пользование — серверная часть операционной системы (сер- вер); — средства запроса доступа к удаленным ресурсам и услугам и их использования — клиентская часть операционной системы; — транспортные средства операционной системы, с помощью которых происходит обмен сообщениями в сети. Упрощенно работа сетевой операционной системы происходит следующим образом. Предположим, что пользователь компьютера А решил сохранить свой файл на диске другого компьютера сети — компьютера В. Для этого он набирает соответствующую команду и нажимает клавишу Enter Программный модуль операционной системы, отвечающий за интерфейс с пользователем, принимает эту команду и передает ее клиентской части операционной системы ком- пьютера Л. Клиентская часть операционной системы не может получить не- посредственный доступ к ресурсам другого компьютера. Она может только попросить об этом серверную часть операционной системы, работающую на том компьютере, которому принадлежат эти ре- сурсы. Эти просьбы выражаются в виде сообщений, передаваемых по сети. Сообщения могуч содержать не только команды на выпол- нение некоторых действий, но и собственно данные, например со- держимое файла. Управляют передачей сообщений между клиентской и сервер- ными частями по коммуникационной системе сети транспортные средства операционной системы. Эти средства выполняют такие функции, как формирование сообщений, разбиение сообщения на части, преобразование имен компьютеров в числовые адреса в сети, организация доставки и т.п. Правила взаимодействия ком- пьютеров при передаче сообщений по сети фиксируются в комму- никационных протоколах, таких как Ethernet, Token Ring, TCP/IP, IPX и пр. Чтобы два компьютера смогли обмениваться сообщениями по сети, транспортные средства их операционных систем должны поддерживать некоторый общий набор протоколов. Коммуникаци- онные протоколы переносят сообщения клиентских и серверных частей операционных систем по сети, не вникая в их содержание. На стороне компьютера В должна работать серверная часть опе- рационной системы, постоянно ожидая приходов запросов из сети на удаленный доступ к ресурсам этого компьютера. Серверная часть,
приняв запрос из сети, обращается к локальному диску и записывает на него файл. Конечно, для выполнения этих действий потребуется не одно, а целая серия сообщений, переносящих между компьюте- рами команды операционной системы и части передаваемого файла. 23.2. Сетевые службы и сетевые сервисы Совокупность серверной и клиентской частей операционной сис- темы, предоставляющих доступ к конкретному типу ресурса компью- тера через сеть, называется сетевой службой. Например, если обес- печивается доступ через сеть к файловой системе компьютера, то клиентская и серверные части операционной системы образуют файловую службу. Говорят, что сетевая служба предоставляет пользователям сети некоторый набор услуг, описание этого набора услуг называется сер- висом. Таким образом, сервис — это интерфейс между потребителем услуг и поставщиком услуг (службой). Каждая служба связана с определенным типом сетевых ресурсов и/или определенным способом доступа к этим ресурсам. Например, служба печати обеспечивает доступ пользователей сети к разделя- емым принтерам сети и предоставляет сервис печати, а почтовая служба сети предоставляет доступ к информационному ресурсу сети — электронным письмам. Способом доступа к ресурсам отли- чается, например, служба удаленного доступа — она предоставляет пользователям сети доступ ко всем ее ресурсам через коммутируемые телефонные каналы. Для получения удаленного доступа к конкрет- ному ресурсу, например к принтеру, служба удаленного доступа взаи- модействует со службой печати. Сетевые службы по своей природе являются клиент- серверными системами. Поскольку при реализации любою сетевою сервиса ес- тественно возникает источник запросов (клиент) и исполнитель за- просов (сервер), то и любая сетевая служба содержит в своем составе две несимметричные части — клиентскую и серверную (рис. 2.3). Сетевая служба может быть представлена в операционной системе либо обеими (клиентской и серверной) частями, либо только одной из них. 23.3. Встроенные сетевые службы и сетевые оболочки На практике сложилось несколько подходов к построению сете- вых операционных систем, различающихся глубиной внедрения се- тевых служб в операционную систему (рис. 2.4): • сетевые службы глубоко встроены в операционную систему;
Рис. 2.3. Клиент-серверная природа сетевых служб Рис. 2.4. Варианты построения сетевых ОС • сетевые службы объединены в виде некоторого набора — оболо- чек; • сетевые службы производятся и поставляются в виде отдельного продукта. Первые сетевые операционные системы представляли собой со- вокупность уже существующей локальной операционной системы
с надстроенной над ней сетевой оболочкой. При этом в локальную операционную систему встраивался минимум сетевых функций, не- обходимых для работы сетевой оболочки, которая выполняла основ- ные сетевые функции. Однако в дальнейшем разработчики сетевых операционных систем с самого начала проектировали операционную систему для работы в сети. Сетевые функции у этих операционных систем глу- боко встраивались в основные модули системы, что обеспечивало ее логическую стройность, простоту эксплуатации и модификации, а также высокую производительность. Другой вариант реализации сетевых служб — объединение их в виде некоторого набора (оболочки); при этом все службы такого набора должны быть между собой согласованы, т.е. в своей работе они могуч обращаться друг к другу, могут иметь в своем составе об- щие компоненты. Для работы такой оболочки необходимо наличие некоторой локальной операпионной системы, которая бы выполняла обычные свои функции по управлению аппаратурой компьютера и в среде которой выполнялись бы сетевые службы, составляющие эту оболочку. Оболочка в этом случае представляет собой самостоя- тельный программный продукт. 2.3.4. Одноранговые и серверные сетевые операционные системы В зависимости от того, как распределены функции между ком- пьютерами в сети, они могут выступать в трех разных ролях: • компьютер, занимающийся исключительно обслуживанием за- просов других компьюгеров, играет роль выделенного сервера сети; • компьютер, обращающийся с запросами к ресурсам другого ком- пьютера, исполняет роль клиентского узла; • компьютер, совмещающий функции клиента и сервера, является одноранговым узлом. Очевидно, что сеть не может состоять только из клиентских и только из серверных узлов. Сеть, оправдывающая свое назначение и обеспечивающая взаимодействие компьютеров, может быть по- строена по одной из трех схем: • сеть на основе одноранговых узлов — одноранговая сеть; ' сеть на основе клиентов и серверов — сеть с выделенными серве- рами (двухранговая сеть)', • сеть, включающая узлы всех типов, — гибридная сеть. Каждая из этих схем обладает своими достоинствами и недостат- ками, определяющими их области применения.
2.3.5. Операционные системы в одноранговых сетях В одноранговых сетях (рис. 2.5) все компьютеры равны в правах доступа к ресурсам друг друга. Каждый пользователь может по сво- ему желанию объявить какой-либо ресурс своего компьютера разде- ляемым, после чего другие пользователи могут его эксплуатировать. В таких сетях на всех компьютерах устанавливается одна и та же опе- рационная система, которая предоставляет всем компьютерам в сети потенциально равные возможности. Одноранговые сети могут быть построены, например, на базе ОС LANtastic, Personal Ware, Windows for Workgroup, Windows NT Workstation, Windows 95/98. Компьютер 1 Компьютер 2 Компьютер n Рис. 2,5. Одноранговая сеть: С — серверная часть; К — клиентская часть В одноранговых сетях также может возникнуть функциональная несимметричность: одни пользователи не желают разделять свои ре- сурсы с другими, и в таком случае их компьютеры выполняют роль клиента; за другими компьютерами администратор закрепил только функции по организации совместного использования ресурсов, а значит, они являются серверами; в третьем случае, когда локальный пользователь не возражает против использования его ресурсов и сам не исключает возможности обращения к другим компьютерам, опе- рационная система, устанавливаемая на его компьютере, должна включать и серверную, и клиентскую части. В отличие от сетей с вы- деленными серверами в одноранговых сетях отсутствует специали- зация операционной системы в зависимости от преобладающей функциональной направленности — клиента или сервера. Все ва- риации реализуются средствами конфигурирования одного и того же варианта операционной системы.
Одноранговые сети проще в организации и эксплуатации, однако они применяются в основном для объединения небольших групп пользователей, нс предъявляющих больших требований к объемам хранимой информации, ее защищенности от несанкционированного доступа и скорости доступа. При повышенных требованиях к этим характеристикам более подходящими являются двухранговые сети или сети с выделенными серверами, где сервер лучше решает задачу обслуживания пользователей своими ресурсами, так как его аппара- тура и сетевая операционная система специально спроектированы для этой цели. 2.3.6. Операционные системы в сетях с выделенными серверами Если выполнение каких-либо серверных функций является ос- новным назначением компьютера (например, предоставление фай- лов в общее пользование всем остальным пользователям сети, или организация совместного использования факса, или предоставление всем пользователям сети возможности запуска на данном компью- тере своих приложений), то такой компьютер называется выделенным сервером (рис. 2.6). В зависимости от того, какой ресурс сервера яв- ляется разделяемым, он называется файл-сервером, факс-сервером, принт-сервером, сервером приложений и т.д. Очевидно, что на выделенных серверах желательно устанавливать операционные системы, специально оптимизированные для выпол- нения тех или иных серверных функций. Поэтому в сетях с выделен- ными серверами чаше всего используются сетевые операционные системы, в состав которых входит нескольких вариантов операцион- ных систем, отличающихся возможностями серверных частей. На- пример, сетевая операционная система Novell NetWare имеет сервер- ный вариант, оптимизированный для работы в качестве файл-сер- вера, а также варианты оболочек для рабочих станций с различными локальными операционными системами, причем эти оболочки вы- полняют исключительно функции клиента. Другим примером опе- рационной системы, ориентированной на построение сети с выде- ленным сервером, является операционная система Windows NT. В отличие от NetWare оба варианта данной сетевой операционной системы: Windows NT Server (для выделенного сервера) и Windows NT Workstation (для рабочей станции) — могут поддерживать функции и клиента, и сервера. Е1о серверный вариант Windows NT имеет больше возможностей для предоставления ресурсов своего компьютера другим пользователям сети, так как может выполнять
Рис. 2.6. Сеть с выделенными серверами более широкий набор функций, поддерживает большее количество одновременных соединений с клиентами, реализует централизован- ное управление сетью, имеет более развитые средства зашиты. Выделенный сервер не принято использовать в качестве компью- тера для выполнения текущих задач, не связанных с его основным назначением, так как это может уменьшить производительность его работы как сервера. В связи с такими соображениями в операцион- ной системе Novell NetWare на серверной части возможность выпол- нения обычных прикладных программ вообще не предусмотрена, т.е. сервер не содержит клиентской части, а на рабочих станциях от- сутствуют серверные компоненты. Однако в других сетевых опера- ционных системах функционирование на выделенном сервере кли- ентской части вполне возможно. Например, под управлением Win- dows NT Server могут запускаться обычные программы локального пользователя, кот орые могут потребовать выполнения клиентских
функций операционной системы при появлении запросов к ресурсам других компьютеров сети. При этом рабочие станции, на которых установлена операционная система Windows NT Workstarion, могут выполнять функции невыделенного сервера. Важно понять, что, несмотря на то что в сети с выделенным серве- ром все компьютеры в общем случае могут выполнять одновременно роли и сервера, и клиента, эта сеть функционально несимметрична — аппаратно и программно в ней реализованы два типа компьютеров- одни — в большей степени ориентированные на выполнение сервер- ных функций и работающие под управлением специализированных серверных операционных систем, а другие — в основном выполня- ющие клиентские функции и работающие под управлением соответ- ствующего этому назначению варианта операционных систем. Функ- циональная несимметричность, как правило, вызывает и несиммет- ричность аппаратуры — для выделенных серверов используются более мощные компьютеры с большими объемами оперативной и внешней памяти Таким образом, функциональная несимметричность в сетях с выделенным сервером сопровождается несимметричностью опера- ционных систем (специализация операционных систем) и аппаратной несимметричностью (специализация компьютеров). В больших сетях наряду с отношениями клиент—сервер сохраня- ется необходимость и в одноранговых связях, поэтому такие сети чаще всего строятся по гибридной схеме (рис. 2.7). 2.4. Требования к современным операционным системам Операционная система является сердцевиной программного обеспечения компьютера, она создает среду для выполнения прило- жений и во многом определяет, какими полезными для пользователя свойствами эти приложения будут обладать. В связи с этим рас- смотрим требования, которым должна удовлетворять современная операционная система. Очевидно, что главным требованием, предъявляемым к операци- онной системе, является способность выполнения основных функций: эффективного управления ресурсами и обеспечения удоб- ного интерфейса для пользователя и прикладных программ. Совре менная операционная система, как правило, должна реализовывать мультипрограммную обработку, виртуальную память, поддерживать многооконный интерфейс, а также выполнять многие другие совер- шенно необходимые функции. Кроме этих функциональных требо-
Одноранговые связи Рис. 2.7. Гибридная сеть ваний, к операционным системам предъявляются не менее важные рыночные требования. К этим требованиям относятся; • расширяемость. Код операционной системы должен быть напи- сан таким образом, чтобы можно было легко внести дополнения и изменения, если это потребуется, и не нарушить целостность системы; • переносимость. Код операционной системы должен легко пере- носиться с процессора одного типа на процессор другого типа и с аппаратной платформы (которая включает наряду с типом процессора и способ организации всей аппаратуры компьютера) одного типа на аппаратную платформу другого типа; • надежность и отказоустойчивость. Система должна быть защи- щена как от внутренних, так и от внешних ошибок, сбоев и отка- зов. Ее действия должны быть всегда предсказуемыми, а прило- жения не должны наносить вред операционной системе;
• совместимость. Операционная система должна иметь средства для выполнения прикладных программ, написанных для других операционных систем. Кроме того, пользовательский интерфейс должен быть совместим с существующими системами и стандар- тами; • безопасность. Операционная система должна обладать средствами защиты ресурсов одних пользователей от других; • производительность. Система должна обладать настолько хоро- шим быстродействием и временем реакции, насколько это позво- ляет аппаратная платформа. Выводы ОС — это комплекс взаимосвязанных программ, предназначен- ный для повышения эффективности аппаратуры компьютера путем рационального управления его ресурсами, а также для обеспечения удобств пользователю путем предоставления ему расширенной вир- туальной машины. К числу основных ресурсов, управление которыми осуществляет ОС, относятся процессоры, основная память, таймеры, наборы дан- ных, диски, накопители на магнитных лентах, принтеры, сетевые устройства и некоторые другие. Ресурсы распределяются между про- цессами. Для решения задач управления ресурсами разные ОС ис- пользуют различные алгоритмы, особенности которых в конечном счете и определяют облик ОС. Наиболее важными подсистемами ОС являются подсистемы управления процессами, памятью, файлами и внешними устрой- ствами, а также подсистемы пользовательского интерфейса, защиты данных и администрирования. Прикладному программисту возможности ОС доступны в виде набора функций, составляющих интерфейс прикладного программи- рования (API). Термин «сетевая операционная система» используется в двух зна- чениях: во-первых, как совокупность ОС всех компьютеров сети; во-вторых, как ОС отдельного компьютера, способного работать в сети. К основным функциональным компонентам сетевой ОС отно- сятся средства управления локальными ресурсами и сетевые сред- ства. Последние, в свою очередь, можно разделить на три компо- нента: средства предоставления локальных ресурсов и услуг в общее пользование — серверная часть ОС; средства запроса доступа к уда-
ленным ресурсам и услугам — клиентская часть ОС (редиректор) и транспортные средства ОС, которые совместно с коммуникацион- ной системой обеспечивают передачу сообщений между компьюте- рами сети. Совокупность серверной и клиентской частей, предоставляющих доступ к конкретному типу ресурса компьютера через сеть, называ- ется сетевой службой. Сетевая служба предоставляет пользователям сети набор услуг — сетевой сервис. Каждая служба связана с опреде- ленным типом сетевых ресурсов и/или определенным способом до- ступа к этим ресурсам. Наиболее важными для пользователей сете- вых ОС являются файловая служба и служба печати Сетевые службы могут быть либо глубоко встроены в ОС, либо объединены в виде некоторой оболочки, либо поставляться в виде отдельного продукта. В зависимости от того, как распределены функции между ком- пьютерами сети, они могут выступать в трех разных ролях. Компью- тер, занимающийся исключительно обслуживанием запросов других компьютеров, играет роль выделенного сервера сети. Компьютер, обращающийся с запросами к ресурсам другой машины, исполняет роль клиентского узла. Компьютер, совмещающий функции клиента и сервера, является одноранговым узлом. Одноранговые сети состоят только из одноранговых узлов. При этом все компьютеры в сети имеют потенциально равные возмож- ности. Одноранговые ОС включают как серверные, так и клиентские компоненты сетевых служб. Одноранговые сети проще в организа- ции и эксплуатации, по этой схеме организуется работа в небольших сетях, в которых количество компьютеров не превышает 19—20. В сетях с выделенными серверами используются специальные варианты сетевых ОС, оптимизированные для работы в роли либо серверов, либо клиентов. Для серверных ОС характерны поддержка мощных аппаратных платформ, в том числе мультипроцессорных, широкий набор сетевых служб, поддержка большого числа одновре- менно выполняемых процессов и сетевых соединений, наличие раз- витых средств защиты и средств централизованного администриро- вания сети. Клиентские ОС, в общем случае являясь более прос- тыми, должны обеспечивать удобный пользовательский интерфейс и набор редиректоров, позволяющий получать доступ к разнообраз- ным сетевым ресурсам. В число требований, предъявляемых сегодня к сетевым ОС, вхо- дят: функциональная полнота и эффективность управления ресур- сами; модульность и расширяемость; переносимость и многоплат- формснность; совместимость на уровне приложений и пользоватсль-
ских интерфейсов; надежность и отказоустойчивость; безопасность и производительность. Вопросы для самоконтроля 1. Поясните определение операционной системы как расти иренной вир- туальной машины. 2. В соответствии с определением операционной системы ее главными функциями являются предоставление удобства пользователю и эффек- тивное управление ресурсами компьютера. Какая из этих двух групп функций должна доминировать в мультипрограммных операционных системах больших компьютеров? А в операционных системах первых персональных компьютеров? Объясните почему. 3. В чем состоит отличие в виртуальных машинах, предоставляемых опе- рационной системой простому пользователю и прикладному програм- мисту? 4. Перечислите основные типы ресурсов современных компьютеров. 5. В чем состоит отличие между понятиями «программа» и «процесс»? 6. Назови ге общие задачи операцион] юй системы гго управлег гию любым типом ресурса. 7. Перечислите основные подсистемы операционной системы автоном- ного компьютера. 8. С какой целью операционная система создает системные информаци- онные структуры? 9. Какие классы процессов вы знаете? 10. Какой из классов процессов имеет наивысший приоритет? 11. Какую иг гформацию содержит контекст прог гесса? 12. Какие основные задачи выполняются операционной системой при управлении процессами? 13. Какие основные задачи выполняются операционной системой при управлении памятью? 14. Объясните назначение виртуальной памяти. 15. Объясните назначение программ драйверов. 16. Какие основные задачи выполняются средствами отказоустойчивости операционной системы? 17. Для чего используется резервирование данных? 18. Кто использует функции API — пользователь или ггрограммист? 19. Каким образом происходит вызов функций API? 20. Какой минимум функциональных возможностей надо добавить к ло- кальной операционной системе, чтобы она стала сетевой? 21. В чем заключается отличие между сетевой операционной системой и расггредеденной операционной системой? 22. Какие из утверждений верны: а) сетевая операционная система — это совокупность операционных систем всех комггьютеров сети;
б) сетевая операционная система — это операционная система отдель- ного компьютера, способного работать в сети; в) сетевая операционная система — это набор сетевых служб выпол- ненных в виде оболочки? 23. Перечислите основные сетевые службы. 24. Поясните значение следующих терминов применительно к сетевым операционным системам: «сервис», «сервер», «клиент», «служба», «услуга». 25. Может ли сетевая оболочка работать над сетевой операционной систе- мой? 26. Какие из утверждений верны: а) операционная система выделенного сервера никогда не содержит клиентских частей сетевых служб; б) в одноранговых операционных системах всегда имеются и клиент- ские, и серверные части сетевых служб; в) в сетях с выделенными серверами могут поддерживаться одноран- говые связи? 27. Может ли выделенный сервер обращаться с запросами к ресурсам кли- ентских станций? 28. Приведите примеры одноранговых операционных сетей и операцион- ных сетей с выделенным сервером. 29. Какие основные требования предъявляются к современным операци- онным системам? Объясните эти требования.
Глава 3 АРХИТЕКТУРА ОПЕРАЦИОННОЙ СИСТЕМЫ Любая сложная система, в том числе и операционная, должна иметь понятную и рациональную структуру, которая может быть раз- делена на отдельные функционально законченные части — модули. Ясное понимание назначения каждого отдельного модуля и правил взаимодействия между ними способствует возможности быстрой модификации и дальнейшего развития системы. Функциональная сложность операционной системы неизбежно приводит к сложности ее архитектуры, под которой понимают струк- турную организацию операционной системы на основе различных программных модулей. Большинство современных операционных систем представляют собой хорошо структурированные модульные системы, в которые изначально заложены способности к дальнейшему развитию, рас- ширению и переносу на новые платформы. Какой-либо единой ар- хитектуры операционных систем не существует, но существуют уни- версальные подходы к структурированию операционных систем. 3.1. Ядро и вспомогательные модули операционной системы Обобщенная структура операционной системы подразумевает разделение всех ее модулей на две основных группы: • ядро — модули, выполняющие основные функции операционной системы; • модули, выполняющие вспомогательные функции операционной системы. Модули ядра выполняют такие базовые функции операционной системы, как управление процессами, памятью, устройствами ввода- вывода и т.п. Без ядра операционная система является полностью не- работоспособной и не сможет выполнить ни одну из своих функций. Функции, составляющие ядро операционной системы, можно разделить на функции, решающие внутрисистемные задачи по орга-
низации вычислительного процесса и недоступные для приложений, и функции, служащие для поддержки приложений, создающие для них так называемую прикладную программную среду. Благодаря этим функциям приложения могут обращаться к ядру с запросами — си- стемными вызовами — для выполнения тех или иных действий, на- пример открытия и чтения файла, получения системного времени и т.п. Эти функции образуют интерфейс прикладного программиро- вания — API. Функции ядра являются наиболее часто используемыми функ- циями операционной системы, поэтому скорость их выполнения определяет производительность всей системы в целом. Для обеспе- чения высокой производительности операционной системы все мо- дули ядра или большая их часть постоянно находятся в оперативной памяти компьютера, т.е. являются резидентными. Остальные модули операционной системы, а именно вспомога- тельные функции, выполняют очень полезные, но менее обязатель- ные функции операционной системы. Например, к таким функциям могут быть отнесены программы дефрагментации диска, текстового редактора, резервного копирования данных и т п. Вспомогательные модули операционной системы можно разде- лить на следующие группы: • утилиты — программы, решающие отдельные задачи управления и сопровождения компьютерной системы, например программа сжатия дисков и т.п.; • системные обрабатывающие программы — текстовые или графи- ческие редакторы, компиляторы, компоновщики, отладчики; • программы предоставления пользователю дополнительных услуг — специальный вариант пользовательского интерфейса, программа калькулятора, игры; • библиотеки процедур {функции) различного назначения, упроща- ющих разработку приложений, например библиотека математи- ческих функций и т.п. Как и обычные приложения, для выполнения своих задач вспо- могательные модули операционной системы обращаются к функ- циям ядра посредством системных вызовов. Вспомогательные мо- дули обычно загружаются в оперативную память компьютера только на время выполнения своих функций, т.е. являются транзитными. Обычно ядро операционной системы оформляется в виде прог- раммного модуля некоторого специального формата, отличающегося от формата пользовательских приложений. Часть компонентов опе- рационной системы оформляются как обычные приложения,
т.е. в виде исполняемых модулей стандартного для данной операци- онной системы формата. Тем самым бывает очень сложно провести четкую грань между операционной системой и приложениями (рис. 3.1). Решение о том, является ли какая-либо программа частью операционной системы или нет, принимает разработчик операцион- ной системы. Некоторая программа вначале может существовать как пользовательское приложение, а потом стать частью операционной системы, или наоборот. Например, Web-браузер компании «Micro- soft», который вначале был отдельным приложением, а, начиная с Windows NT 4.0 и Windows 95/98, стал частью операционной сис- темы. (2) Пользовательские приложения Вспомогательные модули ОС Рис. 3.1. Нечеткость границ между ОС и приложениями 3.2. Ядро в привилегированном режиме Для надежного управления ходом выполнения приложений опе- рационная система должна иметь по отношению к приложениям определенные привилегии. Иначе некорректно работающее прило- жение может вмешаться в работу операционной системы и, напри- мер, разрушить часть ее кодов. Операционная система должна обла- дать исключительными полномочиями также для того, чтобы играть роль арбитра в споре приложений за ресурсы компьютера в мульти- программном режиме. Ни одно приложение не должно иметь воз- можности без ведома операционной системы получить дополнитель- ную область памяти, занимать процессор дольше разрешенного опе-
рационной системой периода времени, непосредственно управлять совместно используемыми внешними устройствами. Обеспечить привилегии операционной системы невозможно без специальных средств аппаратной поддержки. Аппаратура компью- тера должна поддерживать как минимум два режима работы — поль- зовательский режим (user mode) и привилегированный режим, который также называют режимом ядра (kernel mode) или режим супервизора (supervisor mode). Подразумевается, что операционная система или некоторая ее часть работает в привилегированном режиме, а прило- жения — в пользовательском режиме Так как ядро выполняет все основные функции операционной системы, то чаще всего именно ядро становится той частью операционной системы, которая рабо- тает в привилегированном режиме (рис. 3.2). Рис. 3.2. Архитектура ОС с ядром в привилегированном режиме Приложения становятся в подчиненное положение за счет за- прета выполнения в пользовательском режиме некоторых критичных команд, связанных с переключением процессора с задачи на задачу, управлением устройствами ввода-вывода, доступом к механизму рас- пределения и защиты памяти. Выполнение некоторых команд в пользовательском режиме запрещается безусловно (очевидно, что к таким командам относится команда перехода в привилегирован- ный режим), тогда как другие запрещается выполнять только при определенных условиях. Важно, что условия разрешения выполне- ния критичных команд находятся под полным контролем операци- онной системы и этот контроль обеспечивается за счет набора ко- манд, безусловно запрещенных для пользовательского режима. На- пример, выполнение команды доступа к памяти для приложения
разрешается, если команда обращается к области памяти, отведен- ной данному приложению операционной системой, и запрещается при обращении к областям памяти, занимаемым операционной си- стемой или другими приложениями. Повышение устойчивости операционной системы, обеспечива- емое переходом ядра в привилегированный режим, достигается за счет некоторого замедления выполнения системных вызовов. Си- стемный вызов привилегированного ядра инициирует переключение процессора из пользовательского режима в привилегированный, а при возврате к приложению — переключение из привилегирован- ного режима в пользовательский (рис. 3.3). Во всех типах процессо- ров из-за дополнительной двукратной задержки переключения пе- реход на процедуру со сменой режима выполняется медленнее, чем вызов процедуры без смены режима. режимов Рис. 3.3. Смена режимов при выполнении системного вызова к привилегированному ядру Архитектура операционной системы, основанная на привилеги- рованном ядре и приложениях, работающих в пользовательском ре- жиме, стала, по существу, классической. Ее используют многие по- пулярные операционные системы, например UNIX, OS/2, Windows NT и т.д В некоторых случаях для повышения быстродействия разработ- чики операционной системы отступают от этого классического ва- рианта архитектуры, организуя работу ядра и приложений в одном и том же режиме. Так, например, сетевая операционная система Net- Ware компании «Novell» использует привилегированный режим про- цессора как для работы ядра, так и для работы своих специфических приложений. В этом случае повышается быстродействие, но снижа-
ется надежность операционной системы, которая компенсируется за счет тщательной отладки каждого приложения. В одном режиме работают также ядро и приложения тех операци- онных систем, которые разработаны для процессоров, вообще не под- держивающих привилегированного режима работы. Наиболее попу- лярным процессором такого типа был процессор Intel 8088/86, послу- живший основой для персональных компьютеров компании «1ВМ». Операционная система MS DOS, разработанная компанией «Micro- soft» для этих компьютеров, состояла из двух модулей msdos.sys и io.sys, составляющих ядро системы, к которым с системными вы- зовами обращались командный интерпретатор command.com, сис- темные утилиты и приложения. Некорректно написанные приложе- ния вполне могли разрушить основные модули MS DOS, что иногда и происходило. Аналогичными операционными системами являются системы MSX, СР/М, PC DOS и т.п. Появление в более поздних версиях процессоров фирмы «Intel» (начиная с 80286) возможности работать в привилегированном ре- жиме не было использовано разработчиками MS DOS. Эта операци- онная система всегда работала на процессорах данного типа в так называемом реальном режиме, в котором эмулируется процессор 8088/86. Не следует считать, что реальный режим является синони- мом пользовательского режима, а привилегированный режим — его альтернативой. Реальный режим был реализован только для совмес- тимости поздних моделей процессоров с ранней моделью 8088/86 и альтернативой ему является защищенный режим работы процессора, в котором становятся доступны все особенности процессоров поздних моделей. 3.3. Многослойная структура операционной системы Компьютер, работающий под управлением операционной системы на основе ядра, можно рассматривать как систему, состоящую из трех иерархически расположенных слоев, нижний слой образует аппара- тура; промежуточный — ядро, а утилиты, обрабатывающие программы и приложения, составляют верхний слой системы (рис. 3.4). Слоистая структура в виде системы концентрических окружностей иллюстри- рует тот факт, что каждый слой может взаимодействовать только со смежными слоями. В соответствии с такой структурой система со- стоит из иерархии слоев. Каждый слой обслуживает вышележащий слой, выполняя для него некоторый набор функций, которые обра-
Ядро ОС Рис, 3.4. Трехслойная структура зуют межслойный интерфейс (рис. 3.5) На основе функций нижеле- жащего слоя следующий (верхний по иерархии) слой строит свои функции — более сложные и более мощные, которые, в свою очередь, К слою к т 2 К слою к - 1 Рис. 3.5. Многослойное взаимодействие
оказываются примитивами для создания еще более мощных функций вышележащего слоя. Строгие правила касаются только взаимодей- ствия между слоями системы, а между модулями внутри слоя связи могут быть произвольными. Отдельный модуль может выполнить свою работу либо самостоятельно, либо обратиться к другому модулю своего слоя, либо обратиться за помощью к нижележащему слою через мсжслойный интерфейс. Такая организация имеет ряд достоинств. Она существенно упро- щает разработку системы, так как позволяет сначала определить «сверху вниз» функции слоев и межслойные интерфейсы, а затем при детальной реализации постепенно наращивать мощность функций слоев, двигаясь «снизу вверх». Кроме того, при модернизации сис- темы можно изменять модули внутри слоя без необходимости про- изводить какие-либо изменения в остальных слоях, если при этих внутренних изменениях мсжслойные интерфейсы остались в силе. Поскольку ядро операционной системы представляет собой слож- ный многофункциональный комплекс, то многослойный подход обычно распространяется и на структуру ядра. Ядро может состоять из следующих слоев (рис. 3.6). Рис. 3.6. Многослойная архитектура ядра ОС: 1 — средства аппаратной поддержки ОС; 2 — машинно зависимые модули; 3 — базовые механизмы ядра; 4 — менеджеры ресурсов; 5 — интерфейс сис- темных вызовов Средства аппаратной поддержки операционной системы. До сих пор об операционной системе говорилось как о комплексе программ, хотя часть функций операционной системы может выполняться и аппаратными средствами. В этом случае речь идет не о всей аппа-
ратуре компьютера, а только об аппаратуре, непосредетвенно участ- вующей в организации вычислительного процесса. Например, сред- ства поддержки привилегированного режима, система прерываний, средства защиты памяти и т.п. Машинно зависимые компоненты операционной системы. Этот слой образуют программные модули, в которых отражается специфика аппаратной платформы компьютера. За счет этого слоя происходит полное экранирование вышележащих слоев ядра от особенностей аппаратной реализации, тем самым позволяя разрабатывать выше- лежащие слои на основе машинно независимых модулей. Базовые механизмы ядра. Этот слой выполняет наиболее прими- тивные операции ядра. Модули данного слоя не принимают решений о распределении ресурсов — они только отрабатывают принятые «наверху» решения, что и дает повод называть их исполнительными механизмами для модулей верхних слоев. Менеджеры ресурсов. Этот слой состоит из мощных функцио- нальных модулей, реализующих стратегические задачи по управ- лению основными ресурсами компьютера. Обычно на данном слое работают менеджеры (диспетчеры) процессов, ввода-вывода, фай- ловой системы и оперативной памяти. Интерфейс системных вызовов. Этот слой является самым верх- ним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интер- фейс операционной системы. Приведенное разбиение ядра операционной системы на слои яв- ляется достаточно условным. В реальной системе количество слоев и распределение функций между ними могу г быть и иными. 3.4. Аппаратная зависимость и переносимость операционных систем Многие операционные системы успешно работают на различных аппаратных платформах без существенных изменений в своем со- ставе. Во многом это объясняется тем, что, несмотря на различия в деталях, средства аппаратной поддержки операционной системы большинства компьютеров приобрели сегодня много типовых черт, а именно эти средства в первую очередь влияют на работу компонен- тов операционной системы. В результате в операционной системе можно выделить достаточно компактный слой машинно зависимых компонентов ядра и сделать остальные слои операционной системы общими для различных аппаратных платформ.
3.4.1. Типовые средства аппаратной поддержки операционной системы Четкой границы между программной и аппаратной реализацией функций операционной системы не существует, но, тем не менее, практически все современные аппаратные платформы имеют неко- торый типичный набор средств аппаратной поддержки операцион- ной системы, в который входят следующие компоненты: • средства поддержки привилегированного режима; • средства трансляции адресов; • средства переключения процессов; • система прерываний; • системный таймер, • средства защиты областей памяти. Средства поддержки привилегированного режима обычно основаны на системном регистре процессора, часто называемом регистром слова состояния процессора. Этот регистр содержит некоторые при- знаки, определяющие режимы работы процессора, в том числе и признак текущего режима привилегий. Смена режима привилегий выполняется за счет изменения слова состояния в результате преры- вания или выполнения привилегированной команды. Е обязанности средств поддержки привилегированного режима входит выполнение проверки допустимости выполнения активной программой команд процессора при текущем уровне привилегированности. Средства трансляции адресов выполняют операции преобразо- вания виртуальных адресов (условные адреса, выработанные транс- лятором), которые содержатся в кодах процесса, в адреса физической памяти (номера ячеек физической памяти компьютера). Средства переключения процессов предназначены для быстрого сохранения контекста приостанавливаемого процесса и восстанов- ления контекста процесса, который становится активным. Система прерываний позволяет компьютеру реагировать на внешние события, синхронизировать выполнение процессов и ра- боту устройств ввода-вывода, быстро переходить с одной программы на другую. Механизм прерываний нужен для того, чтобы оповестить процессор о возникновении в вычислительной системе некоторого непредсказуемого события, например некорректного завершения арифметической операции, или события, которое не синхронизиро- вано с циклом работы процессора, например завершения операции ввода-вывода внешним устройством. Прерывания бывают аппарат- ными и программными. В первом случае при возникновении
условий прерывания источник прерывания (например, контроллер внешнего устройства) выдает определенный электрический сигнал. Этот сигнал прерывает выполнение процессором текущей последо- вательности команд, задаваемых исполняемым кодом, и вызывает автоматический переход на заранее определенную процедуру, назы- ваемую процедурой обработки прерывания. В случае программного прерывания источником прерывания является выполняемая прог- рамма, из которой с помощью специальной команды (например, для процессоров фирмы «Intel» это команда ini) выполняется системный вызов какой-либо процедуры ядра. После завершения обработки прерывания обычно происходит возврат к исполнению прерванного кода. Прерывания играют важную роль в работе любой операционной системы, являясь ее движущей силой. Действительно, большая часть действий операционной системы инициируется прерываниями раз- личного типа. Системный таймер, часто реализуемый в виде быстродейству- ющего регистра-счетчика, необходим операционной системе для выдержки интервалов времени. Для этого в регистр таймера прог- раммно загружается значение требуемого интервала в условных еди- ницах, из которого затем автоматически с определенной частотой начинает вычитается по единице. При достижении нулевого значе- ния счетчика таймер инициирует прерывание, которое обрабатыва- ется процедурой операционной системы. Частота отсчетов таймера, как правило, тесно связана с частотой тактового генератора процес- сора, но ни в коем случае не следует путать таймер ни с тактовым генератором, который вырабатывает сигналы, синхронизирующие все операции в компьютере, ни с системными часами — работающей на батареях электронной схеме, которые ведут независимый отсчет времени и календарной даты. Прерывания от системного таймера используются операционной системой в первую очередь для слеже- ния за тем, как отдельные процессы расходуют время процессора. Например, в системе с разделением времени при обработке очеред- ного прерывания от таймера планировщик процессов может прину- дительно передать управление другому процессу, если текущий про- цесс исчерпал выделенный ему квант времени. Средства защиты областей памяти обеспечивают на аппаратном уровне проверку возможности программного кода осуществлять с данными определенной области памяти такие операции, как чте- ние, запись или выполнение (при передачах управления).
3.4.2. Машинно зависимые компоненты операционной системы Одна и та же операционная система не может без каких-либо из- менений устанавливаться на компьютерах, отличающихся типом процессора или/и способом организации всей аппаратуры. Однако опыт разработки операционных систем показывает: ядро можно спроектировать таким образом, что только часть модулей будут ма- шинно зависимыми, а остальные не будут зависеть от особенностей аппаратной платформы. Объем машинно зависимых компонентов операционной сис- темы зависит от того, насколько велики отличия в аппаратных платформах, для которых разрабатывается операционная система. Одно из наиболее очевидных отличий — несовпадение системы команд процессоров — преодолевается достаточно просто. Опера- ционная система программируется на языке высокого уровня, а за- тем соответствующим компилятором вырабатывается код для кон- кретного типа процессора. Однако во многих случаях различия в организации аппаратуры компьютера лежат гораздо глубже и пре- одолеть их таким образом не удается. Например, однопроцессор- ный и двухпроцессорный компьютеры требуют применения в опе- рационных системах совершенно разных алгоритмов распределе- ния процессорного времени. Аналогично отсутствие аппаратной поддержки виртуальной памяти приводит к принципиальному различию в реализации подсистемы управления памятью. В таких случаях в код операционной системы придется вносить специфику аппаратной платформы, для которой эта операционная система разрабатывается. Для уменьшения количества машинно зависимых модулей про- изводители операционных систем ограничивают распространение своей операционной системы только несколькими типами процес- соров и созданными на их базе аппаратными платформами. Для компьютеров на основе процессоров Intel x86/Pentium разра- ботка экранирующего машинно зависимого слоя операционной сис- темы несколько упрощается за счет встроенной в постоянную память компьютера базовой системы ввода-вывода — BIOS BIOS содержит драйверы для всех устройств, входящих в базовую конфигурацию компьютера: жестких дисков, клавиатуры, дисплея и т.д. Эти драй- веры выполняют примитивные операции по управлению устрой- ствами компьютера, но за счет этих операций экранируются разли- чия аппаратных платформ, созданных на процессорах фирмы «Intel»
или совместимых с ними процессорах разных производителей. Раз- работчики операционной системы могут пользоваться слоем драй- веров BIOS как частью машинно зависимого слоя операционной системы, а могут и заменить все или часть драйверов RIOS компо- нентами операционной системы. 3.4.3. Переносимость операционной системы Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую операционную систему называют переносимой или мобильной. Для того чтобы обеспечить свойство мобильности операционной системы, разработчики следуют следующим правилам: • большая часть кода операционной системы должна быть напи- сана на языке, трансляторы которого имеются на всех компью- терах, куда предполагается перенести систему. Такими языками являются стандартные языки высокого уровня. Наибольшее распространение как язык для написания операционных систем получил язык Си; • объем машинно зависимых частей кода, которые непосред- ственно взаимодействуют с аппаратными средствами, должен быть по возможности минимизирован; • аппаратно зависимый код должен быть надежно изолирован в не- скольких модулях, а не быть распределен по всей операционной системе. В идеале слой машинно зависимых компонентов ядра полностью экранирует остальную часть операционной системы от особенно- стей аппаратной платформы, подменяя реальную аппаратуру неким унифицированным виртуальным компьютером, одинаковым для всех вариантов аппаратной платформы. Все слои операционной сис- темы, которые лежат выше слоя машинно зависимых компонентов, могут быть написаны для управления этой виртуальной аппарату- рой. Таким образом, у разработчиков появляется возможность со- здавать один вариант машинно независимой части операционной системы (включая компоненты ядра, утилиты, системные обраба- тывающие программы) для всего набора поддерживаемых платформ (рис. 3.7).
Машинно независимая часть (язык программирования высокого уровня) Машинно независимая часть (машинный язык компьютера типа С) Машинно независимая часть (машинный язык компьютера типа А} Машинно независимая часть (машинный язык компьютера типа В) Машинно зависимая часть компьютера типа А Машинно зависимая часть компьютера типа В Машинно зависимая часть компьютера типа С ОС компьютера В ОС компьютера А ОС компьютера С Компьютер типа В Рис. 3.7. Перенос ОС на разные аппаратные платформы 3.5. Микроядерная архитектура При микроядерной архитектуре в привилегированном режиме остается работать только очень небольшая часть операционной сис- темы, называемая микроядром (рис. 3 8). Микроядро защищено от остальных частей операционной системы и приложений. В состав микроядра обычно входят машинно зависимые модули, а также час- тично — модули выполняющие базовые функции ядра. Все осталь- ные базовые функции и другие, более высокоуровневые функции ядра оформляются в виде приложений, работающих в пользователь- ском режиме. Однозначного решения о том, какие из системных функций нужно оставить в привилегированном режиме, а какие пе- ревести в пользовательский, не существует. Обычно набор функций
Угилиты ОС Рис. 3.8, Перенос основного объема функций ядра в пользовательское пространство микроядра составляют базовые функции операционной системы, которые трудно или невозможно выполнить в пространстве пользо- вателя В общем случае многие менеджеры ресурсов, являющиеся неотъемлемыми частями обычного ядра, становятся «периферий- ными» модулями, работающими в пользовательском режиме. Работающие в пользовательском режиме менеджеры ресурсов имеют принципиальные отличия от традиционных утилит и обраба- тывающих программ операционной системы, хотя также оформлены в виде приложений. Утилиты и обрабатывающие программы вызы- ваются в основном пользователями. Совсем другая ситуация возни- кает, когда в форме приложения оформляется часть операционной системы, основным назначением которой является обслуживание запросов других приложений, например создание процесса, выделе- ние памяти и т.п. Именно поэтому менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами операционной системы, т.е. модулями, основным назначением которых является обслуживание запросов локальных приложений и других модулей операционной системы. Схематично механизм обращения к функциям операционной системы, оформленным в виде серверов, выглядит следующим обра- зом (рис. 3.9). Клиент, которым может быть либо прикладная прог- рамма, либо другой компонент операционной системы, запрашивает выполнение некоторой функции у соответствующего сервера, посы- лая ему сообщение. Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изо- лированы друг от друга. Микроядро, выполняющееся в привилеги-
Рис. 3.9. Реализация системных вызовов в микроядерной архитектуре рованном режиме, имеет доступ к адресным пространствам каждого из этих приложений и поэтому может работать в качестве посред- ника. Микроядро сначала передает сообщение, содержащее имя и параметры вызываемой процедуры, нужному серверу, затем сервер выполняет запрошенную операцию, после чего ядро возвращает ре- зультат клиенту с помощью другого сообщения. Таким образом, ра- бота микроядерной операционной системы соответствует известной модели клиент—сервер, в которой роль транспортных средств вы- полняет микроядро. 3.5.1. Преимущества и недостатки микроядерной архитектуры Операционные системы, основанные на концепции микроядра, в высокой степени соответствуют большинству требований к совре- менным операционным системам, обладая целым рядом достоинств: • высокой степенью переносимости, обусловленной тем, что весь машинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше измене ний и все они логически сгруппированы вместе; • расширяемостью, которая присуща микроядерной операционной системе в очень высокой степени. В традиционных системах даже при наличии многослойной структуры нелегко удалить или заме нить один слой по причине множественности и размытости ин- терфейсов между слоями. В то же время ограниченный набор четко определенных интерфейсов микроядра открывает путь к упорядоченному росту и эволюции операционной системы. До бавление новой подсистемы требует разработки нового приложе- ния, что никак не затрагивает целостности микроядра; • надежностью, так как каждый сервер выполняется в виде отдель- ного процесса в своей области памяти и таким образом защищен
от других серверов операционной системы. И если один сервер терпит крах, то он может быть перезапущен без останова или по- вреждения остальных серверов операционной системы. Более того, поскольку серверы работают в пользовательском режиме, они нс могут испортить микроядро, а небольшой объем кода мик- роядра снижает вероятность ошибок программирования; • поддержкой распределенных вычислений, так как используются ме- ханизмы, аналогичные сетевым. Серверы микроядерной операци- онной системы могут работать как на одном, так и на разных ком- пьютерах. В этом случае при получении сообщения от приложения микроядро может обработать его самостоятельно и передать ло- кальному серверу или же переслать по сети микрсядру, работа- ющему на другом компьютере Переход к распределенной обра- ботке требует минимальных изменений в работе операционной системы — просто локальный транспорт заменяется на сетевой. За эти достоинства приходится платить снижением производи- тельности, и это является основным недостатком микроядерной ар- хитектуры. При классической организации операционной системы (рис. 3.10, а) выполнение системного вызова сопровождается двумя переключениями режимов, а при микроядерной организации (рис. 3.10, б) — четырьмя. Таким образом, операционная система на основе микроядра при прочих равных условиях всегда будет мед- Рабста приложения Рис. 3.10. Схема режимов при выполнении системного вызова
лсннес, чем операционная система с классическим ядром. Именно поэтому микроядерный подход не получил такою широкого распро- странения, которое ему предрекали. Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT. В версиях 3.1 и 3 5 диспетчер окон, графическая библиотека и высокоуровневые драйверы графических устройств входили в состав сервера и вызов функций этих модулей осуществлялся в соответствии с микроядср- ной схемой. Но такой механизм обращения к часто используемым функциям графического интерфейса существенно замедлял работу приложений. В результате в версию 4.0. были внесены существенные изменения — все перечисленные модули были перенесены в ядро, что отдалило эту операционную систему от идеальной микроядерной архитектуры, но зато резко повысило ее производительность. 3.6. Совместимость и множественные прикладные среды В то время как архитектурные особенности операционных систем непосредственно касаются только системных программистов, кон- цепция множественных прикладных сред непосредственно связана с нуждами конечных пользователей — возможностью операционной системы выполнять приложения, написанные для других операци- онных систем. Такое свойство операционной системы называется совместимостью. 3.6.1. Двоичная совместимость и совместимость исходных текстов Необходимо различать совместимость на двоичном уровне и со- вместимость на уровне исходных текстов. Приложения обычно хра- нятся в операционной системе в виде исполняемых файлов, содер- жащих двоичные коды команд и данных. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение в среде другой операционной системы. Совместимость на уровне исходных текстов требует наличия со- ответствующего компилятора в составе программного обеспечения компьютера, на котором предполагается выполнять данное прило- жение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исход- ных текстов в новый исполняемый модуль. Совместимость на уровне исходных текстов важна в основном для программистов, в распоряжении которых эти исходные тексты
всегда имеются. Но для конечных пользователей практическое зна- чение имеет только двоичная совместимость. Обладает ли новая операционная система двоичной совместимо- стью или совместимостью исходных текстов с существующими опе- рационными системами, зависит от многих факторов. Самый глав- ный из них — архитектура процессора, на котором работает новая операционная система. Если процессор использует тот же набор команд (возможно, более расширенный) и тот же диапазон адресов, тогда двоичная совместимость может быть достигнута очень просто. Для этого достаточно выполнить следующие условия: • вызовы функции API должны поддерживаться данной операци- онной системой; • внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной операци- онной системы Гораздо сложнее достичь двоичной совместимости операционным системам, предназначенным для выполнения на процессорах, име- ющих разные архитектуры Помимо соблюдения перечисленных выше условий, в этом случае необходимо будет организовать эмуля- цию двоичного кода. Для этого необходимо, чтобы на компьютере с другим типом процессора было установлено специальное прог- раммное обеспечение — эмулятор Эмулятор должен последовательно выбирать каждую двоичную команду одного процессора, программным способом дешифрировать ее, чтобы определить, какие действия она задает, а затем выполнить эквивалентную подпрограмму, написанную в командах другого про- цессора. Так как у последнего совершенно другая архитектура, он должен будет имитировать (эмулировать) все элементы первого про- цессора, используя свои регистры или память. Состояние эмулиру- емых регистров и флагов после выполнения каждой команды должно бать абсолютно таким же, как в реальном процессоре. Это простая, но очень медленная работа, так как одна команда реального процессора выполняется значительно быстрее, чем эму- лирующая ее последовательность команд. 3.6.2. Трансляция библиотек Выходом в таких случаях является использование так называемых прикладных программных сред. Одной из составляющих, формиру- ющих прикладную программную среду, является набор функций интерфейса прикладного программирования API, которые операци- онная система предоставляет своим приложениям. Для сокращения
времени на выполнение чужих программ прикладные среды имити- руют обращение к библиотечным функциям. Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графиче- ских интерфейсов пользователя) типа Windows, Мас или UN IX Mo- tif; при этом приложения тратят примерно 60—80% своего времени на обращение и выполнение функций GUI и других библиотечных вызовов операционной системы. Именно это свойство приложений позволяет прикладным программным средам компенсировать боль- шие затраты времени, связанные с покомандным эмулированием программы Прикладная программная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но напи- санные с использованием команд процессора компьютера, на кото- ром выполняется приложение. Таким образом, достигается суще- ственное ускорение выполнения программ с API другой операцион- ной системы. Иногда такой подход называют трансляцией, чтобы отличить его от более медленного процесса эмулирования. Чтобы программа, написанная для одной операционной системы, могла быть выполнена в рамках другой операционной системы, не- достаточно лишь обеспечить совместимость API Для обеспечения совместимости необходимо также организовать бесконфликтное сосуществование в рамках одной операционной системы нескольких способов управления ресурсами компьютера. 3.6.3. Способы реализации прикладных программных сред Создание полноценной прикладной среды, полностью совмести- мой со средой другой операционной системы, является достаточно сложной задачей, тесно связанной со структурой операционной сис- темы. Существуют различные варианты построения множественных прикладных сред, отличающихся как особенностями архитектурных решений, так и функциональными возможностями, обеспечива- ющими различную степень переносимости приложений. Один из наиболее очевидных вариантов реализации множе- ственнвтх прикладных сред основывается на стандартной многоуров- невой структуре операционных сред. На рис. 3.11 операционная система ОС1 поддерживает приложения операционнвтх систем ОС2 и ОСЗ. Для этого в ее составе имеются специалвные приложения — прикладные программные среды, которые транслируют интерфейсвт операционных систем API ОС2 и API ОСЗ в интерфейс своей опера- ционной сисгемв! API ОС1.
Транслятор системных вызовов Пользова1ельсиий режим Поивилегированный режим ДР| ОС I Менеджеры ресурсов Прикладная среда ОС2 вазовые механизмы Машинно независимые задачи Рис. 3.11. Прикладные программные среды, транслирующие системные вызовы В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов. В приведенном на рис. 3.12 примере опе- рационная система поддерживает приложения, написанные для ОС1, ОС2 и ОСЗ. Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих операционных систем: API ОС1, API ОС2 и API ОСЗ. В этом случае все функции уровня API обращаются к функциям нижележа- щего уровня операционной системы, которые должны поддерживать все три в общем случае несовместимые прикладные среды. Для этого
Рис. 3.12. Реализация совместимости на основе нескольких равноправных API функции каждого API реализуются ядром с учетом специфики соот- ветствующей операционной системы, даже если они имеют анало- гичное назначение. Для того чтобы ядро могло выбрать нужный ва- риант реализации системного вызова, каждый процесс должен пе- редавать в ядро набор идентифицирующих характеристик Еще один способ построения множественных прикладных сред основан на микроядерном подходе. При этом очень важно отделить базовые, общие для всех прикладных сред механизмы операционной системы от специфических для каждой из прикладных сред высоко- уровневых функций, решающих стратегические задачи. Все функции операционной системы реализуются микроядром и серверами поль- зовательского режима, а каждая прикладная среда оформляется в виде отдельного сервера и не включает базовых механизмов опера- ционной системы (рис. 3.13). Приложения, используя API, обраща- ются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функ- циям микроядра) и отсылает приложению результат. В ходе выпол- нения запроса прикладной среде приходится, в свою очередь, обра- щаться к базовым механизмам операционной системы, реализуемым микроядром и другими серверами. Создание в рамках одной операционной системы нескольких прикладных сред для выполнения приложений различных операци- онных систем позволяет иметь единственную версию программы и переносить ее между операционными системами. Множественные
Гис. 3.13. Микроядерный подход к реализации множественных прикладных сред
прикладные среды обеспечивают совместимость на двоичном уровне данной операционной системы с приложениями, написанными для других операционных систем В результате пользователи получают большую свободу выбора операционных систем и более легкий до- ступ к качественному программному обеспечению. Выводы Простейшая структуризация ОС состоит в разделении всех ком понентов ОС на модули, выполняющие основные функции ОС (ядро), и модули, выполняющие вспомогательные функции ОС. Вспомогательные модули ОС оформляются либо в виде приложений (утилиты и системные обрабатывающие программы), либо в виде библиотек процедур. Вспомогательные модули загружаются в опе- ративную память только на время выполнения своих функций, т.е. являются транзитными. Модули ядра постоянно находятся в опе- ративной памяти, т.е. являются резидентными. При наличии аппаратной поддержки режимов с разными уров- нями полномочий устойчивость ОС может быть повышена путем выполнения функций ядра в привилегированном режиме, а вспомо- гательных модулей ОС и приложений — в пользовательском. Это дает возможность защитить коды и данные ОС и приложений от не- санкционированного доступа. ОС может выступать в роли арбитра в спорах приложений за ресурсы. Ядро, являясь структурным элементом ОС, в свою очередь, может быть логически разложено на следующие слои (начиная с самого нижнего): • машинно зависимые компоненты ОС; • базовые механизмы ядра; • менеджеры ресурсов; • интерфейс системных вызовов. В многослойной системе каждый слой обслуживает вышележа- щий слой, выполняя для него некоторый набор функций, которые образуют межслойный интерфейс. На основе функций нижележа- щего слоя следующий вверх по иерархии слой строит свои функ- ции — более сложные и более мощные, которые, в свою очередь, оказываются примитивами для создания еще более мощных функ- ций вышележащего слоя. Многослойная организация ОС суще- ственно упрощает разработку и модернизацию системы. Л юбая ОС для решения своих задач взаимодействует с аппарат- ными средствами компьютера, а именно: средствами поддержки
привилегированного режима и трансляции адресов; средствами пе- реключения процессов и защиты областей памяти; системой преры- ваний и системным таймером. Это делает ОС машинно зависимой, привязанной к определенной аппаратной платформе. Переносимость ОС может быть достигнута при соблюдении сле- дующих правил. Во-первых, большая часть кода должна быть напи- сана на языке, трансляторы которого имеются на всех компьютерах, куда предполагается переносить систему. Во-вторых, объем машинно зависимых частей кода, которые непосредственно взаимодействуют с аппаратными средствами, должен быть по возможности миними- зирован. В-третьих, аппаратно зависимый код должен быть надежно локализован в нескольких модулях. Микроядерная архитектура является альтернативой классиче- скому способу построения операционной системы, в соответствии с которым все основные функции операционной системы, состав- ляющие многослойное ядро, выполняются в привилегированном режиме. В микроядерных ОС в привилегированном режиме остается работать "олько очень небольшая часть ОС, называемая микроядром. Все остальные высокоуровневые функции ядра оформляются в виде приложений, работающих в пользовательском режиме. Микроядерныс ОС удовлетворяют большинству требований, предъявляемых к современным ОС, обладая переносимостью, рас- ширяемостью. надежностью и создавая хорошие предпосылки для поддержки распределенных приложений. За эти достоинства прихо- дится платить снижением производительности, что является основ- ным недостатком микроядерной архитектуры. Прикладная программная среда — совокупность средств ОС, предназначенная для организации выполнения приложений, ис- пользующих определенную систему машинных команд, опреде- ленный тип API и определенный формат исполняемой программы. Каждая ОС создает как минимум одну прикладную программную среду. Проблема состоит в обеспечении совместимости нескольких программных сред в рамках одной ОС. При построении множе- ственных прикладных сред используются различные архитектурные решения, концепции эмуляции двоичного кода, трансляции API. Вопросы для самоконтроля 1. Что понимают под архитектурой операционной системы? 2. Какие функции выполняют модули ядра операционной системы? 3. Какие функции выполняют модули операционной системы, не входя- щие в ядро операционной системы?
4. Определите назначение программ утилит. 5. Определите назначение системных обрабатывающих программ. 6. Приведите примеры программ предоставления пользователю дополни- тельных услуг. 7. Определите назначение библиотек процедур (функций). 8. В чем заключается отличие между резидентными и транзитными про- граммами? 9. В каком из двух режимов, пользовательском или привилегированном, работает операционная система? 10. В чем заключаются отличия между пользовательским и привилегиро- ванным режимами? 11. Какие из приведенных ниже терминов являются синонимами: • привилегированный режим; • защищенный режим; • режим супервизора; • пользовательский режим; • реальный режим, • режим ядра? 12. Выполнение каких команд доступа к памяти разрешается в пользова- тельском и привилегированном режимах: • доступ к памяти, отведенной данному приложению; • доступ к памяти других приложений? 13. Чем вызвано замедление выполнения системных вызовов при переходе из пользовательского режима в привилегированный режим и обратно? 14. Приведите примеры операционных систем, не поддерживающих работу в привилегированном режиме. 15. Чем отличаются реальный и защищенный режимы работы процессора? 16. Объясните принцип организации многослойной структуры компью- тера, работающего под управлением операционной системы на основе ядра. 17. Перечислите название и назначение основных слоев, составляющих ядро операционной системы. 18. Перечислите и охарактеризуйте основные компоненты средств аппа- ратной поддержки операционной системы. 19. С помощью каких средств можно преодолеть несовпадение систем ко- манд процессоров различных платформ? 20. Каким образом можно уменьшить объем машинно зависимых модулей операционной системы? 21. Объясните роль BIOS. 22. Каким правилам следуют разработчики операционных систем для обес- печения мобильности и переносимости операционных систем? 23. Объясните принцип микроядерной архитектуры. 24. Каким образом происходит обращение к функциям операционной сис- темы, оформленным в виде серверов, в системах с микроядерной архи- тектурой?
25. Какими преимуществами и недостатками обладает микроядерная ар- хитектура? 26. Что понимается под термином «совместимость»? 27. Что представляет собой двоичная совместимость? 28 Что представляет собой совместимость исходных текстов? 29 Каково назначение программы эмулятора? 30. Каково назначение прикладных программных сред? 31. Какие способы реализации прикладных программных сред вы знаете?
Глава 4 ПРОЦЕССЫ И ПОТОКИ 4.1. Планирование процессов и потоков 4.1.1. Понятия «процесс» и «поток» В настоящее время в большинстве операционных систем опреде- лены два типа единиц работы. Более крупная единица работы, нося- щая название процесса или задачи, требует для своего выполнения нескольких более мелких работ, для обозначения которых исполь- зуют термины «поток» или «нить». Между этими внутренними еди- ницами работы и будут разделяться процессорное время и другие ресурсы компьютера. Работа любого компьютера заключается в выполнении некоторой программы, поэтому и с процессом, и с потоком связывается опре- деленный программный код, представленный в виде исполняемого модуля. Чтобы этот программный код мог быть выполнен, его необ- ходимо загрузить в оперативную память, возможно, выделить неко- торое место на диске для хранения данных, предоставить доступ к устройствам ввода-вывода и т.д. Выполнение программы также невозможно без предоставления ей процессорного времени, т.е. вре- мени, в течение которого процессор выполняет коды данной прог- раммы. В операционной системе процесс рассматривается как заявка на потребление всех видов ресурсов, кроме одного — процессорного времени. Этот последний важнейший ресурс распределяется опера- ционной системой между другими единицами работы — потоками, которые и получили свое название благодаря тому, что они представ- ляют собой последовательности (потоки выполнения) команд. В простейшем случае процесс состоит из одного потока, и именно таким образом трактовалось понятие «процесс» до середины 1980-х гг., ив таком же виде оно сохранилось в некоторых совре- менных ОС. В таких системах понятие «поток» полностью поглоща- ется понятием «процесс», т.е. остается только одна единица работы и потребления ресурсов — процесс. Мультипрограммирование осу- ществляется в таких ОС на уровне процессов, а отдельный процесс
никогда не может быть выполнен быстрее, чем в однопрограммном режиме (всякое разделение ресурсов только замедляет работу одного из участников за счет дополнительных затрат времени на ожидание освобождения ресурса). Современные ОС используют механизм распараллеливания вы- числений, который учитывает тесные связи между отдельными вет- вями вычислений одного и того же приложения. Для этих целей ОС предлагают механизм многопоточной обработки (multithreading). При этом вводится новая единица работы — поток, а понятие «'Про- цесс» в значительной степени меняет смысл. Понятию «поток» со- ответствует последовательный переход процессора от одной команды программы к другой. ОС распределяет процессорное время между потоками, а процессу ОС назначает адресное пространство и набор ресурсов, которые совместно используются всеми его потоками. Мультипрограммирование более эффективно на уровне потоков, а не процессов. Задача, оформленная в виде нескольких потоков в рамках одного процесса, может быть выполнена быстрее за счет псевдопараллельного выполнения ее отдельных частей. Особенно эффективно можно использовать многопоточность для выполнения распределенных сетевых приложений. Наибольший эффект от введения многопоточной обработки до- стигается в мультипроцессорных системах, в которых потоки, в том числе и принадлежащие одному процессу, могут выполняться на раз- ных процессорах действительно параллельно (а не псевдопарал- лельно). 4.1.2. Назначение подсистемы управления процессами и потоками Подсистема управления процессами и потоками является одной из основных подсистем мультипрограммной ОС, непосредственно влияющей на функционирование компьютера. Подсистема занима- ется созданием и уничтожением процессов и потоков, поддерживает взаимодействие между ними, а также распределяет процессорное время между несколькими одновременно существующими в системе процессами и потоками. Подсистема ответственна за обеспечение процессов необходи- мыми ресурсами, для этого ОС поддерживает в памяти специальные информационные структуры, в которые записывает, какие ресурсы выделены каждому процессу. Она может назначить процессу ресурсы в единоличное пользование или в совместное пользование с другими процессами. Некоторые из ресурсов выделяются процессу при его
создании, а некоторые — динамически по запросам во время выпол- нения. Ресурсы могут быть приписаны процессу на все время его жизни или только на определенный период. При выполнении этих функций подсистема управления процессами взаимодействует с дру- гими подсистемами ОС, ответственными за управление ресурсами, такими как подсистема управления памятью, подсистема ввода-вы- вода, файловая система. На компьютере при одновременном выполнении нескольких не- зависимых процессов может возникать ряд дополнительных проблем, а именно: потоки возникают и выполняются асинхронно, но у них может возникнуть необходимость во взаимодействии, на- пример, при обмене данными. Кроме этого, также очень важно со- гласовывать скорости потоков, это необходимо для предотвращения эффекта «гонок» (например, когда несколько потоков пытаются из- менить один и тот же файл), взаимных блокировок или других кол- лизий, которые возникают при совместном использовании ресурсов. Синхронизация потоков является одной из важных функций под- системы управления процессами и потоками. Каждый раз, когда процесс завершается, ОС предпринимает шаги, чтобы удалить из системы следы его пребывания. Для этого подсистема управления процессами закрывает все файлы, с кото- рыми работал процесс, освобождает области оперативной памяти, отведенные под коды, данные и системные информационные струк- туры процесса, а также выполняется коррекция всевозможных оче- редей ОС и списков ресурсов, в которых имелись ссылки на завер- шаемый процесс. 4 13. Создание процессов и потоков Создать процесс — это прежде всего означает создать описатель процесса, в качестве которого выступает одна или несколько инфор- мационных структур, содержащих все сведения о процессе, необхо- димые операционной системе для управления им. В число таких сведений могут входить, например, идентификатор процесса, данные о расположении в памяти исполняемого модуля, степень привиле- гированности процесса (приоритет и права доступа) и т.п. Создание описателя процесса знаменует собой появление в системе еще одного процесса. Начиная с этого момента при распределении ресурсов ОС должна принимать во внимание потребности нового претендента на ресурсы компьютера. Создание процесса также включает в себя загрузку кодов и дан- ных исполняемой программы данного процесса с диска в операгив-
ную память. Для этого ОС должна найти программу на диске, пере- распределить оперативную память, если это необходимо, и выделить память исполняемой программе нового процесса. Затем ОС считы- вает программу с диска и записывает ее в выделенные для нее участки памяти. В системах с виртуальной памятью в начальный момент может загружаться только часть кодов и данных процесса, с тем чтобы «подкачивать» остальные по мере необходимости. В многопоточной системе при создании процесса ОС создает для каждого процесса как минимум один поток выполнения. При созда- нии потока, так же как и при создании процесса, операционная сис- тема генерирует специальную информационную структуру — описа- тель потока, который содержит необходимую для его выполнения системную информацию. В исходном состоянии поток или процесс (если речь идет о ОС, нс поддерживающих многопоточную работу) находится в приостановленном состоянии. Момент выборки потока или процесса на выполнение осуществляется в соответствии с при- нятым в данной системе правилом предоставления процессорного времени и с учетом всех существующих в данный момент потоков и процессов. 4.1.4. Планирование и диспетчеризация потоков На протяжении существования процесса выполнение его потоков может быть многократно прервано и продолжено (если ОС не под- держивает многопоточную обработку, все сказанное ниже о плани- ровании и диспетчеризации относится к процессу). Переход от выполнения одного потока к другому осуществляется в результате планирования и диспетчеризации. Работа по опреде- лению того, в какой момент необходимо прервать выполнение теку- щего активного потока и какому потоку предоставить возможность выполняться, называется планированием. Планирование потоков осуществляется на основе информации, хранящейся в описателях процессов и потоков. При планировании могут приниматься во вни- мание приоритет потоков, время их ожидания в очереди, накоп- ленное время выполнения, интенсивность обращений к вводу-вы- воду и другие факторы. ОС планирует выполнение потоков незави- симо от того, принадлежат ли они одному или разным процессам. Так, например, после выполнения пот ока некоторого процесса ОС может выбрать для выполнения другой поток того же процесса или же назначить к выполнению поток другого процесса. Планирование потоков, по существу, включает в себя решение двух следующих задач:
• определение момента времени для смены текущего активного потока; • выбор для выполнения потока из очереди готовых потоков. Существует два типа планирования: • динамическое планирование; • статическое планирование. В большинстве операционных систем универсального назначения планирование осуществляется динамически (on-line), т.е. решения принимаются во время работы системы на основе анализа текущей ситуации. Другой тип планирования — статический — используется в спе- циализированных системах, в которых весь набор одновременно выполняемых задач определен заранее, например в системах реаль- ного времени. Планировщик в этом случае называется статическим (или предварительным планировщиком), так как он принимает ре- шения о планировании не во время работы системы, а заранее (off- line). Диспетчеризация заключается в реализации найденного в ре- зультате планирования (динамического или статического) реше- ния, т.е. в переключении процессора с одного потока на другой. Прежде чем прервать выполнение потока, ОС запоминает его кон- текст, с тем чтобы впоследствии использовать эту информацию для последующего возобновления выполнения данного потока. Кон- текст отражает, во-первых, состояние аппаратуры компьютера в момент прерывания потока: значение счетчика команд, содер- жимое регистров общего назначения, режим работы процессора, флаги, маски прерываний и другие параметры Во-вторых, кон- текст включает параметры операционной среды, а именно ссылки на открытые файлы, данные о незавершенных операциях ввода- вывода, коды ошибок выполняемых данным потоком системных вызовов и т.д. Диспетчеризация сводится к следующему: • сохранение контекста текущего потока, который требуется сме- нить; • загрузка контекста нового потока, выбранного в результате пла- нирования, • запуск нового потока на выполнение. Поскольку операция переключения контекстов существенно влияет на производительность вычислительной системы, прог- раммные модули ОС выполняют диспетчеризацию потоков со- вместно с аппаратными средствами процессора.
4.1.5. Состояния потока ОС выполняет планирование потоков, принимая во внимание их состояние. В мультипрограммной системе поток может находиться в одном из трех основных состояний: • выполнение — активное состояние потока, во время которого по- ток обладает всеми необходимыми ресурсами и непосредственно выполняется процессором; • ожидание — пассивное состояние потока, находясь в котором по- ток заблокирован по своим внутренним причинам (ждет осуще- ствления некоторого события, например завершения операции ввода-вывода, получения сообщения от другого потока или осво- бождения какого-либо необходимого ему ресурса); • готовность — также пассивное состояние потока, но в этом слу- чае поток заблокирован в связи с внешним по отношению к нему обстоятельством (имеет все требуемые для него ресурсы, готов выполняться, однако процессор занят выполнением другого по- тока) . В течение своей жизни каждый поток переходит из одного со- стояния в другое в соответствии с алгоритмом планирования пото- ков, принятым в данной операционной системе. Рассмотрим типичный граф состояния потока (рис. 4.1). Только что созданный поток находится в состоянии готовности, он готов к выполнению и стоит в очереди к процессору. Когда в результате планирования подсистема управления потоками принимает реше- ние об активизации данного потока, он переходит в состояние вы- полнения и находится в нем до тех пор, пока либо он сам освобо- дит процессор, перейдя в состояние ожидания какого-нибудь со- Рис. 4.1, Типичный граф состояния потока
бытия, либо будет принудительно «вытеснен» из процессора, например вследствие исчерпания отведенного данному потоку кванта процессорного времени В последнем случае поток возвра- щается в состояние готовности. В это же состояние поток перехо- дит из состояния ожидания, после того как ожидаемое событие произойдет. В состоянии выполнения в однопроцессорной системе может на- ходиться не более одного потока, а в каждом из состояний ожидания и готовности — несколько потоков. Эти потоки образуют очереди соответственно ожидающих и готовых потоков. Очереди потоков организуются путем объединения в списки их описателей. Таким образом, каждый описатель потока, кроме всего прочего, содержит по крайней мерс один указатель на другой описатель, соседствующий с ним в очереди. Такая организация очередей позволяет легко их пе- реупорядочивать, включать и исключать потоки, переводить потоки из одного состояния в другое. Если предположить, что на рис. 4.2 показана очередь готовых потоков, то запланированный порядок выполнения выглядит так: А, В, Е, D, С. Рис. 4.2. Очередь потоков 4.1.6 Вытесняющие и невытесняющие алгоритмы планирования Все множество алгоритмов планирования можно разделить на два класса: вытесняющие и невытесняющие алгоритмы планирования. Невытесняющие (non-preemptive) алгоритмы основаны на том, что активному потоку позволяется выполняться, пока он сам, по соб- ственной инициативе, не отдаст управление операционной системе, для того чтобы та выбрала из очереди другой готовый к выполнению поток. Вытесняющие (preemptive) алгоритмы — это такие способы плани- рования потоков, в которых решение о переключении процессора с выполнения одного потока на выполнение другого потока прини- мается операционной системой, а не активной задачей.
Основным различием между вытесняющими и невытесняющими алгоритмами является степень централизации механизма планиро- вания потоков. При вытесняющем мультипрограммировании функции планирования потоков целиком сосредоточены в операци- онной системе и программист пишет свое приложение, не заботясь о том, что оно будет выполняться одновременно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения активного потока; запоми- нает его контекст; выбирает из очереди готовых потоков следующий; запускает новый поток на выполнение, загружая его контекст. При невытесняющем мультипрограммировании механизм плани- рования распределен между операционной системой и прикладными программами. Прикладная программа, получив управление от опе- рационной системы, сама определяет момент завершения очередного цикла своего выполнения и только затем передает управление ОС с помощью какого-либо системного вызова. ОС формирует очереди потоков и выбирает в соответствии с некоторым правилом (напри- мер, с учетом приоритетов) следующий поток на выполнение. Такой механизм требует определенного подхода к программированию при- ложений, т.е. разработчики приложений для операционной среды с невытесняющей многозадачностью вынуждены, возлагая на себя часть функций планировщика, создавать приложения так, чтобы они выполняли свои задачи небольшими частями. Почти во всех современных операционных системах, ориентиро- ванных на высокопроизводительное выполнение приложений, реали- зованы вытесняющие алгоритмы планирования потоков (процессов). 4 1.7. Алгоритмы планирования, основанные на квантовании В основе многих вытесняющих алгоритмов планирования лежит концепция квантования. В соозветствии с этой концепцией каждому потоку поочередно для выполнения предоставляется ограниченный непрерывный период процессорного времени — квант. Смена актив- ного потока происходит, если: • поток завершился и покинул систему; • произошла ошибка; • поток перешел в состояние ожидания; • исчерпан квант процессорного времени, отведенный данному потоку. Поток, который исчерпал свой квант, переводится в состояние готовности и ожидает, когда ему будет предоставлен новый квант
процессорного времени, а на выполнение в соответствии с опреде- ленным правилом выбирается новый поток из очереди готовых к вы- полнению потоков. Граф состояний потока, изображенный на рис. 4.3, соответствует алгоритму планирования, основанному на квантовании. Рис. 4.3. Граф состояний потока в системе с квантованием Кванты, выделяемые потокам, могут быть одинаковыми для всех потоков или различными. Рассмотрим, например, случай, когда всем потокам предоставляются кванты одинаковой длины q (рис. 4.4). Если в системе имеется п потоков, то время, которое поток проводит в ожидании следующего кванта, можно грубо оценить как q(n - 1). Чем больше потоков в системе, тем больше время ожидания, тем меньше возможности вести одновременную интерактивную работу нескольким пользователям. Но если величина кванта выбрана очень небольшой, то значение произведения q(n -1) все равно будет доста- точно мало для того, чтобы пользователь не ощущал дискомфорта от присутствия в системе других пользователей. Типичное значение Очередь готовых потоков Рис. 4 4. Иллюстрация расчета времени ожидания в очереди
кванта в системах разделения времени составляет десятки миллисе- кунд. Потоки получают для выполнения квант времени, но некоторые из них используют его не полностью, например, из-за необходи- мости выполнить ввод или вывод данных. В результате возникает ситуация, когда потоки с интенсивными обращениями к вводу-вы- воду используют только небольшую часть выделенного им процес- сорного времени. Алгоритм планирования может исправить эту «не- справедливость». В качестве компенсации за неиспользованные полностью кванты потоки получают привилегии при последующем обслуживании. Для этого планировщик создает две очереди готовых потоков (рис. 4.5). Очередь 1 образована потоками, которые перешли в состояние готовности в результате исчерпания кванта времени, а очередь 2 — потоками, у которых завершилась операция ввода-вы- вода. При выборе потока для выполнения прежде всего просматри- вается вторая очередь, и только если она пуста, квант выделяется потоку из первой очереди. Рис. 4.5. Квантование с предпочтением потоков, интенсивно обращающихся к вводу-выводу 4.1.8. Алгоритмы планирования, основанные на приоритетах Другой важной концепцией, лежащей в основе многих вытесня- ющих алгоритмов планирования, является приоритетное обслужи- вание. Приоритетное обслуживание предполагает наличие у потоков некоторой изначально известной характеристики — приоритета, на основании которой определяется порядок их выполнения. Прио-
pumetn — это число, характеризующее степень привилегированности потока при использовании ресурсов вычислительной машины, в частности процессорного времени: чем выше приоритет, тем выше привилегии, тем меньше времени будет проводить поток в очередях. Приоритет может выражаться целым или дробным, положитель- ным или отрицательным значением. В некоторых ОС принято, что приоритет потока тем выше, чем больше (в арифметическом смысле) число, обозначающее приоритет. В других системах, наоборот, чем меньше число, тем выше приоритет. В большинстве операционных систем, поддерживающих потоки, приоритет потока непосредственно связан с приоритетом процесса, в рамках которого выполняется данный поток. Приоритет процесса назначается операционной системой при его создании. Значение приоритета включается в описатель процесса и используется при на- значении приоритета потокам этого процесса. При назначении при- оритета вновь созданному процессу ОС учитывает, является этот процесс системным или прикладным, каков статус пользователя, запустившего процесс, было ли явное указание пользователя на при- своение процессу определенного уровня приоритета. Поток может быть инициирован не только по команде пользователя, но и в резуль- тате выполнения системного вызова другим потоком. В этом случае при назначении приоритета новому потоку' ОС должна принимать во внимание значение параметров системного вызова. Во многих ОС предусматривается возможность изменения при- оритетов в течение жизни потока. Изменения приоритета могут происходить по инициативе самого потока, когда он обращается с соответствующим вызовом к операционной системе, или по ини- циативе пользователя, когда он выполняет соответствующую ко- манду. Кроме того, ОС сама может изменять приоритеты потоков в зависимости от ситуации, складывающейся в системе. В по- следнем случае приоритеты называются динамическими в отличие от неизменяемых, фиксированных приоритетов. Пользователи, как правило, не имеют права повышать приоритеты своим потокам, это разрешено делать (да и то в определенных пределах) только адми- нистраторам. В большинстве же случаев ОС присваивает приори- теты потокам по умолчанию. Существуют две разновидности приоритетного планирования: обслуживание с относительными приоритетами и обслуживание с аб- солютными приоритетами. В обоих случаях выбор потока на выполнение из очереди готовых осуществляется одинаково: выбирается поток, имеющий наивысший
приоритет. Однако проблема определения момента смены активного потока решается по-разному. В системах с относительными приори- тетами активный поток выполняется до тех пор, пока он сам нс по- кинет процессор, перейдя в состояние ожидания (или же произойдет ошибка, или поток завершится). На рис. 4.6, а показан граф со- стояний потока в системе с относительными приоритетами. Рис. 4.6. Графы состояний потоков в системах с относительными и абсолютными приоритетами В системах с абсолютными приоритетами выполнение активного потока прерывается, кроме указанных выше причин, еше при одном условии: если в очереди готовых потоков появился поток, приоритет которого выше приоритета активного потока. В этом случае пре- рванный поток переходит в состояние готовности (рис. 4.6, б). В системах, в которых планирование осуществляется на основе относительных приоритетов, минимизируются затраты на переклю- чение процессора с одной работы на другую. С другой стороны, здесь могут возникать ситуации, когда одна задача занимает процессор долгое время. Ясно, что для систем разделения времени и реального
времени такая дисциплина обслуживания не подходит: интерактив- ное приложение может ждать своей очереди часами, пока вычисли- тельной задаче не потребуется ввод-вывод. А вот в системах пакетной обработки относительные приоритеты используются широко. В системах с абсолютными приоритетами время ожидания потока в очередях может быть сведено к минимуму, если ему назначить са- мый высокий приоритет. Такой поток будет вытеснять из процессора все остальные потоки (кроме потоков, имеющих такой же наивыс- ший приоритет). Это делает планирование на основе абсолютных приоритетов подходящим для систем управления объектами, в ко- торых важна быстрая реакция на событие. 4.1.9 Смешанные алгоритмы планирования Во многих операционных системах алгоритмы планирования по- строены с использованием как концепции квантования, так и кон- цепции приоритетов. Например, в основе планирования лежит кван- тование, но величина кванта и/или порядок выбора потока из оче- реди готовых к выполнению потоков определяется их приоритетами. Например, в ОС Windows NT квантование сочетается с динами- ческими абсолютными приоритетами. На выполнение выбирается готовый поток с наивысшим приоритетом. Ему выделяется квант времени. Если во время выполнения в очереди готовых к выполне- нию потоков появляется поток с более высоким приоритетом, то он вытесняет выполняемый поток. Вытесненный поток возвращается в очередь готовых к выполнению потоков, причем он становится впереди всех остальных потоков, имеющих такой же приоритет. В операционной системе UNIX System V Release 4 понятие «поток» отсутствует и планирование осуществляется на уровне процессов. В этой системе реализована вытесняющая многозадачность, основан- ная на использовании концепции приоритетов и квантования. Каждый процесс в ОС UNIX System V Release 4 в зависимости от задачи, которую он решает, относится к одному из трех опреде- ленных в системе приоритетных классов: классу реального времени, классу системных процессов или классу процессов разделения вре- мени. Назначение и обработка приоритетов выполняются для разных классов по-разному. Процессы системного класса, зарезервированные для ядра, ис- пользуют стратегию фиксированных приоритетов. Уровень приори- тета процессу назначается ядром и никогда не изменяется. Процессы реального времени также используют стратегию фикси- рованных приоритетов, но пользователь может их изменять.
Процессы разделения времени используют стратегию динамиче- ских приоритетов Величина приоритета, назначаемого процессам, вычисляется пропорционально значениям двух составляющих: пользовательской части и системной части. Пользовательская часть приоритета может быть изменена администратором и владельцем процесса, но в последнем случае только в сторону его снижения, а системная составляющая позволяет планировщику управлять про- цессами в зависимости от того, как долго они занимают процессор, не уходя в состояние ожидания. У тех процессов, которые потреб- ляют большие периоды процессорного времени без ухода в со- стояние ожидания, приоритет снижается, а у тех процессов, которые часто уходят в состояние ожидания после короткого периода ис- пользования процессора, приоритет повышается. 4.1.10. Планирование в системах реального времени В системах реальною времени, в которых главным критерием эф- фективности является обеспечение временных характеристик вычис- лительного процесса, планирование имеет особое значение. Любая система реального времени должна реагировать на сигналы управля- емого объекта в течение заданных временных ограничений. Необхо- димость тщательного планирования работ облегчается тем, что в сис- темах реального времени весь набор выполняемых задач известен заранее. Кроме того, часто в системе имеется информация о временах выполнения задач, моментах активизации, предельных допустимых сроках ожидания ответа и т.д. Эти данные могут быть использованы планировщиком для создания статического расписания или для по- строения адекватного алгоритма динамического планирования. При разработке алгоритмов планирования для систем реального времени необходимо учитывать, какие последствия в этих системах возникают при несоблюдении временных ограничений. Если эти последствия катастрофичны, как, например, для системы управ- ления полетами или атомной электростанцией, то операционная система реального времени, на основе которой строится управление объектом, называется жесткой {hard). Если же последствия наруше- ния временных ограничений не столь серьезны, т.е. сравнимы с той пользой, которую приносит система управления объектом, то сис- тема является мягкой {soft) системой реального времени. Примером мягкой системы реального времени является система резервирова- ния билетов. Если из-за временных нарушений оператору не удается зарезервировать билет, это не очень страшно — можно просто по- слать запрос на резервирование заново.
4.1.11. Моменты перепланировки Для реализации алгоритма планирования ОС должна получать управление всякий раз, когда в системе происходит событие, требу- ющее перераспределения процессорного времени Вызвать перерас- пределение процессорного времени могут следующие события: • прерывание от таймера, сигнализирующее, что время, отведенное активной задаче на выполнение, закончилось. Планировщик пе- реводит задачу в состояние готовности и выполняет переплани- рование; • активная задача выполнила системный вызов, связанный с запросом на ввод-вывод или на доступ к ресурсу, который в настоящий мо- мент занят (например, файл данных). Планировщик переводит задачу в состояние ожидания и выполняет перепланирование; • активная задача выполнила системный вызов, связанный с освобож - дением ресурса. Планировщик проверяет, не ожидает ли этот ре- сурс какая-либо другая задача. Если да, то эта задача переводится из состояния ожидания в состояние готовности. При этом воз- можно, что задача, которая получила ресурс, имеет более высокий приоритет, чем текущая активная задача. После перепланирова- ния более приоритетная задача получает доступ к процессору, вытесняя текущую задачу; • внешнее {аппаратное) прерывание, которое сигнализирует о завер- шении периферийным устройством операции ввода-вывода, пе- реводит соответствующую задачу в очередь готовых, и выполня- ется планирование; • внутреннее прерывание сигнализирует об ошибке, которая про- изошла в результате выполнения активной задачи. Планировщик снимает задачу и выполняет перепланирование. При возникновении каждого из этих событий планировщик вы- полняет просмотр очередей и решает вопрос о том, какая задача бу- дет выполняться следующей. Помимо указанных, существует и ряд других событий (часто связанных с системными вызовами), требу- ющих перепланировки. Например, запросы приложений и пользо- вателей на создание новой задачи или повышение приоритета уже существующей задачи создают новую ситуацию, которая требует пересмотра очередей и, возможно, переключения процессора На рис. 4 7 показан фрагмент временной диаграммы работы пла- нировщика в системе, где одновременно выполняются четыре по- тока. В данном случае неважно, по какому правилу выбираются по- токи на выполнение и каким образом изменяются их приоритеты.
Рис 4 7. Моменты перепланировки потоков Существенное значение имеют лишь события, вызывающие активи- зацию планировщика. Первые четыре цикла работы планировщика, приведенные на ри- сунке, были инициированы прерываниями от таймера по истечении квантов времени (эти события обозначены на рисунке как Т). Следующая передача управления планировщику была осуще- ствлена в результате выполнения потоком 3 системного запроса на ввод-вывод (событие I/O). Планировщик перевел этот поток в со- стояние ожидания, а затем переключил процессор на поток 2. По- ток 2 полностью использовал свой квант, произошло прерывание от таймера, и планировщик активизировал поток 1. При выполнении потока 1 произошло событие R — системный вызов, в результате которого освободился некоторый ресурс (напри- мер, был закрыт файл). Это событие вызвало перепланировку пото- ков. Планировщик просмотрел очередь ожидающих потоков и обна- ружил, что поток 4 ждет освобождения данного ресурса. Этот поток был переведен в состояние готовности, но, поскольку приоритет выполняющегося в данный момент потока 1 выше приоритета по- тока 4, планировщик вернул процессор потоку 1. В следующем цикле работы планировщик активизировал поток 4, а затем, после истечения кванта и сигнала от таймера, управление получил поток 2. Этот поток не успел использовать свой квант, так как был снят с выполнения в результате возникшей ошибки (собы- тие ER). Далее планировщик предоставлял процессорное время потокам 1, 4 и снова 1. Во время выполнения потока 1 произошло прерывание S от внешнего устройства, сигнализирующее о том, что операция пе- редачи данных завершена. Это событие активизировало работу пла- нировщика, в результате которой поток 3, ожидавший завершения
ввода-вывода, вытеснил поток 1, так как имел в этот момент более высокий приоритет. Последний показанный на диаграмме период выполнения потока 1 прерывался несколько раз. Вначале это было прерывание от внешнего устройства (S), затем программное прерывание (R), вызвавшее осво- бождение ресурса, и, наконец, прерывание от таймера (7). Каждое из этих трех прерываний вызвало перепланировку потоков. В двух первых случаях планировщик оставил выполняться поток 1, так как в очереди не оказалось более приоритетных потоков, а квант времени, выделенный потоку 1, еще не был исчерпан. Переключение потоков было выполнено только по прерыванию от таймера. В системах реального времени для отработки статического рас- писания планировщик активизируется по прерываниям от таймера. Эти прерывания пронизывают всю временную ось, возникая через короткие постоянные интервалы времени. После каждого прерыва- ния планировщик просматривает расписание и проверяет, не пора ли переключить задачи. Кроме прерываний от таймера, в системах ре- ального времени перепланирование задач может происходить по прерываниям от внешних устройств — различного вида датчиков и исполнительных механизмов. 4.2. Мультипрограммирование на основе прерываний 4.2.1 Назначение и типы прерываний Прерывания являются основной движущей силой любой опера- ционной системы. Так, периодические прерывания от таймера вы- зывают смену процессов в мультипрограммной ОС, а прерывания от устройств ввода-вывода управляют потоками данных, которыми вычислительная система обменивается с внешним миром. Любое прерывание переводит процессор на выполнение потока команд, отличного от того, который выполнялся до сих пор, с после- дующим возвратом к исходному коду, т.е. прерывает выполнение текущего потока команд, что и дало название данному событию. Прерывание происходит в произвольной точке потока команд прог- раммы, которую программист не может прогнозировать. Прерыва- ние возникает либо в зависимости от внешних по отношению к про цессу выполнения программы событий, либо при появлении непред- виденных аварийных ситуаций в процессе выполнения данной программы.
В зависимое™ от источника прерывания делятся на три больших класса: • внешние, • внутренние; • программные. Внешние прерывания могут возникать в результате действий поль- зователя или оператора или же в результате поступления сигналов от аппаратных устройств — сигналов завершения операций ввода- вывода, вырабатываемых контроллерами внешних устройств ком- пьютера, такими как принтер или жесткий диск и т.д. Внешние пре- рывания называют также аппаратными, так как прерывание возни- кает вследствие подачи некоторой аппаратурой электрического сигнала, который передается на контроллер прерываний, а с него — на специальный вход прерывания процессора. Данный класс преры- ваний является асинхронным по отношению к потоку инструкций прерываемой программы. Аппаратура процессора работает так, что асинхронные прерывания возникают между выполнением двух со- седних инструкций; при этом система после обработки прерывания продолжает выполнение процесса, уже начиная со следующей ин- струкции. Внутренние прерывания, называемые также исключениями, проис- ходят синхронно выполнению программы при появлении аварийной ситуации в ходе исполнения некоторой инструкции программы. Примерами исключений являются деление на ноль, ошибки защиты памяти, обращения по несуществующему адресу, попытка выполнить привилегированную инструкцию в пользовательском режиме и т.п. Исключения возникают непосредственно в ходе выполнения тактов выполнения команды («внутри» выполнения). Программные прерывания отличаются от предыдущих двух классов тем, что они по своей сути не являются «истинными» прерываниями. Программное прерывание возникает при выполнении особой ко- манды процессора, выполнение которой имитирует прерывание, т.е. переход на новую последовательность инструкций. С помощью программных прерываний программист может вызывать функции ОС и функции BIOS. Прерываниям задаются приоритеты, с помощью которых они ранжируются по степени важности и срочности. О прерываниях, имеющих одинаковое значение приоритета, говорят, что они отно- сятся к одному уровню приоритета прерываний. Прерывания обрабатываются модулями операционной системы, так как действия, выполняемые по прерыванию, относятся к управ-
лснию разделяемыми ресурсами компьютера — принтером, диском, таймером, процессором и т.п. Процедуры, вызываемые по прерыва- ниям, обычно называют обработчиками прерываний или процедурами обслуживания прерываний {Interrupt Service Routine, I SR). Аппаратные прерывания обрабатываются драйверами соответствующих внешних устройств, исключения — специальными модулями ядра, а прог- раммные прерывания — процедурами ОС, обслуживающими сис- темные вызовы. Кроме этих модулей, в операционной системе может находиться так называемый диспетчер прерываний, который коор- динирует работу отдельных обработчиков прерываний. 4.2.2. Механизм прерываний Механизм прерываний поддерживается аппаратными средствами компьютера и программными средствами операционной системы. Аппаратная поддержка прерываний имеет свои особенности, зави- сящие от типа процессора и других аппаратных компонентов, пере- дающих сигнал запроса прерывания от внешнего устройства к про- цессору (таких как контроллер внешнего устройства, шины подклю- чения внешних устройств, контроллер прерываний, являющийся посредником между сигналами шины и сигналами процессора). Особенности аппаратной реализации прерываний оказывают влияние на средства программной поддержки прерываний, работа- ющие в составе ОС. Существуют два основных способа, с помощью которых шины выполняют прерывания: векторный {vectored) и опрашиваемый {polled). В обоих способах процессору предоставляется информация об уровне приоритета прерывания на шине подключения внешних устройств. В случае векторных прерываний в процессор передается также информация о начальном адресе программы обработки воз- никшего прерывания — обработчика прерываний. Устройствам, которые используют векторные прерывания, на- значается вектор прерываний. Он представляет собой электриче- ский сигнал, выставляемый на соответствующие шины процессора и несущий в себе информацию об определенном, закрепленном за данным устройством номере, который идентифицирует соответ- ствующий обработчик прерываний. Этот вектор может быть фик- сированным, конфигурируемым (например, с использованием пе- реключателей) или программируемым. Операционная система мо- жет предусматривать процедуру регистрации вектора обработки прерываний для определенного устройства, которая связывает не- которую подпрограмму обработки прерываний с определенным
вектором. При получении сигнала запроса прерывания процессор выполняет специальный цикл подтверждения прерывания, в кото- ром устройство должно идентифицировать себя. В течение этого цикла устройство отвечает, выставляя на шину вектор прерываний. Затем процессор использует этот вектор для нахождения обработ- чика данного прерывания. При использовании опрашиваемых прерываний процессор полу- чает от запросившего прерывание устройства только информацию об уровне приоритета. С каждым уровнем прерываний может быть связано несколько устройств и, соответственно, несколько прог- рамм — обработчиков прерываний. При возникновении прерывания процессор должен определить, какое устройство из тех, которые свя- заны с данным уровнем прерываний, действительно запросило пре- рывание. Это достигается вызовом всех обработчиков прерываний для данного уровня приоритета, пока один из обработчиков не под- твердит, что прерывание пришло от обслуживаемого им устройства. Если же с каждым уровнем прерываний связано только одно устрой- ство, то определение нужной программы обработки прерывания происходит немедленно, как и при векторном прерывании. Механизм прерываний некоторой аппаратной платформы может сочетать векторный и опрашиваемый типы прерываний. Типичным примером такой реализации является платформа персональных ком- пьютеров на основе процессоров Intel Pentium. Шины, используемые в этой платформе в качестве шин подключения внешних устройств, поддерживают механизм опрашиваемых прерываний. Контроллеры периферийных устройств выставляют на шину не вектор, а сигнал запроса прерывания определенного уровня IRQ. Однако в процес- соре Pentium система прерываний является векторной. Вектор пре- рываний в процессор Pentium поставляет контроллер прерываний, который отображает поступающий от шины сигнал IRQ на опреде- ленный номер вектора. Вектор прерываний, передаваемый в процессор, представляет собой целое число в диапазоне от 0 до 255, указывающее на одну из 256 программ обработки прерываний, адреса которых хранятся в таблице обработчиков прерываний. В том случае, когда к каждой линии IRQ подключается только одно устройство, процедура обра- ботки прерываний работает так, как если бы система прерываний была чисто векторной, т.е. процедура не выполняет никаких допол- нительных опросов для выяснения того, какое именно устройство запросило прерывание. Однако при совместном использовании од- ного уровня IRQ несколькими устройствами программа обработки
прерываний должна работать в соответствии со схемой опрашива- емых прерываний, т.е. дополнительно выполнить опрос всех устройств, подключенных к данному уровню IRQ Механизм прерываний чаще всего поддерживает приоритезацию и маскирование прерываний. Приоритезация означает, что все источники прерываний делятся на классы и каждому классу назна- чается свой уровень приоритета запроса на прерывание. Приоритеты могут обслуживаться как относительные и абсолютные. Обслужива- ние запросов прерываний по схеме с относительными приоритетами заключается в том, что при одновременном поступлении запросов прерываний из разных классов выбирается запрос, имеющий высший приоритет. Однако в дальнейшем при обслуживании этого запроса процедура обработки прерывания уже не откладывается даже в том случае, когда появляются более приоритетные запросы, — ре- шение о выборе нового запроса принимается только в момент завер- шения обслуживания очередного прерывания. Если же более прио- ритетным прерываниям разрешается приостанавливать работу про- цедур обслуживания менее приоритетных прерываний, то это означает, что работает схема приоритезации с абсолютными приори- тетами. Если процессор работает по схеме с абсолютными приоритетами, то он поддерживает в одном из своих внутренних регистров перемен- ную. фиксирующую уровень приоритета обслуживаемого в данный момент прерывания. При поступлении запроса из определенного класса его приоритет сравнивается с текущим приоритетом процес- сора; и если приоритет запроса выше, то текущая процедура обра- ботки прерываний вытесняется, а по завершении обслуживания нового прерывания происходит возврат к прерванной процедуре. Упорядоченное обслуживание запросов прерываний, наряду со схемами приоритетной обработки запросов, может выполняться механизмом маскирования запросов. Собственно говоря, в описанной схеме абсолютных приоритетов выполняется маскирование — при обслуживании некоторого запроса все запросы с равным или более низким приоритетом маскируются, т.е. не обслуживаются. Схема мас- кирования предполагает возможность временного маскирования пре- рываний любого класса независимо от уровня приоритета. Обобщенно последовательность действий аппаратных и прог- раммных средств по обработке прерывания можно описать следу- ющим образом. 1. П ри возникновении сигнала (для аппаратных прерываний) или условия прерывания (для внутренних прерываний; происходит
первичное аппаратное распознавание типа прерывания. Если пре- рывания данного типа в настоящий момент запрещены (приоритет- ной схемой или механизмом маскирования), то процессор продол- жает поддерживать естественный ход выполнения команд. В против- ном случае в зависимости от поступившей в процессор информации (уровень прерывания, вектор прерывания или тип условия внутрен- него прерывания) происходит автоматический вызов процедуры об- работки прерывания, адрес которой находится в специальной таб- лице операционной системы, размещаемой либо в регистрах процес- сора, либо в определенном месте оперативной памяти. 2. Автоматически сохраняется некоторая часть контекста пре- рванного потока, которая позволит ядру возобновить исполнение потока процесса после обработки прерывания. В это подмножество обычно включаются значения счетчика команд, слова состояния компьютера, хранящего признаки основных режимов работы про- цессора, а также нескольких регистров общего назначения, которые требуются программе обработки прерывания. Может быть сохранен и полный контекст процесса, если ОС обслуживает данное преры- вание со сменой процесса. Однако в общем случае это нс обяза- тельно, часто обработка прерываний выполняется без вытеснения текущего процесса. 3. Одновременно с загрузкой адреса процедуры обработки преры- ваний в счетчик команд может автоматически выполняться загрузка нового значения слова состояния компьютера, которое определяет режимы работы процессора при обработке прерывания, в том числе работу в привилегированном режиме. В некоторых моделях процес- соров переход в привилегированный режим за счет смены состояния машины при обработке прерывания является единственным способом смены режима. Прерывания практически во всех мультипрограммных ОС обрабатываются в привилегированном режиме модулями ядра, так как при этом обычно нужно выполнить ряд критических операций, от которых зависит жизнеспособность системы, — управлять внеш- ними устройствами, перепланировать потоки и т.п. 4. Временно запрещаются прерывания данного типа, чтобы не образовалась очередь вложенных друг в друга потоков одной и той же процедуры. Детали выполнения этой операции зависят от особенностей аппаратной платформы, например может исполь- зоваться механизм маскирования прерываний. Многие процессоры автоматически устанавливают признак запрета прерываний в начале цикла обработки прерывания, в противном случае это делает прог- рамма обработки прерываний.
5. После того как прерывание обработано ядром операционной системы, прерванный контекст восстанавливается и работа потока возобновляется с прерванного места. Часть контекста восстанавли- вается аппаратно по команде возврата из прерываний (например, адрес следующей команды и слово состояния машины), а часть — программным способом, с помощью явных команд извлечения дан- ных из стека. При возврате из прерывания блокировка повторных прерываний данного типа снимается. 4.2.3. Программные прерывания Программное прерывание реализует один из способов перехода на подпрограмму с помощью специальной инструкции процессора, например такой, как ПУТ в процессорах Intel Pentium. При выполне- нии команды программного прерывания процессор отрабатывает туже последовательность действий, что и при возникновении внеш- него или внутреннего прерывания, но только происходит это в пред- сказуемой точке программы — гам, где программист поместил дан- ную команду. Программные прерывания часто используются для выполнения ограниченного количества вызовов функций ядра операционной системы, т.е. системных вызовов. Еще одной из причин появления инструкций программных пре- рываний в системе команд процессоров является то, что их исполь- зование часто приводит к более компактному коду программ по срав- нению с использованием стандартных команд выполнения процедур. Это объясняется тем, что разработчики процессора обычно резерви- руют для обработки прерываний небольшое число возможных под- программ, так что длина операнда в команде программного преры- вания, который указывает на нужную подпрограмму, меньше, чем в команде перехода на подпрограмму. Например, в процессоре х86 предусмотрена возможность применения 256 программ обработки прерываний, поэтому в инструкции INT операнд имеет длину в один байт, а использование команды CALL потребовало бы уже не одно- байтовый, а двух- или четырехбайтовый операнд. Другой причиной применения программных прерываний вместо обычных инструкций вызова подпрограмм является возможность смены пользователь- ского режима на привилегированный одновременно с вызовом про- цедуры — это свойство программных прерываний поддерживается большинством процессоров.
4.2.4. Диспетчеризация и приоритезация прерываний в ОС Операционная система играет активную роль в организации про- цесса обработки прерываний. Прерывания выполняют очень полез- ную для компьютера функцию — они позволяют реагировать на асинхронные по отношению к вычислительному процессу собы- тия. В то же время прерывания создают дополнительные трудности для ОС в организации вычислительного процесса. Эти трудности связаны с непредвиденными переходами управления от одной про- цедуры к другой, возникающими в результате прерываний от внешних устройств. Возможно также возникновение в непредви- денные моменты времени исключений, связанных с ошибками во время выполнения инструкций. Усложняют задачу планирования вычислительных работ и запросы на выполнение системных функций (системные вызовы) от пользовательских приложений, выполняемые с помощью программных прерываний. Сами модули ОС также часто вызывают друг друга с помощью программных пре- рываний, еще больше запутывая картину вычислительного про- цесса. Для упорядочения работы обработчиков прерываний в операци- онных системах применяется тот же механизм, что и для упорядоче- ния работы пользовательских процессов, — механизм приоритетных очередей. Все источники прерываний обычно делятся на несколько классов, причем каждому классу присваивается приоритет. В опера- ционной системе выделяется программный модуль, который зани- мается диспетчеризацией обработчиков прерываний. Этот модуль в разных ОС называется по-разному, но для определенности будем его называть диспетчером прерываний. При возникновении прерывания диспетчер прерываний вызыва- ется первым. Он запрещает ненадолго все прерывания, а затем вы- ясняет причину прерывания. После этого диспетчер сравнивает на- значенный данному источнику прерывания приоритет с текущим приоритетом потока команд, выполняемого процессором В этот момент времени процессор уже может выполнять инструкции дру- гого обработчика прерываний, также имеющего некоторый приори- тет. Если приоритет нового запроса выше текущего, то выполнение текущего обработчика приостанавливается и он помещается в соот- ветствующую очередь обработчиков прерываний. В противном слу- чае в очередь помещается обработчик нового запроса.
4.2.5. Системные вызовы Системный вызов позволяет приложению обратиться к операци- онной системе с просьбой выполнить то или иное действие, оформ- ленное как процедура (функция) или набор процедур (функций) кодового сегмента ОС. Для прикладного программиста операцион- ная система выглядит как некая библиотека, предоставляющая не- который набор полезных функций, с помощью которых можно упро- стить прикладную программу или выполнить действия, запрещенные в пользовательском режиме, например обмен данными с устрой- ством ввода-вывода. Реализация системных вызовов должна удовлетворять следу- ющим требованиям: • обеспечивать переключение в привилегированный режим; • обладать высокой скоростью вызова процедур ОС; • обеспечивать по возможности единообразное обращение к сис- темным вызовам для всех аппаратных платформ, на которых ра- ботает ОС; • допускать легкое расширение набора системных вызовов; • обеспечивать контроль со стороны ОС за корректным использо- ванием системных вызовов. В большинстве ОС системные вызовы обслуживаются по центра- лизованной схеме, основанной на существовании диспетчера сис- темных вызовов (рис. 4.8). При любом системном вызове приложе- ние выполняет программное прерывание с определенным и един- ственным номером вектора. Перед выполнением программного прерывания приложение тем или иным способом передает операционной системе номер систем- Рис. 4.8. Централизованная схема обработки системных вызовов
ного вызова, который является индексом в таблице адресов процедур ОС, реализующих системные вызовы (таблица sysent на рис. 4.8). Способ передачи зависит от реализации: например, номер можно поместить в определенный регистр общего назначения процессора или передать через стек (в этом случае после прерывания и перехода в привилегированный режим их нужно будет скопировать в систем- ный стек из пользовательского, это действие в некоторых процессо- рах автоматизировано) Также некоторым способом передаются ар- гументы системного вызова: они могуч как помещаться в регистры обшего назначения, так и передаваться через стек или массив, нахо- дящийся в оперативной памяти. Массив удобен при большом объеме данных, передаваемых в качестве аргументов, при этом в регистре общего назначения указывается адрес этого массива. Диспетчер системных вызовов обычно представляет собой простую программу, которая сохраняет содержимое регистров про- цессора в системном стеке (поскольку в результате программного прерывания процессор переходит в привилегированный режим), проверяет, попадает ли запрошенный номер вызова в поддержива- емый ОС диапазон (т.е. нс выходит ли номер за границы таблицы) и передает управление процедуре ОС, адрес которой задан в таблице адресов системных вызовов. Процедура реализации системного вызова извлекает из систем- ного стека аргументы и выполняет заданное действие. Это действие может быть весьма простым, например чтение значения системных часов, так что системный вызов оформляется в виде одной функции. Более сложные системные вызовы, такие как чтение из файла или выделение процессу дополнительного сегмента памяти, требуют обращения основной функции системного вызова к нескольким внутренним процедурам ядра ОС, принадлежащим к различным подсистемам, таким как подсистема ввода-вывода или управления памятью. После завершения работы системного вызова управление возвра- щается диспетчеру, при этом он получает также код завершения этого вызова. Диспетчер восстанавливает регистры процессора, помещает в определенный регистр код возврата и выполняет инструкцию воз- врата из прерывания, которая восстанавливает непривилегирован- ный режим работы процессора. Операционная система может выполнять системные вызовы в синхронном или асинхронном режиме. Синхронный системный вы- зов означает, что процесс, сделавший такой вызов, приостанавлива- ется (переводится планировщиком ОС в состояние ожидания) до тех
пор, пока системный вызов не выполнит всю требующуюся от него работу (рис. 4.9, а). После этого планировщик переводит процесс в состояние готовности, и при очередном выполнении процесс га- рантированно может воспользоваться результатами завершившегося к этому времени системного вызова. Синхронные вызовы называ- ются также блокирующими, так как вызвавший системное действие процесс блокируется до его завершения. Прикладном Асинхронный системный вызов не приводит к переводу процесса в режим ожидания после выполнения некоторых начальных сис- темных действий, например запуска операции вывода-вывода, управление возвращается прикладному процессу (рис. 4.9, б). Большинство системных вызовов в операционных системах яв- ляются синхронными, так как этот режим избавляет приложение от работы по выяснению момента появления результата вызова. Вместе с тем в новых версиях операционных систем количество асинхронных системных вызовов постепенно увеличивается, что дает больше свободы разработчикам сложных приложений. Осо- бенно нужны асинхронные системные вызовы в операционных сис-
темах на основе микроядерного подхода, так как при этом в пользо- вательском режиме работает часть ОС, которым необходимо иметь полную свободу в организации своей работы, а такую свободу дает только асинхронный режим обслуживания вызовов микроядром. 4.3. Синхронизация процессов и потоков 4.3.1. Цели и средства синхронизации Существует достаточно обширный класс средств операционной системы, с помощью которых обеспечивается взаимная синхрони- зация процессов и потоков. Потребность в синхронизации потоков возникает только в мультипрограммной операционной системе и связана с совместным использованием аппаратных и информаци- онных ресурсов компьютера. Синхронизация необходима для исключения гонок и тупиков при обмене данными между потоками, разделении данных, при доступе к процессору и устройствам ввода- вывода. Во многих операционных системах эти средства называются сред- ствами межпроцессного взаимодействия — Inter Process Communica- tions (JPC), что отражает историческую первичность понятия «про- цесс» по отношению к понятию «поток». Обычно к средствам 1РС относят не только средства межпроцессной синхронизации, но и средства межпроцессного обмена данными. Любое взаимодействие процессов или потоков связано с их син- хронизацией, которая заключается в согласовании их скоростей пу- тем приостановки потока до наступления некоторого события и по- следующей его активизации при наступлении этого события. Син- хронизация лежит в основе любого взаимодействия потоков, связано ли это взаимодействие с разделением ресурсов или с обме- ном данными. Например, поток-получатель должен обращаться заданными только после того, как они помещены в буфер потоком- отправителем. Если же поток-получатель обратился к данным до мо- мента их поступления в буфер, то он должен быть приостановлен. При совместном использовании аппаратных ресурсов синхрони- зация также совершенно необходима. Когда, например, активному потоку требуется доступ к последовательному порту, а с этим портом в монопольном режиме работает другой поток, находящийся в дан- ный момент в состоянии ожидания, то ОС приостанавливает актив- ный поток и не активизирует его до тех пор, пока нужный ему порт не освободится. Часто нужна также синхронизация с событиями,
внешними по отношению к вычислительной системе, например ре- акция на нажатие комбинации клавиш CtrH-C. Ежесекундно в системе происходят сотни событий, связанных с распределением и освобождением ресурсов, и ОС должна иметь надежные и производительные средства, которые бы позволяли ей синхронизировать потоки с происходящими в системе событиями. 4,3.2. Необходимость синхронизации и гонки Пренебрежение вопросами синхронизации в многопоточной сис- теме может привести к неправильному решению задачи или даже к краху системы. Рассмотрим, например (рис. 4.10), задачу ведения базы данных клиентов некоторого предприятия. Каждому клиенту отводится отдельная запись в базе данных, в которой среди прочих полей имеются поля «Заказ» и «Оплата». Программа, ведущая базу данных, оформлена как единый процесс, имеющий несколько пото- ков, в том числе поток Л, который заносит в базу данных информа- цию о заказах, поступивших от клиентов, и поток В. кот орый фик- сирует в базе данных сведения об оплате клиентами выставленных счетов. Оба этих потока совместно работают над общим файлом базы данных, используя однотипные алгоритмы, включающие три шага. 1. Считать из файла базы данных в буфер запись о клиенте с за- данным идентификатором. Рис. 4.10. Возникновение гонок при доступе к разделяемым данным
2. Внести новое значение в поле «Заказ» (для потока А) или «Оплата» (для потока В). 3. Вернуть модифицированную запись в файл базы данных. Обозначим соответствующие шаги для потока А как Аъ А2 и А3, а для потока В как В. В3и В3. Предположим, что в некоторый мо- мент поток А обновляет поле «Заказ» записи о клиенте N. Для этого он считывает эту запись в свой буфер (шаг 3,), модифицирует значе- ние поля «Заказ» (шаг 32), но внести запись в базу данных (шаг Л3) не успевает, так как его выполнение прерывается, например, вслед- ствие завершения кванта времени. Предположим также, что потоку В также потребовалось внести сведения об оплате относительно того же клиента N. Когда подходит очередь потока В, он успевает считать запись в свой буфер (шаг В) и выполнить обновление поля «Оплата» (шаг В?), а затем прерыва- ется. Заметим, что в буфере у потока В находится запись о клиенте N, в которой поле «Заказ» имеет прежнее, неизмененное значение. Когда в очередной раз управление будет передано потоку А. то он, продолжая свою работу, запишет запись о клиенте N с модифициро- ванным полем «Заказ» в базу данных (шаг А3). После прерывания по- тока А и активизации потока В последний запишет в базу данных по- верх только что обновленной записи о клиенте Лиевой вариант записи, в которой обновлено значение поля «Оплата». Таким образом, в базе данных будут зафиксированы сведения о том, что клиент N произвел оплату, но информация о его заказе окажется потерянной (рис. 4.11, а). Рис. 4.11. Влияние относительных скоростей потоков на результат решения задачи
Сложность проблемы синхронизации кроется в нерегулярности возникающих ситуаций. Так, в предыдущем примере можно пред- ставить и другое развитие событий: могла быть потеряна информа- ция не о заказе, а об оплате (рис. 4.11, б) или, напротив, все исправ- ления были успешно внесены (рис. 4.11, в). Все определяется взаим- ными скоростями потоков и моментами их прерывания. Поэтому отладка взаимодействующих потоков является сложной задачей. Ситуации, подобные той, когда два или более потока обрабатывают разделяемые данные и конечный результат зависит от соотношения скоростей потоков, называются гонками. 4.3.3. Критическая секция и блокирующие переменные Важным понятием синхронизации потоков является понятие «критической секции» про1раммы. Критическая секиия — это часть программы, результат выполнения которой может непредсказуемо меняться, если переменные, относящиеся к этой части программы, изменяются другими потоками в то время, когда выполнение этой части еще не завершено. Критическая секция всегда определяется по отношению к определенным критическим данным, при несогла- сованном изменении которых могут возникнуть нежелательные эф- фекты. Чтобы исключить эффект гонок по отношению к критическим данным, необходимо обеспечить, чтобы в каждый момент времени в критической секции, связанной с этими данными, находился только один поток. При этом неважно, находится этот поток в ак- тивном или в приостановленном состоянии. Этот прием называют взаимным исключением. Для синхронизации потоков одного процесса прикладной прог- раммист может использовать глобальные блокирующие переменные. С этими переменными, к которым все потоки процесса имеют пря- мой доступ, программист работает, не обращаясь к системным вы- зовам ОС. Каждому набору критических данных ставится в соответствие двоичная переменная, которой поток присваивает значение 0, когда он входит в критическую секцию, и значение 1, когда он ее покидает. На рис. 4.12 показан фрагмент алгоритма потока, использующего для реализации взаимного исключения доступа к критическим данным D блокирующую переменную F(D). Перед входом в критическую сек- цию поток проверяет, не работает ли уже какой-нибудь поток с дан- ными D. Если переменная F(D) установлена в 0, то данные заняты и проверка циклически повторяется Если же данные свободны
Рис. 4.12. Реализация критических секций с использованием блокирующих переменных (F(D) = 1), то значение переменной F(D) устанавливается в 0 и поток входит в критическую секцию. После того как поток выполнит все действия с данными D. значение переменной 1(D) снова устанавли- вается равным 1. Блокирующие переменные могут использоваться не только при доступе к разделяемым данным, но и при доступе к разделяемым ресурсам любого вида. Если все потоки написаны с учетом вышеописанных соглашений, то взаимное исключение гарантируется. При этом потоки могут быть прерваны операционной системой в любой момент и в любом месте, в том числе в критической секции, хотя одно ограничение на преры- вания все же имеется. Нельзя прерывать поток между выполнением операций проверки и установки блокирующей переменной. Реализация взаимного исключения списанным выше способом имеет существенный недостаток: в течение времени, когда один по- ток находится в критической секции, другой поток, которому требу- ется тот же ресурс, получив доступ к процессору, будет непрерывно
опрашивать блокирующую переменную, бесполезно тратя выделя- емое ему процессорное время, которое могло бы быть использовано для выполнения какого-нибудь другого потока. Для устранения этого недостатка во многих ОС предусматриваются специальные систем- ные вызовы для работы с критическими секциями. На рис. 4.13 показано, как с помощью этих функций можно реа- лизовать взаимное исключение. Перед тем как начать изменение критических данных, поток выполняет системный вызов EnterCriti- calSection(). В рамках этого вызова сначала выполняется, как и в пре- дыдущем случае, проверка блокирующей переменной, отражающей состояние критического ресурса. Если системный вызов определил, что ресурс занят (/•(/)) = 0), он, в отличие от предыдущего случая, Рис. 4.13. Реализация взаимного исключения с использованием системных функций входа в критическую секцию и выхода из нее
не выполняет циклический опрос, а переводит поток в состояние ожидания (D) и делает отметку о том, что данный поток должен быть активизирован, когда соответствующий ресурс освободится. Поток, который в это время использует данный ресурс, после выхода из кри- тической секции должен выполнить системную функцию LeavcCrit- icalSectionQ, в результате чего блокирующая переменная принимает значение, соответствующее свободному состоянию ресурса (F(D) = 1), а операционная система просматривает очередь ожидающих этот ресурс потоков и переводит первый поток из очереди в состояние готовности 4.3.4. Семафоры Обобщением блокирующих переменных являются так называ- емые семафоры Дийкстры. Вместо двоичных переменных Дийкстра предложил использовать переменные, которые могут принимать це- лые неотрицательные значения. Такие переменные, используемые для синхронизации вычислительных процессов, получили название семафоров. Для работы с семафорами вводятся два примитива, традиционно обозначаемых Р и V. Пусть переменная S представляет собой сема- фор. Тогда действия И(5) и P(S) определяются следующим образом. V(S): переменная S увеличивается на 1. Выборка, наращивание и запоминание не могут быть прерваны. К переменной S нет доступа другим потокам во время выполнения этой операции. P(Sp. уменьшение S на 1, если это возможно. Если S= 0 и невоз- можно уменьшить S, оставаясь в области целых неотрицательных значений, то в этом случае поток, вызывающий операцию Р(З'). ждет, пока это уменьшение станет возможным. Успешная проверка и уменьшение также являют ся неделимой операцией. Никакие прерывания во время выполнения примитивов V и Р не допустимы. Рассмотрим использование семафоров на классическом примере взаимодействия двух выполняющихся в режиме мультипрограмми- рования потоков, один из которых пишет данные в буферный пул, а другой считывает их из буферного пула. Пусть буферный пул со- стоит из W буферов, каждый из которых может содержать одну за- пись. В общем случае поток-писатель и поток-читатель могут иметь различные скорости и обращаться к буферному пулу с переменной интенсивностью. В один период скорость записи может превышать скорость чтения, в другой — наоборот. Для правильной совместной работы поток-писатель должен приостанавливаться, когда все бу-
ферм оказываются занятыми, и активизироваться при освобождении хотя бы одного буфера. Напротив, поток-читатель должен приоста- навливаться, когда все буферы пусты, и активизироваться при появ- лении хотя бы одной записи. Введем два семафора: е — число пустых буферов и/ — число за- полненных буферов, причем в исходном состоянии е = N, af = 0. Тогда работа потоков с общим буферным пулом может быть описана следующим образом (рис. 4.14). Рис. 4.14. Использование семафоров для синхронизации потоков Поток-писатель прежде всего выполняет операцию Р(е), с по- мощью которой он проверяет, имеются ли в буферном пуле незапол- ненные буферы. В соответствии с семантикой операции Р, если се- мафор е равен 0 (т е. свободных буферов в данный момент нет), поток-писатель переходит в состояние ожидания. Если же значе- нием е является положительное число, то он уменьшает число сво- бодных буферов, записывает данные в очередной свободный буфер и после этого наращивает число занятых буферов операцией V(f). Поток-читатель действует аналогичным образом с той лишь разни- цей, что он начинает работу с проверки наличия заполненных буфе- ров, а после чтения данных наращивает количество свободных буфе- ров. Семафор может использоваться и в качестве блокирующей пере- менной. В рассмотренном выше примере, для того чтобы исключить коллизии при работе с разделяемой областью памяти, будем считать, что запись в буфер и считывание из буфера являются критическими
секциями. Взаимное исключение будем обеспечивать с помощью двоичного семафора b (рис. 4.15). Оба потока после проверки доступ- ности буферов должны выполнить проверку доступности критиче- ской секции. Псток-писатель Поток-чгтатель Р(е) — если есть свободные буферы, то уменьшить их количество, если кет, то перей-и в состояние ОЖИДАНИЕ Р(6 — если есть заполненные буферы, то уменьшит.» их числе на 1, если нет, то перейти в состояние ОЖИДАНИЕ Р(Ь) — если критическая секция доступна, то установите признак «Занято», если нет, то перейти в состояние СЖИДАНИЕ 7(b) — освободить критическую секцию Буферный пул Критическая секция Критическая секция Р(Ь) — если критическая секция доступна, то установить признак «Занято», если нет, то перейти в состояние ОЖИДАНИЕ 7(b) — освободить критическую секцию V(f) — нарастить число занятых буферов 7(6 — нарастить число занятых буферов Рис, 4.15. Использование двоичного семафора 4.3.5. Тупики Приведенный выше пример позволяет также проиллюстрировать еще одну проблему синхронизации — взаимные блокировки, назы- ваемые также дед юками {deadlocks), клинчами (clinch) или тупиками. Если в рассмотренном примере переставить местами операции Р(е) и Р(Ь) в потоке-писателе, то при некотором стечении обстоятельств эти два потока могут взаимно блокировать друг друга. Итак, пусть поток-писатель начинает свою работу с проверки до- ступности критической секции — операции Р(Ь) и пусть он первым войдет в критическую секцию. Выполняя операцию Р(е), он может обнаружить отсутствие свободных буферов и перейти в состояние ожидания. Как уже было показано, из этого состояния его может вывести только поток-читатель, который возьмет очередную запись из буфера. Но поток-читатель не сможет этого сделать, так как для этого ему потребуется войти в критическую секцию, вход в которую
заблокирован потоком-писателем. Таким образом, ни один из этих потоков не может завершить начатую работу и возникнет тупиковая ситуация, которая не может разрешиться без внешнего воздействия. Невозможность потоков завершить начатую работу из-за возник- новения взаимных блокировок снижает производительность вычис- лительной системы. Поэтому проблеме предотвращения тупиков уделяется большое внимание. На тот случай, когда взаимная блоки- ровка все же возникает, система должна предоставить администра- тору или оператору средства, с помощью которых он смог бы распо- знать тупик, отличить его от обычной блокировки из-за временной недоступности ресурсов. И наконец, если тупик диагностирован, то нужны средства для снятия взаимных блокировок и восстановле- ния нормального вычислительного процесса. Другой, более гибкий подход к предотвращению тупиков заклю- чается в том, что ОС каждый раз при запуске задач анализирует их потребности в ресурсах и определяет, может ли в данной мультипро- граммной смеси возникнуть туттик. Если да, то запуск новой задачи временно откладывается. ОС может также использовать опреде- ленные правила при назначении ресурсов потокам, например ре- сурсы могут выделяться операционной системой в определенной последовательности, общей для всех потоков. Выводы Мультипрограммирование, или многозадачность (multitasking), — это способ организации вычислительного процесса, при котором на одном процессоре попеременно выполняются сразу несколько программ. Мультипрограммирование применяется для повышения эффек- тивности вычислительной системы, которая может пониматься как: • общая пропускная способность вычислительной системы; • удобство работы пользователей, например возможность интерак- тивной работы для нескольких пользователей или возможность одновременной работы одного пользователя с несколькими при- ложениями на одной машине; • реактивность системы, т.е. способность системы выдерживать заранее заданные (возможно, очень короткие) интервалы времени между запуском программы и получением результата. В зависимости от выбранного критерия эффективности ОС де лятся на системы пакетной обработки, системы разделения времени и системы реального времени.
Мультипроцессорная обработка — это способ организации вы- числительного процесса в системах с несколькими процессорами, при котором несколько задач (процессов, потоков) могут одновре- менно выполняться на разных процессорах системы. Основной задачей мультипрограммной операционной системы является распределение ресурсов между процессами и потоками — двумя базовыми единицами работы ОС. В операционных системах, в которых существуют как процессы, так и потоки, процесс рассматривается операционной системой как заявка на потребление всех видов ресурсов, кроме одного — процес- сорного времени. Процессорное время распределяется ОС между другими единицами работы — потоками, представляющими собой последовательности команд. Потоки возникли в операционных системах как средство распа- раллеливания вычислений, облегчающее работу программиста. В ОС, не поддерживающей потоки, процесс всегда состоит из одного потока, а программисту приходится самостоятельно решать задачу синхронизации нескольких параллельных ветвей программы. Операционная система для реализации мультипрограммирования выполняет планирование и диспетчеризацию потоков (в ОС, не под- держивающих потоки, — диспетчеризацию процессов). Планирова- ние включает определение момента времени для смены текущего потока, а также выбор нового потока для выполнения. Диспетчери- зация заключается в реализации найденного в результате планиро- вания решения, т.е. в переключении процессора с одного потока на другой. Планирование может выполняться динамически, когда решения принимаются во время работы системы на основе анализа текущей ситуации, или статически, если потоки запускаются на выполнение на основании заранее разработанного расписания. Первый способ характерен для универсальных ОС, а второй — для специализиро- ванных ОС, например ОС реального времени. Динамический планировщик ОС может реализовывать различные алгоритмы планирования, которые делятся на такие крупные классы, как вытесняющие и невытесняющие алгоритмы, алгоритмы квантования и приоритетные алгоритмы. Используемый алгоритм планирования зависит от назначения ОС. Применяются также сме- шанные алгоритмы, объединяющие достоинства нескольких классов. При применении вытесняющих алгоритмов планирования ОС получает полный контроль над вычислительным процессом, а при применении невытесняющих алгоритмов решения принимаются
децентрализованно: активный поток определяет момент смены по- токов, а ОС выбирает новый поток для выполнения. Система прерываний позволяет ОС реагировать на внешние со- бытия, происходящие асинхронно вычислительному процессу: сиг- налы готовности устройств ввода-вывода; аварийные сигналы аппа- ратуры вычислительной системы и т.п. В зависимости от источника прерывания делятся на три больших класса: • внешние прерывания, связанные с сигналами от внешних устройств; • внутренние прерывания, возникающие в результате ошибок вы- числений; • программные прерывания, представляющие собой удобный спо- соб вызова процедур операционной системы. Механизм прерываний поддерживается аппаратными средствами компьютера и программными средствами операционной системы. Существуют два основных способа выполнения прерывания, век- торный (vectored), когда в процессор передается номер вызываемой процедуры обработки прерывания, и опрашиваемый (polled), когда процессор вынужден последовательно опрашивать потенциальные источники запроса прерывания. Для упорядочивания процессов обработки прерываний все источ- ники прерываний распределяются по нескольким приоритетным уровням, а роль арбитра выполняет диспетчер прерываний ОС Системные вызовы, с помощью которых приложения получают обслуживание со стороны ОС, реализуются на основе механизма программных прерываний. Системные вызовы могут выполняться синхронно, когда поток приостанавливается до завершения систем- ного вызова, или асинхронно, когда поток продолжает работу парал- лельно с системной процедурой, реали зующей вызов. Для синхронизации процессов и потоков, решающих общие за- дачи и совместно использующих ресурсы, в операционных системах существуют специальные средства: критические секции и семафоры. Отсутствие синхронизации может приводить к таким нежелательным последствиям, как гонки и тупики. Вопросы для самоконтроля 1. Поясните употребление терминов «программа», «процесс», «задача», «поток», «нить». 2. В чем состоит принципиальное отличие состояний «ожидания» и «готов- ности» потока, ведь и в том и в другом он ожидает некоторого события?
3. Мультипрограммные операционные системы принято разделять на сис- темы реального времени, системы разделения времени, системы пакет- ной обработки. С другой стороны, алгоритмы планирования могут быть основаны на квантовании, относительных приоритетах, абсолютных приоритетах. Предложите для каждого из перечисленных типов ОС наиболее подходящий, по вашему мнению, тип алгоритма планирова- ния. 4 В какой очереди (ожидающих или готовых) скапливается большее число процессов: а) в интерактивных системах разделения времени; б) в системах пакетной обработки, решающих «счетные» задачи? 5. Известно, что программа А выполняется в монопольном режиме за 10 мин, а программа В — за 20 мин, т.е. при последовательном вы- полнении они требуют 30 мин. Если Т — время выполнения обеих этих задач в режиме мультипрограммирования, то какое из неравенств, при- веденных ниже, справедливо: а) 74 10; б) 10< Т<20-> в) 20 < Т< 30; г) Г>30? 6. Может ли процесс в мультипрограммном режиме выполняться быстрее, чем в монопольном? 7. Чем объясняется потенциально более высокая надежность операцион- ных систем, в которых реализована вытесняющая многозадачность? 8. При невытесняющем планировании необходимо, чтобы во всех выпол- няющихся программах были предусмотрены кодовые последователь- ности, которые передают управление ОС Эти точки возврата управ- ления прикладной программист должен определить заранее, еще до вы- полнения программы. Можно ли сказать, что в этом случае мы имеем дело со статическим планированием? 9. Приведите пример алгоритма планирования, в результате работы кото- рого процесс, располагая всеми необходимыми ресурсами, может бес- конечно долго находиться в системе, не имея возможности завер- шиться. 10. Для тех вариантов, которые вы считаете возможными, опишите более подробно алгоритм планирования. 11. Являются ли синонимами термины «планирование процессов» и «дис- петчеризация процессов»? 12. Можно ли задачу планирования процессов целиком возложить на при- ложения? 13. Приведите пример задачи, при программировании которой использо- вание механизма потоков может привести к существенному повыше- нию скорости ее выполнения. 14. Сравните два варианта организации мультипроцессорной обработки В первом случае процесс (поток), начав выполняться на каком-либо
процессоре, при каждой следующей активизации будет назначаться планировщиком на этот же процессор. Во втором варианте процесс (поток) каждый раз в общем случае выполняется на произвольно вы- бранном свободном процессоре. Какой вариант эффективнее в отно- шении времени выполнения отдельного приложения? В отношении суммарной производительности компьютера? 15. Представьте себе ОС, разработанную для компьютера, в котором отсут- ствует система прерываний. Какой алгоритм планирования процессов может быть реализован в такой ОС? 16. Какие события вызывают перепланирование процессов (потоков)? 17. Поясните разницу между программными и аппаратными прерывани- ями. 18. Что такое вектор прерываний? 19. Какой тип системы прерываний — векторный или опрашиваемый — реализован в процессоре Pentium? 20. Всегда ли прерывание вызывает перепланировку процессов? 21. Какими средствами синхронизации процессов располагает совре- менная ОС? 22. Представим себе двух студентов, которым нужно поработать с одной и той же книгой, имеющейся в библиотеке в единственном экземпляре. Они одновременно пришли в библиотеку, но один из них сначала по- шел в читальный зал и, заняв единственное свободное место, отпра- вился в книжное хранилище, а другой — наоборот, начал с того, что получил книгу, а потом пошел в читальный зал искать место. В резуль- тате ни один из них не может выполнить работу, так как для этого им не хватает необходимого ресурса. Можно ли считать, что в данном слу- чае произошла взаимная блокировка или, другими словами, клинч?
Глава 5 УПРАВЛЕНИЕ ПАМЯТЬЮ 5.1. Функции операционной системы по управлению памятью Память как важнейший ресурс компьютера требует тщательного управления со стороны операционной системы. Особая ее роль объ- ясняется тем, что процессор не может выполнять команды прог- раммы, пока они не будут загружены в память. Память распределя- ется как между модулями прикладных программ, модулями сис- темных программ, так и между модулями самой операционной системы. В этой главе под памятью мы будем подразумевать оперативную память — ОЗУ (Random Access Memory — RAM) или основную па- мять компьютера (main memory). Мультипрограммная операционная система выполняет следу- ющие функции по управлению памятью: • отслеживание свободной и занятой памяти; • выделение памяти процессам и освобождение памяти по завер- шении процессов; • вытеснение кодов и данных процессов из оперативной памяти на диск (полное или частичное), когда размеры основной памяти недостаточны для размещения в ней всех процессов, и возвраще- ние их в оперативную память, когда в ней освобождается место; • настройка адресов программы на конкретную область физиче- ской памяти; • динамическое распределение памяти, т.е. выполнение запросов приложений на выделение им дополнительной памяти во время их выполнения. После того как приложение перестает ну- ждаться в дополнительной памяти, оно может возвратить ее системе; • дефрагментация памяти; • выделение памяти для создаваемых ОС служебных информацион- ных структур, таких как описатели процессов и потоков, различ- ные таблицы распределения ресурсов, буферы, используемые про- цессами для обмена данными, синхронизирующие объекты и т.п.;
защита памяти, которая состоит в том, чтобы нс позволить вы- полняемому процессу записывать или читать данные из памяти, назначенной другому процессу. 5.2. Типы адресов Для идентификации переменных и команд на разных этапах прог раммирования используются символьные имена, виртуальные и фи- зические адреса (рис. 5.1). Текст программы Пространство имен программы Символьное имя 1 Символьное имя Л/ Пространство команд программы Транслятор Виртуальное адресное пространство Виртуальный адрес О Виртуальный адрес М Операционная система Физическое адресное пространство Физический адрес (ячейка оперативной памяти) Рис. 5.1. Типы адресов
Символьные имена (метки) присваивает программист в процессе создания программы (например, метки в тексте программы). Виртуальные адреса формирует транслятор в процессе трансляции исходного текста программы на машинный язык. Поскольку во время трансляции в общем случае неизвестно, в какое место опе- ративной памяти будет загружена программа, то транслятор присваи- вает переменным и командам виртуальные (условные) адреса, обычно считая по умолчанию, что программы будут начинаться с ну- левого адреса. Физические адреса соответствуют номерам ячеек оперативной па- мяти. где в действительности расположены или будут расположены переменные и команды программы после запуска программы на вы- полнение. Совокупность виртуальных адресов процесса называется виртуаль- ным адресным пространством. Диапазон возможных адресов вирту- ального пространства у всех процессов является одним и тем же. На- пример, при использовании 32-разрядных виртуальных адресов этот диапазон задается границами 0000000016 и FFFFFFFF]6. Тем не менее каждый процесс имеет собственное виртуальное адресное простран- ство — транслятор присваивает виртуальные адреса переменным и ко- дам каждой программы независимо от других программ (рис. 5.2). Совпадение виртуальных адресов переменных и команд различ- ных процессов не приводит к конфликтам, так как в том случае, когда эти переменные и процессы одновременно присутствуют в па- мяти, операционная система отображает их на разные физические адреса. В разных операционных системах используются разные способы структуризации виртуального адресного пространства. В одних ОС виртуальное адресное пространство процесса, подобно физической памяти, представлено в виде непрерывной линейной последователь- ности виртуальных адресов. Такую структуру адресного пространства называют также плоской {flat). При этом виртуальным адресом явля- ется единственное число (т), представляющее собой смещение от- носительно начала (обычно это значение ООО...000) виртуального адресного пространства и номером конкретной ячейки (рис. 5.3, а). .Адрес такого типа называют линейным виртуальным адресом. В других ОС виртуальное адресное пространство делится на части, называемые сегментами (секциями). В этом случае помимо линейного адреса может быть использован виртуальный адрес, пред- ставляющий собой пару чисел (п, т), где п определяет сегмент, а т — смещение внутри сегмента (рис. 5.3,5).
Виртуальное Виртуальные адресное пространство Физические адреса процесса! адоеса Оперативная память FFFFFFFF16 OOGFFFFO16 Переменная А — оооооооо16 — Переменная А DPip I ya) iDriue адресное пространство процесса 2 FFFFFFFF , 10 OOOFFFFO.. Команда Подпрограмма 5 oocooooo16 Виртуальное адресное пространство/\ /\ процесса 3 / \ у \ FFFFFFFF16 000FFFF016 Подпрограмма 5 Команда оосооооо16 Рис. 5-3. Типы виртуальных адресных пространств: а — плоское; б — сегментированное Рис. 5.2. Виртуальное адресное пространство нескольких процессов 6)
Задачей операционной системы является отображение индиви- дуальных виртуальных адресных пространств всех одновременно выполняющихся процессов на общую физическую память. Существуют два принципиально отличающихся подхода к пре- образованию виртуальных адресов в физические. В первом случае замена виртуальных адресов на физические вы- полняется один раз для каждого процесса во время начальной за- грузки программы в память. Специальная системная программа — перемещающий загрузчик — на основании имеющихся у нее исходных данных о начальном адресе физической памяти, в которую предстоит загружать программу, а также информации, предоставленной транс- лятором об адресно зависимых элементах программы, выполняет загрузку программы, совмещая се с заменой виртуальных адресов физическими. Второй способ заключается в том, что программа загружается в па- мять в неизмененном виде в виртуальных адресах, т.е. операнды ин- струкций и адреса переходов имеют тс значения, которые выработал транслятор. В наиболее простом случае, когда виртуальная и физи- ческая память процесса представляют собой единые непрерывные области адресов, операционная система выполняет преобразование виртуальных адресов в физические по следующей схеме. При загрузке операционная система фиксирует смещение дей- ствительного расположения программного кода относительно вир- туального адресного пространства. Во время выполнения программы при каждом обращении к оперативной памяти выполняется преобра- зование виртуального адреса в физический. Схема такого преобра- зования показана на рис. 5.4. Пусть, например, операционная система использует линейно- структурированное виртуальное адресное пространство и пусть не- которая программа, работающая под управлением этой ОС, загру- жена в физическую память, начиная с физического адреса S ОС запоминает значение начального смещения 5 и во время выполнения программы помещает его в специальный регистр процессора. При обращении к памяти виртуальные адреса данной программы прео- бразуются в физические путем прибавления к ним смещения 5. На- пример, при выполнении команды MOV А, В (пересылки данных), находящейся по адресу VA, виртуальный адрес VA заменяется физи- ческим адресом VA + S. Последний способ является более гибким: в то время как переме- щающий загрузчик жестко привязывает программу к первоначально выделенному ей участку памяти, динамическое преобразование вир-
Рис. 5.4. Схема динамического преобразования адресов туальных адресов позволяет перемещать программный код процесса в течение всего периода его выполнения. Но использование переме- щающего загрузчика более экономично, так как в этом случае пре- образование каждого виртуального адреса происходит только один раз во время загрузки, а при динамическом преобразовании — при каждом обращении по данному адресу. В некоторых случаях (обычно в специализированных системах), когда заранее точно известно, в какой области оперативной памяти будет выполняться программа, транслятор выдает исполняемый код сразу в физических адресах. Необходимо различать максимально возможное виртуальное адрес- ное пространство процесса и назначенное (выделенное) процессу вир- туальное адресное пространство. В первом случае речь идет о макси- мальном размере виртуального адресного пространства, определя- емом архитектурой компьютера, на котором работает ОС, в частности разрядностью его шины адреса (32-битная, 64-битная и т.п.). Например, при работе на компьютерах с 32-разрядной шиной адреса (процессор Intel Pentium) операционная система может пре- доставить каждому процессу виртуальное адресное пространство до 4 Гбайт. Однако это значение представляет собой только потен- циально возможный размер виртуального адресного пространства, который редко на практике присутствует в компьютере и бывает не-
обходим процессу. Процесс использует только часть доступного ему виртуального адресного пространства. Назначенное виртуальное адресное пространство представляет со- бой набор виртуальных адресов, действительно нужных процессу для работы. Эти адреса первоначально назначает программе транслятор на основании текста программы, когда создает кодовый (текстовый) сегмент, а также сегмент или сегменты данных, с которыми программа работает. Затем при создании процесса ОС фиксирует назначенное виртуальное адресное пространство в своих системных таблицах. В ходе своего выполнения процесс может увеличить размер первона- чального назначенного ему виртуального адресного пространства, запросив у ОС создания дополнительных сегментов или увеличения размера существующих. В любом случае операционная система обычно следит за корректностью использования процессом виртуаль- ных адресов — процессу не разрешается оперировать с виртуальным адресом, выходящим за пределы назначенных ему сегментов. Сегодня для машин универсального назначения типична си- туация, когда объем виртуального адресного пространства превы- шает доступный объем оперативной памяти. В таком случае опера- ционная система для хранения данных виртуального адресного про- странства процесса, нс помещающихся в оперативную память, использует внешнюю память, которая в современных компьютерах представлена жесткими дисками (рис. 5.5). Именно на этом прин- ципе основана виртуальная память — наиболее совершенный меха- низм, используемый в операционных системах для управления па- мятью. Содержимое назначенного процессу виртуального адресного про- странства, т.е. коды команд, исходные и промежуточные данные, а также результаты вычислений, представляет собой образ процесса. Во время работы процесса постоянно выполняются переходы от прикладных кодов к кодам ОС, которые либо явно вызываются из прикладных процессов как системные функции, либо вызываются как реакция на внешние события или на исключительные ситуации, возникающие при некорректном поведении прикладных кодов. Для того чтобы упростить передачу управления от прикладного кода к коду ОС, а также для легкого доступа модулей ОС к прикладным данным (например, для вывода их на внешнее устройство) в боль- шинстве ОС ее сегменты разделяют виртуальное адресное простран- ство с прикладными сегментами активного процесса. То есть сег- менты ОС и сегменты активного процесса образуют единое вирту- альное адресное пространство.
Виртуальное адресное пространство процесса 1 Рис. 5.5. Механизм виртуальной памяти Обычно виртуальное адресное пространство процесса делится на две непрерывные части: системную и пользовательскую. Часть виртуального адресного пространства каждого процесса, отводимая под сегменты ОС, является идентичной для всех процес- сов. Поэтому при смене активного процесса заменяется только вто- рая часть виртуального адресного пространства, содержащая его индивидуальные сегменты, как правило — коды и данные приклад- ной программы (рис. 5.6). / Виртуальное 4 адресное пространство Виртуальное 1рОцесса W адресное пространство процесса 1 Общая часть виртуальных адресных пространств Рис. 5.6. Общая и индивидуальные части виртуальных адресных пространств
5.3. Алгоритмы распределения памяти Все алгоритмы распределения памяти разделены на два класса: алгоритмы, в которых используется перемещение сегментов процес- сов между оперативной памятью и диском, и алгоритмы, в которых внешняя память не привлекается (рис. 5 7) Методы распределения памяти '__________I Распределение памяти без использования внешней памяти Распределение памяти фиксированными разделами Распределение памяти динамическими разделами Распределение памяти перемещаемыми разделами Распределение памяти с использованием внешней памяти Страничное распределение памяти Сегментное распределение памяти Сегментно-страничное распределение памяти Рис. 5.7. Классификация методов распределения памяти 5.3.1 Распределение памяти фиксированными разделами Простейший способ управления оперативной памятью состоит в том, что память разбивается на несколько областей фиксированной величины, называемых раздела ми Такое разбиение может быть вы- полнено вручную оператором во время старта системы или во время ее установки. После этого границы разделов не изменяются. Очередной новый процесс, поступивший на выполнение, поме- щается либо в общую очередь (рис. 5 8, а), либо в очередь к некото- рому разделу (рис. 5.8, б). Подсистема управления памятью в этом случае выполняет следу- ющие задачи: • сравнивает объем памяти, требуемый для вновь поступившего процесса, с размерами свободных разделов и выбирает подходя- щий раздел;
a') ОС Раздел О Процесс А Раздел 1 Раздел 2 ' Раздел N Раздел О Раздел 1 Раздел 2 1 Раздел N Рис. 5.8. Распределение памяти фиксированными разделами: а — с общей очередью; б — с отдельными очередями
• осуществляет загрузку программы в один из разделов и настройку адресов. Уже на этапе трансляции разработчик программы может задать раздел, в котором ее следует выполнять. Это позволяет сразу, без использования перемещающего загрузчика получить машинный код, настроенный на конкретную область памяти. При очевидном преимуществе — простоте реализации, данный метод имеет существенный недостаток — жесткость. Так как в каждом разделе может выполняться только один процесс, то уро- вень мультипрограммирования заранее ограничен числом разделов. Независимо от размера программы она будет занимать весь раздел. Так, например, в системе с тремя разделами невозможно выполнять одновременно более трех процессов, даже если им требуется совсем мало памяти. С другой стороны, разбиение памяти на разделы не по- зволяет выполнять процессы, программы которых не помещаются ни в один из разделов, но для которых было бы достаточно памяти нескольких разделов. Такой способ управления памятью применялся в ранних мульти- программных ОС Однако и сейчас метод распределения памяти фиксированными разделами находит применение в системах реаль- ного времени, в основном благодаря небольшим затратам на реали- зацию. 5.3 2. Распределение памяти динамическими разделами В этом случае память машины не делится заранее на разделы. Сначала вся память, отводимая для приложений, свободна. Каждому вновь поступающему на выполнение приложению на этапе создания процесса выделяется вся необходимая ему память (если достаточный объем памяти отсутствует, то приложение не принимается на выпол- нение и процесс для него не создается). После завершения процесса память освобождается и на это место может быть загружен другой процесс. Таким образом, в произвольный момент времени оператив- ная память представляет собой случайную последовательность заня- тых и свободных участков (разделов) произвольного размера. На рис. 5.9 показано состояние памяти в различные моменты вре- мени при использовании динамического распределения. Так, в мо- мент t0 в памяти находится только ОС, а к моменту tt память разде- лена между пятью процессами, причем процесс П4, завершаясь, покидает память. На освободившееся от процесса П4 место загружа- ется процесс П6, поступивший в момент t3. Для реализации данного метода управления памятью операцион- ная система выполняет следующие функции:
ОС ос Процесс П4 завершен ос Создан новый гроцесс Пб ОС Свободная память П1 П1 П1 П2 П2 Г12 пз ПЗ ПЗ П4 Свободная память Пб Свободная память П5 П5 П5 Свободная память Свободная память Свободная память t0 t, tj f3 Рис. 5.9. Распределение памяти динамическими разделами • ведение таблиц свободных и занятых областей, в которых указы- ваются начальные адреса и размеры участков памяти; • при создании нового процесса — анализ требований к памяти, просмотр таблицы свободных областей и выбор раздела, размер которого достаточен для размещения кодов и данных нового про- цесса. Выбор раздела может осуществляться по разным правилам, например: «первый попавшийся раздел достаточного размера»; «раздел, имеющий наименьший достаточный размер» или «раз- дел, имеющий наибольший достаточный размер»; • загрузка программы в выделенный ей раздел и корректировка таблиц свободных и занятых областей. Данный способ предпола- гает, что программный код не перемещается во время выполне- ния, а значит, настройка адресов может быть проведена едино- временно во время загрузки; • после завершения процесса — корректировка таблиц свободных и занятых областей. По сравнению с методом распределения памяти фиксирован- ными разделами данный метод обладает гораздо большей гибкостью, но ему присущ очень серьезный недостаток — фрагментация памяти. Фрагментация — это наличие большого числа несмежных участков свободной памяти очень маленького размера (фрагментов). На- столько маленького, что ни одна из вновь поступающих программ не может поместиться ни в одном из участков, хотя суммарный
объем фрагментов может составить значительную величину, намного превышающую требуемый объем памяти. 5.3.3. Перемещаемые разделы Одним из методов борьбы с фрагментацией является перемеще- ние всех занятых участков в сторону старших или младших адресов так, чтобы вся свободная память образовала единую свободную об- ласть (рис. 5.10). В дополнение к функциям, которые выполняет ОС при распределении памяти динамическими разделами, в данном случае она должна еще время от времени копировать содержимое разделов из одного места памяти в другое, корректируя таблицы сво- бодных и занятых областей. Эта процедура называется сжатием. Сжатие может выполняться либо при каждом завершении процесса, либо только тогда, когда для вновь создаваемого процесса нет сво- бодного раздела достаточного размера. В первом случае требуется меньше вычислительной работы при корректировке таблиц свобод- ных и занятых областей, а во втором — реже выполняется процедура сжатия. Так как программы перемещаются по оперативной памяти в ходе своего выполнения, то в данном случае невозможно выполнить на- стройку адресов с помощью перемещающего загрузчика. Здесь более подходящим оказывается динамическое преобразование адресов. Рис. 5.10. Распределение памяти перемещаемыми разделами
Хотя процедура сжатия и приводит к более эффективному ис- пользованию памяти, она может потребовать значительного вре- мени, что часто перевешивает преимущества данного метода, 5-4. Свопинг и виртуальная память Необходимым условием для того, чтобы программа могла выпол- няться, является ее нахождение в оперативной памяти. Только в этом случае процессор может извлекать команды из памяти и интерпре- тировать их, выполняя заданные действия. Объем оперативной па- мяти, который имеется в компьютере, существенно сказывается на характере протекания вычислительного процесса. Он ограничи- вает число одновременно выполняющихся программ и размеры их виртуальных адресных пространств. Большое количество задач, необходимое дитя высокой загрузки процессора, требует большого объема оперативной памяти. В усло- виях, когда дитя обеспечения приемлемого уровня мультипрограмми- рования имеющейся оперативной памяти недостаточно, был пред- ложен метод организации вычислительного процесса, при котором образы некоторых процессов целиком или частично временно вы- ружаются на диск. В мультипрограммном режиме помимо активного процесса, т.е. процесса, коды которого в настоящий момент интерпретиру- ются процессором, имеютсяприостановленнвте процессвт, находя- щиеся в ожидании завершения ввода-вывода или освобождения ресурсов, а также процессы в состоянии готовности, стоящие в оче- реди к процессору. Образвт таких неактивных процессов могут быть временно, до следующего цикла активности, выгружены на диск. Несмотря на то что коды и данные процесса отсутствуют в опера- тивной памяти, ОС «знает» о его существовании и в полной мере учитывает это при распределении процессорного времени и других системHBix ресурсов. К моменту, когда подходит очередь выполне- ния выгруженного процесса, его образ возвращается с диска в опе- ративную память. Если при этом обнаруживается, что свободного места в оперативной памяти не хватает, то на диск выгружается другой процесс. Такая подмена (виртуализация) оперативной памяти дисковой памятью позволяет повысить уровень мультипрограммирования — объем оперативной памяти компьютера теперь не столь жестко огра- ничивает количество одновременно выполняемых процессов, по- скольку суммарный обьем памяти, занимаемой образами этих про
цсссов, может существенно превосходить имеющийся объем оперативной памяти. 5.4.1. Сегментное распределение памяти Для сегментного метода программу необходимо разбивать на части и уже каждой такой части выделять область физической памяти. Естественным способом разбиения программы на части яв- ляется разбиение ее на логические элементы — так называемые сег- менты. В принципе каждый программный модуль может быть пред- ставлен как отдельный сегмент, и вся программа тогда будет пред- ставлять собой совокупность множества сегментов. Каждый сегмент размещается в памяти как до определенной степени самостоятельная единица. Логически обращение к элементам протраммы в этом слу- чае будет представляться как указание имени сегмента и смещения относительно начала этого сегмента. Физически имя (или порядко- вый номер) сегмента будет соответствовать некоторому адресу, с ко- торого этот сегмент начинается при его размещении в памяти, и сме- щение должно прибавляться к этому базовому адресу. Преобразование имени сегмента в его порядковый номер осуще- ствит система программирования, а операционная система будет размещать сегменты в памяти на основе полученной информации. Таким образом, виртуальный адрес для этого способа будет состоять из двух полей — номера сегмента и смещения относительно начала сегмента. Соответствующая иллюстрация приведена на рис. 5.11. На этом рисунке изображен случай обращения к ячейке, виртуаль- Регистр таблицы Рис. 5.11. Сегментное распределение памяти
ный адрес которой равен сегменту с номером 11 и смешением от на- чала этого сегмента, равным 612. Как мы видим, операционная сис- тема разместила данный сегмент в памяти, начиная с ячейки с номе- ром 19700. Каждый сегмент, размещаемый в памяти, имеет соответствующую информационную структуру, часто называемую дескриптором сег- мента. Именно операционная система строит для каждого исполня- емого процесса соответствующую таблицу дескрипторов сегментов и при размещении каждого из сегментов в оперативной или внешней памяти в дескрипторе отмечает его текущее местоположение. Если сегмент задачи в данный момент находится в оперативной памяти, то об этом делается пометка в дескрипторе. Как правило, для этого используется «бит присутствия» (present). В этом случае в поле «Адрес» диспетчер памяти записывает адрес физической памяти, с которого сегмент начинается, а в поле «Длина сегмента» (limit) ука- зывается количество адресуемых ячеек памяти. Это поле использу- ется нс только для того, чтобы размещать сегменты без наложения один на другой, но и для того, чтобы проконтролировать, нс обра- щается ли код исполняющейся задачи за пределы текущего сегмента. В случае превышения длины сегмента вследствие ошибок прог- раммирования мы можем говорить о нарушении адресации и с по- мощью введения специальных аппаратных средств генерировать сигналы прерывания, которые позволят фиксировать (обнаруживать) такого рода ошибки. Если бит present в дескрипторе указывает, что сейчас этот сегмент находится не в оперативной, а вс внешней памяти (например, на винчестере), то названные поля адреса и длины используются для указания адреса сегмента в координатах внешней памяти. Помимо информации о местоположении сегмента, в дескрипторе сегмента, как правило, содержатся данные о его типе (сегмент кода или сег- мент данных), правах доступа к этому сегменту (можно или нельзя его модифицировать, предоставлять другой задаче), отметка об об- ращениях к данному сегменту (информация о том, как часто или как давно/недавно этот сегмент используется или не используется, на основании которой можно принять решение о том, чтобы предо- ставить место, занимаемое текущим сегментом, другому сегменту7). При передаче управления следующей задаче ОС должна занести в соответствующий регистр адрес таблицы дескрипторов сегментов этой задачи. Сама таблица дескрипторов сегментов, в свою очередь, также представляет собой сегмент данных, который обрабатывается диспетчером памяти операционной системы.
При таком подходе появляется возможность размещать в опера- тивной памяти не все сегменты задачи, а только те, с которыми в на- стоящий момент происходит работа. С одной стороны, становится возможным, чтобы общий объем виртуального адресного простран- ства задачи превосходил объем физической памяти компьютера, на котором эта задача будет выполняться. С другой стороны, даже если потребности в памяти не превосходят имеющуюся физическую память, появляется возможность размещать в памяти как можно больше задач. А увеличение коэффициента мультипрограммирова- ния позволяет увеличить загрузку системы и более эффективно ис- пользовать ресурсы компьютера. Очевидно, однако, что увеличивать количество задач можно только до определенного предела, ибо если в памяти не будет хватать места для часто используемых сегментов, то производительность системы резко упадет. Ведь сегмент, который сейчас находится вне оперативной памяти, для участия в вычисле- ниях должен быть перемещен в оперативную память. При этом если в памяти есть свободное пространство, то необходимо всего лишь найти его во внешней памяти и загрузить в оперативную память. А если свободного места сейчас нет, то необходимо будет принять решение, на место какого из ныне присутствующих сегментов будет загружаться требуемый. Итак, если требуемого сегмента в оперативной памяти нет, то воз- никает прерывание и управление передается через диспетчер памяти программе загрузки сегмента. Пока происходит поиск сегмента во внешней памяти и загрузка его в оперативную память, диспетчер памяти определяет подходящее для сегмента место, Возможно, что свободного места нет, и тогда принимается решение о выгрузке ка- кого-нибудь сегмента и его перемещении во внешнюю память. Если при этом еще остается время, то процессор передастся другой гото- вой к выполнению задаче. После загрузки необходимого сегмента процессор вновь передается задаче, вызвавшей прерывание из-за отсутствия сегмента. Всякий раз при считывании сегмента в опера- тивную память в таблице дескрипторов сегментов необходимо уста- новить адрес начала сегмента и признак присутствия сегмента. При поиске свободного места используется одна из вышеперечи- сленных дисциплин работы диспетчера памяти (применяются пра- вила «первого подходящего» и «самого неподходящего» фрагментов). Если свободного фрагмента памяти достаточного объема сейчас нет, но, тем нс менее, сумма этих свободных фрагментов превышает тре- бования по памяти для нового сегмента, то в принципе может быть применено «уплотнение памяти».
В идеальном случае размер сегмента должен быть достаточно ма- лым, чтобы его можно было разместить в случайно освобожда- ющихся фрагментах оперативной памяти, но достаточно большим, чтобы содержать логически законченную часть программы, с тем чтобы минимизировать межсегментные обращения. Для решения проблемы замещения (определения того сегмента, который должен быть либо перемещен во внешнюю память, либо просто замещен новым) используются следующие дисциплины: • правило FIFO (first in — first out, что означает «первый пришед- ший первым и выбывает»); • правило LRU (least recently used, что означает «последний из не- давно использованных» или, иначе говоря, «дольше всего неис- пользуемый»); • правило LFU (least frequently used, что означает «используемый реже всех остальных»); • случайный (random) выбор сегмента. Первая и последняя дисциплины являются самыми простыми в реализации, но они нс учитывают, насколько часто используется тот или иной сегмент, и следовательно, диспетчер памяти может вы- грузить или расформировать тот сегмент, к которому в самом бли- жайшем будущем будет обращение. Вероятность ошибки при опре- делении сегмента, к которому будет в ближайшее время выполнено обращение, для этих дисциплин многократно выше, чем у второй и третьей дисциплин, которые учитывают информацию об исполь- зовании сегментов. Алгоритм FI FO ассоциирует с каждым сегментом время, когда он был помещен в память. Для замещения выбирается наиболее старый сегмент. Учет времени необязателен, когда все сегменты в памяти связаны в FIFO-очередь и каждый помещаемый в память сегмент добавляется в хвост этой очереди. Алгоритм учитывает только время нахождения сегмента в памяти, но не учитывает фактическое ис- пользование сегментов. Например, первые загруженные сегменты программы могут содержать переменные, используемые на протяже- нии работы всей программы. Это приводит к немедленному возвра- щению к только что замещенному сегменту. Для реализации дисциплин LRU и LFU необходимо, чтобы про- цессор имел дополнительные аппаратные средства. Минимальные требования — достаточно, чтобы при обращении к дескриптору сег- мента для получения физического адреса, с которого сегмент начи- нает располагаться в памяти, соответствующий бит обращения менял свое значение (скажем, с нулевого, которое установила ОС, в еди-
ничное). Тогда диспетчер памяти может время от времени просмат- ривать таблицы дескрипторов исполняющихся задач и собирать для соответствующей обработки статистическую информацию об обра- щениях к сегментам. В результате можно составить список, упоря- доченный либо по длительности неиспользования (для дисциплины LRU), либо по частоте использования (для дисциплины LFU). Важнейшей проблемой, которая возникает при организации мультипрограммного режима, является защита памяти. Для того чтобы выполняющиеся приложения не смогли испортить саму ОС и другие вычислительные процессы, необходимо, чтобы доступ к таблицам сегментов с целью их модификации был обеспечен только для кода самой ОС. Для этого код ОС должен выполняться в некотором привилегированном режиме, из которого можно осу- ществлять манипуляции с дескрипторами сегментов, тогда как выход за пределы сегмента в обычной прикладной программе должен вы- зывать прерывание по защите памяти. Каждая прикладная задача должна иметь возможность обращаться только к своим собственным сегментам. При использовании сегментного способа организации виртуаль- ной памяти появляется несколько интересных возможностей. Во- первых, появляется возможность при загрузке программы на испол- нение размещать ее в памяти не целиком, а «по мере необходи- мости». Действительно, поскольку в подавляющем большинстве случаев алгоритм, по которому работает код программы, является разветвленным, а не линейным, то в зависимости от исходных дан- ных некоторые части программы, расположенные в самостоятельных сегментах, могут быть и не задействованы; значит, их можно и не за- гружать в оперативную память. Во-вторых, некоторые программные модули могут быть разделя- емыми. Эти программные модули являются сегментами, и в этом случае относительно легко организовать доступ к таким сегментам. Сегмент с разделяемым кодом располагается в памяти в един- ственном экземпляре, а в нескольких таблицах дескрипторов сегмен- тов исполняющихся задач будут находиться указатели на такие раз- деляемые сегменты. Однако у сегментного способа распределения памяти есть и не- достатки. Прежде всего из рис. 5.11 видно, что для получения доступа к искомой ячейке памяти необходимо потратить намного больше времени. Мы должны сначала найти и прочитать дескриптор сег- мента, а уже потом, используя данные из него о местонахождении нужного нам сегмента, можем вычислить и конечный физический
адрес. Для того чтобы уменьшить эти потери, используется кэширо- вание, т.е. те дескрипторы, с которыми мы имеем дело в данный мо- мент, могут быть размешены в сверхоперативной памяти (специаль- ных регистрах, размещаемых в процессоре). Несмотря на то что этот способ распределения памяти приводит к существенно меньшей фрагментации памяти, нежели способы с неразрывным распределением, фрагментация остается Кроме этого, мы имеем большие потери памяти и процессорного времени на размещение и обработку дескрипторных таблиц. Ведь на каждую задачу необходимо иметь свою таблицу дескрипторов сегментов, а при определении физических адресов необходимо выполнять опе- рации сложения. Примером использования сегментного способа организации вир- туальной памяти является операционная система OS/2 первого по- коления, которая была создана для процессора i80286 В этой ОС в полной мере использованы аппаратные средства микропроцессора, который специально проектировался для поддержки сегментного способа распределения памяти. 5 4.2. Страничное распределение памяти При страничном распределении все фрагменты программы, на которые она разбивается (за исключением последней ее части), получаются одинаковыми. Одинаковыми полагаются и единицы па- мяти, которые предоставляются для размещения фрагментов прог- раммы. Эти одинаковые части называют страницами и говорят, что память разбивается на физические страницы, а программа — на вир- туальные страницы. Часть виртуальных страниц задачи размещается в оперативной памяти, а часть — во внешней. Обычно место во внешней памяти, в качестве которой в абсолютном большинстве случаев выступают накопители на магнитных дисках (поскольку они относятся к быстродействующим устройствам с прямым доступом), называют файлом подкачки или страничным файлом (paging file). Иногда этот файл называют swap-файлом, тем самым подчеркивая, что записи этого файла — страницы — замещают друг друга в опера- тивной памяти. В некоторых ОС выгруженные страницы располага- ются не в файле, а в специальном разделе дискового пространства. В UNIX-системах для этих целей выделяется специальный раздел, но кроме него могут быть использованы и файлы, выполняющие те же функции, если объема раздела недостаточно. Разбиение всей оперативной памяти на страницы одинаковой величины, причем величина каждой страницы выбирается кратной
степени двойки, приводит к тому, что вместо одномерного адресного пространства памяти можно говорить о двумерном. Первая коорди- ната адресного пространства — это номер страницы, а вторая коор- дината — номер ячейки внутри выбранной страницы (его называют индексом). Таким образом, физический адрес определяется парой (Рр, I), а виртуальный адрес — парой (Pv, i), где Pv — это номер вир- туальной страницы; Рр — это номер физической страницы и i — это индекс ячейки внутри страницы. Количестве битов, отводимое под индекс, определяет размер страницы, а количество битов, отводимое под номер виртуальной страницы, — объем возможной виртуальной памяти, которой может пользоваться программа. Отображение, осу- ществляемое системой вс время исполнения, сводится к отображе- нию Pv в Рр и приписывании к полученному значению битов адреса, задаваемых величиной /. При этом нет необходимости ограничивать число виртуальных страниц числом физических, те. непомсстивши- еся страницы можно размещать во внешней памяти, которая в дан- ном случае служит расширением оперативной. Для отображения виртуального адресного пространства задачи на физическую память, как и в случае с сегментным способом орга- низации, для каждой задачи необходимо иметь таблицу страниц для трансляции адресных пространств. Для описания каждой страницы диспетчер памяти ОС заводит соответствующий дескриптор, кото- рый отличается от дескриптора сегмента прежде всего тем, что в нем нет необходимости иметь поле длины, — ведь все страницы имеют одинаковый размер. По номеру виртуальной страницы в таблице дескрипторов страниц текущей задачи находится соответствующий элемент (дескриптор). Если бит присутствия имеет единичное зна- чение, значит, данная страница сейчас размещена в оперативной, а нс во внешней памяти и мы в дескрипторе имеем номер физиче- ской страницы, отведенной под данную виртуальную. Если же бит присутствия равен нулю, то в дескрипторе мы будем иметь адрес виртуальной страницы, расположенной сейчас во внешней памяти. Таким образом и осуществляется трансляция виртуального адресного пространства на физическую память. Этот механизм трансляции проиллюстрирован на рис. 5.12. Защита страничной памяти, как и в случае с сегментным меха- низмом, основана на контроле уровня доступа к каждой странице. Как правило, возможны следующие уровни доступа: только чтение; чтение и запись; только выполнение. В этом случае каждая страница снабжается соответствующим кодом уровня доступа. При трансфор- мации логического адреса в физический сравнивается значение кода
Рис. 5.12. Страничный способ организации памяти разрешенного уровня доступа с фактически требуемым. При их не- совпадении работа программы прерывается. При обращении к виртуальной странице, не оказавшейся в дан- ный момент в оперативной памяти, возникает прерывание и управ ление передается диспетчеру памяти, который должен найти свобод- ное место Обычно предоставляется первая же свободная страница. Если свободной физической страницы нет, то диспетчер памяти по одной из вышеупомянутых дисциплин замещения (LRU, LFU, FIFO, random) определит страницу, подлежащую расформированию или сохранению во внешней памяти. На ее место он разместит ту но вую виртуальную страницу, к которой было обращение из задачи, но ее не оказалось в оперативной памяти. Напомним, что алгоритм выбирает для замещения ту страницу, на которую не было ссылки на протяжении наиболее длинного пе- риода времени. Дисциплина LRU (least recently used) ассоциирует с каждой страницей время последнего ее использования. Для заме- щения выбирается та страница, которая дольше всех не использова- лась. Для использования дисциплин LRU и LFU в процессоре должны быть соответствующие аппаратные средства. В дескрипторе стра- ницы размещается бит обращения (подразумевается, что на рис 5.12 этот бит расположен в последнем поле), и этот бит становится еди- ничным при обращении к дескриптору. Если объем физической памяти небольшой и даже часто требу- емые страницы не удается разместить в оперативной памяти, то воз- никает так называемая пробуксовка Другими словами, пробук-
совка — это ситуация, при которой загрузка нужной нам страницы вызывает перемещение во внешнюю память той страницы, с которой мы тоже активно работаем. Очевидно, что это очень плохое явление. Чтобы его не допускать, желательно увеличить объем оперативной памяти (сейчас это стало самым простым решением), уменьшить количество параллельно выполняемых задач либо попробовать ис- пользовать более эффективные дисциплины замещения. В абсолютном большинстве современных ОС используется дис- циплина замещения страниц LRU как самая эффективная. Так, именно эта дисциплина используется в OS/2 и Linux. Однако в такой ОС, как Windows NT, разработчики, желая сделать систему макси- мально независимой от аппаратных возможностей процессора, пошли на отказ от этой дисциплины и применили правило FIFO. А для того, чтобы хоть как-нибудь сгладить ее неэффективность, была введена «буферизация» тех страниц, которые должны быть за- писаны в файл подкачки на диск или просто расформированы. Принцип буферирования прост. Прежде чем замещаемая стра- ница действительно будет перемещена во внешнюю память или про- сто расформирована, она помечается как кандидат на выгрузку. Если в следующий раз произойдет обращение к странице, находящейся в таком «буфере», то страница никуда не выгружается и уходит в ко- нец списка FIFO. В противном случае страница действительно вы- гружается, а на ее место в «буфере» попадает следующий «кандидат». Величина такого «буфера» не может быть большой, поэтому эффек- тивность страничной реализации памяти в Windows NT намного ниже, чем у вышеназванных ОС, и явление пробуксовки начинается даже при существенно большем объеме оперативной памяти. В ряде ОС с пакетным режимом работы для борьбы с пробуксов- кой используется метод «рабочего множества». Рабочее множество — это множество «активных» страниц задачи за некоторый интервал, т.е. тех страниц, к которым было обращение за этот интервал вре- мени. Реально количество активных страниц задачи (за интервал Т) все время изменяется, и это естественно, но, тем не менее, для каждой задачи можно определить среднее количество ее активных страниц. Это среднее число активных страниц и есть рабочее мно- жество задачи. Наблюдения за исполнением множества различных программ показали, что даже если Травно времени выполнения всей работы, то размер рабочего множества часто существенно меньше, чем общее число страниц программы. Таким образом, если ОС может определить рабочие множества исполняющихся задач, то для пред- отвращения пробуксовки достаточно планировать на выполнение
только такое количество задач, чтобы сумма их рабочих множеств не превышала возможности системы. Как и в случае с сегментным способом организации виртуальной памяти, страничный механизм приводит к тому, что без специальных аппаратных средств он будет существенно замедлять работу вычис- лительной системы. Поэтому обычно используется кэширование страничных дескрипторов. Наиболее эффективным способом кэши- рования является использование ассоциативного кэша. Именно та- кой ассоциативный кэш и создан в 32-разрядных микропроцессорах i80x86. Начиная с i80386, который поддерживает страничный способ распределения памяти, в этих микропроцессорах имеется кэш на 32 страничных дескриптора. Поскольку размер страницы в этих микропроцессорах равен 4 Кбайт, возможно быстрое обращение к 128 Кбайт памяти. Итак, основным достоинством страничного способа распределе- ния памяти является минимально возможная фрагментация. По- скольку на каждую задачу может приходиться по одной незаполнен- ной странице, то становится очевидно, что память можно использо- вать достаточно эффективно: этот метод организации виртуальной памяти был бы одним из самых лучших, если бы не два следующих обстоятельства. Первое — это то, что страничная трансляция виртуальной памяти требует существенных накладных расходов. В самом деле, таблицы страниц нужно тоже размещать в памяти. Кроме этого, эти таблицы нужно обрабатывать; именно с ними работает диспетчер памяти. Второй существенный недостаток страничной адресации заклю- чается в том, что программы разбиваются на страницы случайно, без учета логических взаимосвязей, имеющихся в коде. Это приводит к тому, что межстраничные переходы, как правило, осуществляются чаще, нежели межсегментные, и к тому, что становится трудно орга- низовать разделение программных модулей между выполняющимися процессами. Для того чтобы избежать второго недостатка, постаравшись со- хранить достоинства страничного способа распределения памяти, был предложен еще один способ — сегментно-страничный. Правда, за счет дальнейшего увеличения накладных расходов на его реали- зацию. 5.4.3. Сегментно-страничный способ организации памяти Как и в сегментном способе распределения памяти, программа разбивается на логически законченные части — сегменты и вирту-
альный адрес содержит указание на номер соответствующего сег- мента. Вторая составляющая виртуального адреса — смещение от- носительно начала сегмента, в свою очередь, может состоять из двух полей: виртуальной страницы и индекса. Другими словами, получа- ется, что виртуальный адрес теперь состоит из трех компонентов: сегмента, страницы, индекса. Получение физического адреса и из- влечение из памяти необходимого элемента для этого способа пред- ставлены на рис. 5.13. Регистр Рис. 5.13. Сегментно-страничный способ организации памяти Из рисунка сразу видно, что этот способ организации виртуаль- ной памяти вносит еще большую задержку доступа к памяти. Необ- ходимо сначала вычислить адрес дескриптора сегмента и прочитать его, затем вычислить адрес элемента таблицы страниц этого сегмента и извлечь из памяти необходимый элемент, и уже только после этого можно к номеру физической страницы приписать номер ячейки в странице (индекс). Задержка доступа к искомой ячейке получается по крайней мере в три раза больше, чем при простой прямой адреса- ции. Чтобы избежать этой неприятности, вводится кэширование, причем кэш, как правило, строится по ассоциативному принципу.
Другими словами, просмотры двух таблиц в памяти могут быть за- менены одним обращением к ассоциативной памяти. Напомним, что принцип действия ассоциативного запомина- ющего устройства предполагает, что каждой ячейке памяти такого устройства ставится в соответствие ячейка, в которой записывается некий ключ (признак, адрес), позволяющий однозначно иденти- фицировать содержимое ячейки памяти. Сопутствующую ячейку с информацией, позволяющей идентифицировать основные дан- ные, обычно называют полем тега Просмотр полей тега всех ячеек ассоциативного устройства памяти осуществляется одновременно, т.е. в каждой ячейке тега есть необходимая логика, позволяющая посредством побитовой конъюнкции найти данные по их признаку за одно обращение к памяти (если они там, конечно, присут- ствуют). Часто поле тегов называют аргументом, а поле с дан- ными — функцией. В качестве аргумента при доступе к ассоциа- тивной памяти выступают номер сегмента и номер виртуальной страницы, а в качестве функции от этих аргументов получаем номер физической страницы. Остается приписать номер ячейки в стра- нице к полученному номеру — и мы получаем искомую команду или операнд. Оценим достоинства сегментно-страничного способа. Разбиение программы на сегменты позволяет размещать сегменты в памяти пе- диком. Сегменты разбиты на страницы, все страницы сегмента за- гружаются в память. Это позволяет уменьшить обращения к отсут- ствующим страницам, поскольку вероятность выхода за пределы сегмента меньше вероятности выхода за пределы страницы. Стра- ницы исполняемого сегмента находятся в памяти, но при этом они могут находиться не рядом друг с другом, а «россыпью», поскольку диспетчер памяти манипулирует страницами. Наличие сегментов облегчает реализацию разделения программных модулей между па- раллельными процессами. Возможна и динамическая компоновка задачи. А выделение памяти страницами позволяет минимизировать фрагментацию. Однако, поскольку этот способ распределения памяти требует очень значительных затрат вычислительных ресурсов и его не так просто реализовать, используется он редко, причем в дорогих, мощ- ных вычислительных системах. Возможность реализовать сегментно- страничное распределение памяти заложена и в семейство микро- процессоров 180x86, однако вследствие слабой аппаратной под- держки, трудностей при создании систем программирования и операционной системы практически он не используется в ПК.
5.5. Разделяемые сегменты памяти Подсистема виртуальной памяти представляет собой удобный механизм для решения задачи совместного доступа нескольких про- цессов к одному и тому же сегменту памяти, который в этом случае называется разделяемой памятью (shared memory). Хотя основной задачей операционной системы при управлении памятью является защита областей оперативной памяти, принадле- жащей одному из процессов, от доступа к ней остальных процессов, в некоторых случаях оказывается полезным организовать контроли- руемый совместный доступ нескольких процессов к определенной области памяти. Например, в том случае, когда несколько пользова- телей одновременно работают с некоторым текстовым редактором, нецелесообразно многократно загружать его код в оперативную па- мять. Гораздо экономичней загрузить всего одну копию кода, которая обслуживала бы всех пользователей, работающих в данное время с этим редактором (для этого код редактора должен быть реентера- бельным). Очевидно, что сегмент данных редактора не может при- сутствовать в памяти в единственном разделяемом экземпляре; для каждого пользователя должна быть создана своя копия этого сег- мента, в которой помещается редактируемый текст и значения дру- гих переменных редактора, например его конфигурация, индивиду- альная для каждого пользователя, и т.п. Другим примером применения разделяемой области памяти мо- жет быть использование ее в качестве буфера при межпроцессном обмене данными В этом случае один процесс пишет в разделяемую область, а другой — читает. Для организации разделяемого сегмента при наличии подсистемы виртуальной памяти достаточно поместить его в виртуальное адресное пространство каждого процесса, которому нужен доступ к данному сегменту, а затем настроить параметры отображения этих виртуальных сегментов так, чтобы они соответствовали одной и той же области опе- ративной памяти. Детади такой настройки зависят от типа использу- емой в ОС модели виртуальной памяти: сегментной или сегментно- страничной (чисто страничная организация не поддерживает понятие «сегмент», что делает невозможным решение рассматриваемой за- дачи) . Например, при сегментной организации необходимо в дескрип- торах виртуального сегмента каждого процесса указать один и тот же базовый физический адрес. При сегментно-страничной организации отображение на одну и ту же область памяти достигается за счет соот- ветствующей настройки таблицы страниц каждого процесса.
В приведенном выше описании подразумевалось, что разделя- емый сегмент помещается в индивидуальную часть виртуального адресного пространства каждого процесса (рис. 5 14, а) и описыва- ется в каждом процессе индивидуальным дескриптором сегмента (и индивидуальными дескрипторами страниц, если используется сегментно-страничный механизм). «Попадание» же этих виртуаль- ных сегментов на общую часть оперативной памяти достигается за счет согласованной настройки операционной системой многочис- ленных дескрипторов для множества процессов. Рис. 5.14. Способы создания разделяемого сегмента памяти: ВП N — виртуальное адресное пространство процесса N\ ОП — оперативная (физическая) память Возможно и более экономичное для ОС решение этой задачи — по- мещение единственного разделяемого виртуального сегмента в общую часть виртуального адресного пространства процессов, т.е. в ту часть, которая обычно используется дитя модулей ОС (рис. 5.14, б). В этом случае настройка дескриптора сегмента (и дескрипторов страниц) выполняется только один раз, а все процессы пользуются такой на- стройкой и совместно используют часть оперативной памяти. При работе с разделяемыми сегментами памяти ОС должна вы- полнять некоторые функции, общие для любых разделяемых между процессами ресурсов — файлов, семафоров и т.п. Эти функции со- стоят в поддержке схемы именования ресурсов, проверке прав до- ступа определенного процесса к ресурсу, а также в отслеживании
количества процессов, пользующихся данным ресурсом (чтобы уда- лить его в случае ненадобности). Для того чтобы отличать разделя- емые сегменты памяти от индивидуальных, дескриптор сегмента должен содержать поле, имеющее два значения: shared (разделяемый) или private (индивидуальный). Операционная система может создавать разделяемые сегменты как по явному запросу, так и по умолчанию. В первом случае при- кладной процесс должен выполнить соответствующий системный вызов, по которому операционная система создает новый сегмент в соответствии с указанными в вызове параметрами: размером сег- мента; разрешенными над ним операциями (чтение/запись) и иден- тификатором. Все процессы, выполнившие подобные вызовы с од- ним и тем же идентификатором, получают доступ к этому сегменту и используют его по своему усмотрению, например в качестве буфера для обмена данными. Во втором случае операционная система сама в определенных ситуациях принимает решение о том, что нужно создать разделяемый сегмент. Наиболее типичным примером такого рода является поступ- ление нескольких запросов на выполнение одного и того же прило- жения. Если кодовый сегмент приложения помечен в исполняемом файле как реентерабельный и разделяемый, то ОС не создаст при поступлении нового запроса новую индивидуальную для процесса копию кодового сегмента этого приложения, а отображает уже су- ществующий разделяемый сегмент в виртуальное адресное простран- ство процесса. При закрытии приложения каким-либо процессом ОС проверяет, существуют ли другие процессы, пользующиеся дан- ным приложением, и если их нет, то удаляет данный разделяемый сегмент. Разделяемые сегменты выгружаются на диск системой виртуаль- ной памяти по тем же алгоритмам и с помощью тех же механизмов, что и индивидуальные. 5.6. Кэширование данных 5.6.1. Иерархия запоминающих устройств Память вычислительной машины представляет собой иерархию запоминающих устройств (ЗУ), отличающихся средним временем доступа к данным, объемом и стоимостью хранения одного бита (рис. 5.15). Фундаментом этой пирамиды запоминающих устройств служит внешняя память, как правило представляемая жестким
Объем Десятки байт Регистры процессора -2-3 нс Время доступа Десятки — сотни килобайт Быстродействующая память (на основе SRAM) -5-8 нс Десятки мегабайт Оперативная памято (на основе DRAM) -10-2СНС Десятки гигабайт Внешняя память Деся । ки мс Стоимость хранения I бига Рис. 5.15. Иерархия запоминающих устройств диском. Она имеет большой объем (десятки и сотни гигабайт), но скорость доступа к данным является невысокой. Время доступа к диску измеряется миллисекундами. На следующем уровне располагается более быстродействующая (время доступа равно примерно 10—20 нс) и менее объемная (от де- сятков мегабайт до нескольких гигабайт) оперативная память, ре- ализуемая на относительно медленной динамической памяти DRAM. Для хранения данных, к которым необходимо обеспечить быстрый доступ, используются компактные быстродействующие запомина- ющие устройства на основе статической памяти SRAM, объем кото- рых составляет от нескольких десятков до нескольких сотен килобайт, а время доступа к данным обычно не превышает 8 нс. И наконец, верхушку в этой пирамиде составляют внутренние регистры процессора, которые также могут быть использованы для промежуточного хранения данных. Общий объем регистров состав- ляет несколько десятков байт, а ьремя доступа определяется быстро- действием процессора и равно в настоящее время примерно 2—3 нс. Таким образом, можно констатировать печальную закономер- ность: чем больше объем устройства, тем менее быстродействующим оно является. Более того, стоимость хранения данных в расчете на один бит также увеличивается с ростом быстродействия устройств. Однако пользователю хотелось бы иметь и недорогую, и быструю память. Кэш-память представляет некоторое компромиссное реше- ние этой проблемы.
5.6.2. Кэшпамять Кэш-память или просто кэш (cache) — это способ совместного функционирования двух типов запоминающих устройств, отлича- ющихся временем доступа и стоимостью хранения данных, который за счет динамического копирования в «быстрое» ЗУ наиболее часто используемой информации из «медленного» ЗУ позволяет, с одной стороны, уменьшить среднее время доступа к данным, а с другой стороны, экономить более дорогую быстродействующую память. Неотъемлемым свойством кэш-памяти является ее прозрачность для программ и пользователей. Система не требует никакой внешней информации об интенсивности использования данных; ни пользо- ватели, ни программы не принимают никакого участия в перемеще- нии данных из ЗУ одного типа в ЗУ другого типа, все это делается автоматически системными средствами Кэш-памятью или кэшем часто называют не только способ орга- низации работы двух типов запоминающих устройств, но и одно из устройств — «быстрое» ЗУ. Оно стоит дороже и, как правило, имеет сравнительно небольшой объем. «Медленное» ЗУ далее будем называть основной памятью, противопоставляя ее вспомогательной кэш-памяти. Кэширование — это универсальный метод, пригодный для уско- рения доступа к оперативной памяти, к диску и к другим видам за- поминающих устройств. Если кэширование применяется для умень- шения среднего времени доступа к оперативной памяти, то в каче- стве кэша используют быстродействующую статическую память. Если кэширование используется системой ввода-вывода для уско- рения доступа к данным, хранящимся на диске, то в этом случае роль кэш-памяти выполняют буферы в оперативной памяти, в которых оседают наиболее активно используемые данные. Виртуальную па- мять также можно считать одним из вариантов реализации принципа кэширования данных, при котором оперативная память выступает в роли кэша по отношению к внешней памяти — жесткому диску. Правда, в этом случае кэширование используется не для того, чтобы уменьшить время доступа к данным, а для того, чтобы заставить диск частично подменить оперативную память за счет перемещения вре- менно неиспользуемого кода и данных на диск с целью освобож- дения места для активных процессов. Е результате наиболее интен- сивно используемые данные «оседают» в оперативной памяти, остальная же информация хранится в более объемной и менее доро- гостоящей внешней памяти.
5.6.3. Принцип действия кэш памяти Рассмотрим одну из возможных схем кэширования (рис 5.16). Содержимое кэш-памяти представляет собой совокупность записей обо всех загруженных в нее элементах данных из основной памяти. Каждая запись об элементе данных включает в себя: • значение элемента данных; • адрес, который этот элемент данных имеет в основной памяти; • дополнительную информацию, которая используется для реали- зации алгоритма замещения данных в кэше и обычно включает признак модификации и признак действительности данных. Медленный ответ Структура кэш-памяти Адрес данных в основной памяти Данные Управля ош?я информация Рис. 5.16. Схема функционирования кэш-памяти При каждом обращении к основной памяти по физическому ад- ресу просматривается содержимое кэш-памяти с целью опреде- ления, не находятся ли там нужные данные. Кэш-память нс явля- ется адресуемой, поэтому поиск нужных данных осуществляется по содержимому — по взятому из запроса значению поля адреса в оперативной памяти Далее возможен один из двух вариантов раз- вития событий: • если данные обнаруживаются в кэш-памяти, т.е. произошло кэш- попадание (cache-hit), они считываются из нее и результат пере- дается источнику запроса; • если нужные данные отсутствуют в кэш-памяти. т.е. произошел кэш-промах (cache-miss), они считываются из основной памяти,
передаются источнику запроса и одновременно с этим копиру- ются в кэш-память. Вероятность обнаружения данных в кэше зависит от разных фак- торов, таких, например, как объем кэша, объем кэшируемой памяти, алгоритм замещения данных в кэше, особенности выполняемой прог- раммы, время ее работы, уровень мультипрограммирования, и других особенностей вычислительного процесса. Тем не менее в большин- стве реализаций кэш-памяти процент кэш-попаданий оказывается весьма высоким — свыше 90%. Такое высокое значение вероятности нахождения данных в кэш-памяти объясняется наличием у данных объективных свойств: пространственной и временной локальности. Временная локальность. Если произошло обращение по некото- рому адресу, то следующее обращение по тому же адресу с большой вероятностью произойдет в ближайшее время. Пространственная локальность. Если произошло обращение по некоторому адресу, то с высокой степенью вероятности в ближай- шее время произойдет обращение к соседним адресам. Именно основываясь на свойстве временной локальности, дан- ные, только что считанные из основной памяти, размещают в запо- минающем устройстве быстрого доступа, предполагая, что скоро они опять понадобятся. В начале работы системы, когда кэш-память еще пуста, почти каждый запрос к основной памяти выполняется «по полной программе»: просмотр кэша, констатация промаха, чтение данных из основной памяти, передача результата источнику запроса и копирование данных в кэш Затем, по мере заполнения кэша, в полном соответствии со свойством временной локальности возрас- тает вероятность обращения к данным, которые уже были использо- ваны на предыдущем этапе работы системы, т.е. к данным, которые содержатся в кэше и могут быть считаны значительно быстрее, чем из основной памяти. Свойство пространственной локальности также используется для увеличения вероятности кэш-попадания: как правило, в кэш-память считывается нс один информационный элемент, к которому про- изошло обращение, а целый блок данных, расположенных в основ- ной памяти в непосредственной близости с данным элементом. По- скольку при выполнении программы очень высока вероятность, что команды выбираются из памяти последовательно одна за другой из соседних ячеек, то имеет смысл загружать в кэш-память целый фрагмент программы. Аналогично если программа ведет обработку некоторого массива данных, то ее работу можно ускорить, загрузив в кэш часть или даже весь массив данных. При этом учитывается
высокая вероятность того, что значительное число обращений к па- мяти будет выполняться к адресам массива данных. 5 6 4 Проблема согласования данных В процессе работы содержимое кэш-памяти постоянно обновля- ется, а значит, время от времени данные из нее должны вытесняться. Вытеснение означает либо простое объявление свободной соответ- ствующей области кэш-памяти (сброс бита действительности), если вытесняемые данные за время нахождения в кэше не были изменены, либо в дополнение к этому копирование данных в основную память, если они были модифицированы. Алгоритм замены данных в кэш- памяти существенно влияет на ее эффективность. В идеале такой ал- горитм должен, во-первых, быть максимально быстрым, чтобы не за- медлять работу кэш-памяти, а во-вторых, обеспечивать максимально возможную вероятность кэш-попаданий. Поскольку из-за непред- сказуемости вычислительного процесса ни один алгоритм замещения данных в кэш-памяти не может гарантировать оптимальный резуль- тат, разработчики ограничиваются рациональными решениями, ко- торые, по крайней мере, не сильно замедляют работу кэша — запо- минающего устройства, изначально призванного быть быстрым. Наличие в компьютере двух копий данных: в основной памяти и в кэше — порождает проблему согласования данных. Если проис- ходит запись в основную намять по некоторому адресу, а содержимое этой ячейки находится в кэше, то в результате соответствующая за- пись в кэше становится недостоверной. Рассмотрим два подхода к решению этой проблемы: • сквозная запись (write through). При каждом запросе к основной памяти, в том числе и при записи, просматривается кэш. Если данные по запрашиваемому адресу отсутствуют, то запись выпол- няется только в основную память. Если же данные, к которым выполняется обращение, находятся в кэше, то запись выполня- ется одновременно в кэш и основную память; • обратная запись (write back). Аналогично при возникновении за- проса к памяти выполняется просмотр кэша, и если запрашива- емых данных там нет, то запись выполняется только в основную память. В противном же случае запись производится только в кэш-память, при этом в описателе данных делается специальная отметка (признак модификации), которая указывает на то, что при вытеснении этих данных из кэша необходимо переписать их в основную память, чтобы актуализировать устаревшее содержи- мое основной памяти.
В некоторых алгоритмах замещения предусматривается первооче- редная выгрузка модифицированных или, как еще говорят, «гряз- ных» данных. Модифицированные данные могут выгружаться не только при освобождении места в кэш-памяти для новых данных, но и в «фоновом режиме», когда система не очень загружена. 5.6.5. Способы отображения основной памяти на кэш Алгоритм поиска и алгоритм замещения данных в кэше непосред- ственно зависят от того, каким образом основная память отобража- ется на кэш-память. Принцип прозрачности требует, чтобы правило отображения основной памяти на кэш-память не зависело от работы программ и пользователей. При кэшировании данных из оператив- ной памяти широко используются две основные схемы отображения: случайное отображение и детерминированное отображение. При случайном отображении элемент оперативной памяти в об- щем случае может быть размещен в произвольном месте кэш-па- мяти. Для того чтобы в дальнейшем можно было найти нужные дан- ные в кэше, они помещаются туда вместе со своим адресом, т.е. тем адресом, который данные имеют в оперативной памяти. При каждом запросе к оперативной памяти выполняется поиск в кэше, причем критерием поиска выступает адрес оперативной памяти из запроса. Очевидная схема простого перебора для поиска нужных данных в случае кэша оказывается непригодной из-за недопустимо больших временных затрат. Для кэш-памяти со случайным отображением используется так называемый ассоциативный поиск, при котором сравнение выпол- няется не последовательно с каждой записью кэша, а параллельно со всеми его записями (рис. 5.17). Признак, по которому выполня- ется сравнение, называется тегом (tag). В данном случае тегом явля- ется адрес данных в оперативной памяти. Электронная реализация такой схемы приводит к удорожанию памяти, причем стоимость су- щественно возрастает с увеличением объема запоминающего устрой- ства. Поэтому ассоциативная кэш-память используется в тех случаях, когда для обеспечения высокого процента попадания достаточно небольшого объема памяти. В кэш-памяти, построенной на основе случайного отображения, вытеснение старых данных происходит только в том случае, когда вся кэш-память заполнена и нет свободного места. Выбор данных на выгрузку осуществляется среди всех записей кэша. Обычно этот выбор основывается на тех же приемах, что и в алгоритмах замеще- ния страниц, например выгрузке данных, к которым дольше всего
Параллелэкое сравнение Рис. 5.17. Ассоциативный поиск в кэше со случайным отображением не было обращений, или данных, к которым было меньше всего об- ращений Второй, детерминированный способ отображения предполагает, что любой элемент основной памяти всегда отображается в одно и то же место кэш-памяти. В этом случае кэш-память разделена на строки, каждая из которых предназначена для хранения одной записи об одном элементе данных и имеет свой номер. Между номе- рами строк кэш-памяти и адресами оперативной памяти устанавли- вается соответствие «один ко многим»: одному номеру строки соот- ветствует несколько (обычно достаточно много) адресов оператив- ной памяти. В качестве отображающей функции может использоваться простое выделение нескольких разрядов из адреса оперативной па- мяти, которые интерпретируются как номер строки кэш-памяти (та- кое отображение называется прямым). Например, пусть в кэш-па- мяти может храниться 1024 записи, т.е. кэш имеет 1024 строки, про- нумерованные от 0 до 1023. Тогда любой адрес оперативной памяти может быть отображен на адрес кэш-памяти простым отделением 10 двоичных разрядов (рис. 5.18). При поиске данных в кэше используется быстрый прямой доступ к записи по номеру строки, полученному путем обработки адреса оперативной памяти из запроса. Однако, поскольку в найденной
Адрес ОП из запроса 111001110101 1101100011 Номер элемента кэш-памяти Рис. 5.18- Прямое отображение строке могут находиться данные из любой ячейки оперативной па- мяти, младшие разряды адреса которой совпадают с номером строки, необходимо выполнить дополнительную проверку. Для этих целей каждая строка кэш-памяти дополняется тегом, содержащим старшую часть адреса данных в оперативной памяти. При совпадении тега с соответствующей частью адреса из запроса констатируется кэш- попадание. Если же произошел кэш-промах, то данные считываются из опе- ративной памяти и копируются в кэш. Если строка кэш-памяти, в которую должен быть скопирован элемент данных из оперативной памяти, содержит другие данные, то последние вытесняются из кэша. Заметим, что процесс замещения данных в кэш-памяти на основе прямого отображения существенно отличается от процесса замещения данных в кэш-памяти со случайным отображением. Во- первых, вытеснение данных происходит не только в случае отсут- ствия свободного места в кэше; во вторых, никакого выбора данных на замещение не существует.
Во многих современных процессорах кэш-память строится на ос- нове сочетания этих двух подходов, что позволяет найти компромисс между сравнительно низкой стоимостью кэша с прямым отображе- нием и интеллектуальностью алгоритмов замещения в кэше со слу- чайным отображением. При смешанном подходе произвольный адрес оперативной памяти отображается не на один адрес кэш-па- мяти (как это характерно для прямого отображения) и не на любой адрес кэш-памяти (как это делается при случайном отображении), а на некоторую группу адресов. Все группы пронумерованы. Поиск в кэше осуществляется вначале по номеру группы, полученному из адреса оперативной памяти из запроса, а затем в пределах группы путем ассоциативного просмотра всех записей в группе на предмет совпадения старших частей адресов оперативной памяти (рис. 5.19). Адреса запроса 10101111 I 0010 - 1 Номер группы тег Кэш-память Память тегов Искомые данные грут.та 1-я группа 2-я группа (ОСО) n-я группа О я Рис. 5.19. Комбинирование прямого и случайного отображения
При промахе данные копируются по любому свободному адресу из однозначно заданной группы. Если свободных адресов в группе нет, то выполняется вытеснение данных. Поскольку кандидатов на выгрузку несколько — все записи из данной группы, алгоритм замещения может учесть интенсивность обращений к данным и тем самым повысить вероятность попаданий в будущем. Таким образом, в данном способе комбинируется прямое отображение на группу и случайное отображение в пределах группы. Выводы Оперативная память является важнейшим ресурсом вычисли- тельной системы, требующим тщательного управления со стороны мультипрограммной операционной системы. Особая роль памяти объясняется тем, что процессор может выполнять инструкции прог- раммы только в том случае, если они находятся в памяти. Память распределяется как между модулями прикладных прог- рамм, так и между модулями самой операционной системы. Функциями ОС по управлению памятью в мультипрограммной системе являются: • отслеживание наличия свободной и занятой памяти; • выделение памяти процессам и освобождение памяти при завер- шении процессов; • вытеснение кодов и данных процессов из оперативной памяти на диск (полное или частичное), когда размеры основной па- мяти недостаточны для размещения в ней всех процессов, и воз- вращение их в оперативную память, когда в ней освобождается место; • настройка адресов программы на конкретную область физиче ской памяти; • защита памяти процессов от взаимного вмешательства. На разных этапах жизненного цикла программы для представле- ния переменных и кодов требуются три типа адресов: символьные (имена, используемые программистом), виртуальные (условные числа, вырабатываемые компилятором) и физические (адреса фак- тического размещения в оперативной памяти). Совокупность виртуальных адресов процесса называется вирту- альным адресным пространством. Диапазон возможных адресов вир- туального пространства у всех процессов является одним и тем же. Виртуальное адресное пространство может быть плоским (линей- ным) или структурированным.
Необходимо различать максимально возможное виртуальное адресное пространство процесса, которое определяется только раз- рядностью виртуального адреса и архитектурой компьютера, и на- значенное (выделенное) процессу виртуальное адресное простран- ство, состоящее из набора виртуальных адресов, действительно нуж- ных процессу для работы. Виртуальное адресное пространство процесса делится на две не- прерывные части: системную и пользовательскую. Системная часть является общей для всех процессов, в ней размещаются коды и дан- ные операционной системы. Наиболее эффективным способом управления памятью является виртуальная память, вытеснившая в современных ОС методы рас- пределения памяти фиксированными, динамическими или переме- щаемыми разделами. Виртуальная память использует дисковую память для временного хранения не помещающихся в оперативнучо память данных и кодов выполняемых процессов ОС. В настоящее время все множество реализаций виртуальной па- мяти может быть представлено тремя классами: • страничная виртуальная память организует перемещение данных между памятью и диском страницами — частями виртуального адресного пространства фиксированного и сравнительно неболь- шого размера (достоинства — высокая скорость обмена, низкий уровень фрагментации; недостатки — сложно организовать за- щиту данных, разделенных на части механически); • сегментная виртуальная память предусматривает перемещение данных сегментами — частями виртуального адресного простран- ства произвольного размера, полученными с учетом смыслового значения данных (достоинства — «осмысленность» сегментов упрощает их защиту; недостатки — медленное преобразование адреса, высокий уровень фрагментации); • сегментно-страничная виртуальная память сочетает достоинства обоих предыдущих подходов. Сегменты виртуальной памяти могут быть разделяемыми между несколькими процессами. Разделяемые сегменты используются либо для экономии физической памяти, когда несколько пользователей работают с одним кодовым сегментом приложения, либо в качестве средства обмена данными между процессами. Для ускорения доступа к данным в вычислительных системах ши- роко используется принцип кэширования. В компьютерах суще- ствует иерархия запоминающих устройств, в которой нижний уро-
вснь занимает емкая, но относительно медленная дисковая память, затем располагается оперативная память, а верхний уровень состав- ляет сверхоперативная память процессорного кэша. Каждый уровень памяти (кроме нижнего) выполняет роль кэша по отношению к ни- жележащему. Каждая запись в кэш-памяти об элементе данных включает в себя: • значение элемента данных; • адрес, который этот элемент данных имеет в основной памяти; • дополнительную информацию, которая используется для реали- зации алгоритма замещения данных в кэше и обычно включает признак модификации и признак действительности данных. При кэшировании данных из оперативной памяти широко ис- пользуются две основные схемы отображения: случайное отображе- ние и детерминированное отображение. При случайном отображении элемент оперативной памяти может быть размещен в произвольном месте кэш-памяти. Для того чтобы в дальнейшем можно было найти нужные данные в кэше, они поме- щаются туда вместе со своим адресом оперативной памяти. Детерминированный (прямой) способ отображения предполагает, что любой элемент основной памяти всегда отображается в одно и то же место кэш-памяти В этом случае кэш-память разделена на строки, каждая из которых предназначена для хранения одной записи об одном элементе данных и имеет свой номер. Во многих современных процессорах кэш-память строится на ос- нове сочетания этих двух подходов, что позволяет найти компромисс между сравнительно низкой стоимостью кэша с прямым отображе- нием и интеллектуальностью алгоритмов замещения в кэше со слу- чайным отображением. Вопросы для самоконтроля 1. Чем ограничивается максимальный размер физической памяти, кото- рую можно установить в компьютере определенной модели? 2. Чем ограничивается максимальный размер виртуального адресного пространства, доступного приложению? 3. Может ли прикладной процесс использовать системную часть вирту- альной памяти? 4. В каких случаях транслятор создает объект] тый код программы не в вир- туальных, а в физических адресах? 5. Распределение памяти перемещаемыми разделами основано на приме- нении процедуры сжатия. Имеет ли смысл использовать данную про- цедуру при страничном распределении? А при сегментном?
6. Поясните разные значения термина «свопинг». 7. Как величина файла подкачки влияет на производительность системы? 8. Почему размер страницы выбирается равным степени двойки? Можно ли принять такое же ограничение для сегмента? 9. На что влияет размер страницы? Каковы преимущества и недостатки большого размера страницы? 10. Пусть в некоторой программе, работающей в системе со страничной организацией памяти, произошло обращение по виртуальному адресу 0123568. Преобразуйте этот адрес в физический, учитывая, что размер страницы равен 2 4 байт и что таблица страниц данного процесса со- держит следующий фрагмент: Номер виртуальной страницы Номер физической страницы 0000 0101 0001 0010 0010 ООН ООН 0000 11. Где хранятся таблицы страниц и таблицы сегментов? 12. Чем определяется количество таблиц сегментов, имеющихся в опера- ционной системе в произвольный момент времени? 13. Какие характеристики содержит таблица сегментов и таблица страниц при сегментно страничной организации памяти? 14. Пусть ОС реализует выгрузку страниц на основе критерия «выгружается страница, которая не использовалась дольше остальных». Предложите алгоритм вычисления данного критерия, использующий аппаратно устанавливаемые биты доступа. 15. В кэше хранятся данные, которые наиболее активно используются в по- следнее время. Каким образом система определяет, какие данные должны быть загружены в кэш? 16. Почему загрузка и выгрузка данных из кэш-памяти производятся бло- ками?
Глава 6 ввод-вывод И ФАЙЛОВАЯ СИСТЕМА Необходимость обеспечить программам возможность осуще- ствлять обмен данными с внешними устройствами и при этом не включать в каждую программу соответствующий код, осуще- ствляющий собственно управление устройствами ввода-вывода, привела разработчиков к созданию системно! о программного обес- печения и, в частности, самих операционных систем. Программи- рование задач управления вводом-выводом является наиболее слож- ным и трудоемким, требующим очень высокой квалификации. По- этому код, позволяющий осуществлять операции ввода-вывода, стали оформлять в виде системных библиотечных процедур; потом его стали включать не в системы программирования, а в операци- онную систему, с тем чтобы в каждую отдельно взятую программу его не вставлять, а только позволить обращаться к такому коду. Сис- темы программирования стали генерировать обращения к этому системному коду ввода-вывода и осуществлять только подготовку к собственно операциям ввода-вывода, т.е. автоматизировать пре- образование данных к соответствующему формату, понятному устройствам, избавляя прикладных программистов от этой сложной и трудоемкой работы. Другими словами, системы программиро- вания вставляют в машинный код необходимые библиотечные под- программы ввода-вывода и обращения к тем системным прог- раммным модулям, которые, собственно, и управляют операциями обмена между оперативной памятью и внешними устройствами. Таким образом, управление вводом-выводом — это одна из ос- новных функций любой ОС. Файловая система ввиду ее сложности, специфичности и важ- ности как основного хранилища всей информации вычислительной системы заслуживает отдельного рассмотрения, но, тем не менее, здесь файловая система рассматривается совместно с другими ком- понентами подсистемы ввода-вывода по следующим причинам. Во- первых, файловая система активно использует остальные части под- системы ввода-вывода, а во-вторых, модель файла лежит в основе
большинства механизмов доступа к устройствам, используемых в со- временной подсистеме ввода-вывода. 6.1. Функции операционной системы по управлении) файлами и устройствами Подсистема ввода вывода (Input Output Subsystem) мультипро граммной ОС при обмене данными с внешними устройствами ком- пьютера должна выполнять следующие основные функции: • организация параллельной работы устройств ввода-вывода и про- цессора; • согласование скоростей обмена и кэширование данных; • разделение устройств и данных между процессами; • обеспечение удобного логического интерфейса между устрой- ствами и остальной частью системы; • поддержка широкого спектра драйверов с возможностью простого включения в систему нового драйвера; • динамическая: загрузка и выгрузка драйверов; • поддержка нескольких файловых систем; • поддержка синхронных и асинхронных операций ввода-вывода. 6.1.1. Организация параллельной работы устройств ввода-вывода и процессора Каждое устройство ввода-вывода вычислительной системы снаб- жено специализированным блоком управления, называемым конт- роллером. Контроллер взаимодействует с драйвером — системным программным модулем, предназначенным для управления данным устройством. Контроллер периодически принимает от драйвера вы- водимую на устройство информацию, а также команды управления, которые говорят о том, что с этой информацией нужно сделать. Под управлением контроллера устройство может некоторое время выпол- нять свои операции автономно, не требуя внимания со стороны центрального процессора. Это время зависит от многих факторов — объема выводимой информации, степени интеллектуальности управ- ляющего устройством контроллера, быстродействия устройства и т.п. Обычно скорость работы любого устройства ввода- вывода, даже са- мого скоростного, существенно ниже скорости работы процессора. Процессы, происходящие в контроллерах, протекают в периоды между выдачами команд независимо от ОС. От подсистемы ввода- вывода требуется спланировать в реальном масштабе времени (в ко- тором работают внешние устройства) запуск и приостановку7 боль-
шого количества разнообразных драйверов, обеспечив приемлемое время реакции каждого драйвера на независимые события контрол- лера. С другой стороны, необходимо минимизировать загрузку про- цессора задачами ввода-вывода, оставив как можно больше процес- сорного времени на выполнение пользовательских потоков. Данная задача является классической задачей планирования систем реального времени и обычно решается на основе многоуров- невой приоритетной схемы обслуживания по прерываниям. Для обеспечения приемлемого уровня реакции все драйверы (или части драйверов) распределяются по нескольким приоритетным уровням в соответствии с требованиями ко времени реакции и временем ис- пользования процессора. Для реализации приоритетной схемы обычно задействуется общий диспетчер прерываний ОС. 6.1.2. Согласование скоростей обмена и кэширование данных При обмене данными всегда возникает задача согласование ско- рости. Например, если один процесс вырабатывает некоторые дан- ные и передает их другому процессу через оперативную память, то в общем случае скорости генерации данных и их чтения не совпа- дают. Согласование скорости обычно достигается за счет буфериза- ции данных в оперативной памяти и синхронизации доступа процес- сов к буферу. В подсистеме ввода-вывода для согласования скоростей обмена также широко используется буферизация данных в оперативной па- мяти. Однако буферизация только на основе оперативной памяти в подсистеме ввода-вывода оказывается недостаточной из-за большой разницы между скоростью обмена с оперативной памятью, куда про- цессы помещают данные для обработки, и скоростью работы внеш- него устройства. Для таких случаев необходимо предусмотреть другие методы, и часто в качестве буфера используется дисковый файл, на- зываемый спул-фай. юм. Типичный пример применения спулинга дает организация вывода данных на принтер. Печатаемвге документы мо- iyr иметь объем в несколько десятков мегабайт, поэтому для их вре- менного хранения (а печать документа может занимать десятки ми- нут) объема оперативной памяти может просто не хватить. Другим решением этой проблемы является использование боль- шой буферной памяти в контроллерах внешних устройств. Такой подход особенно полезен в тех случаях, когда помещение данных на диск слишком замедляет обмен (или когда данные выводятся на сам диск).
Буферизация данных позволяет не только согласовать скорости работы процессора и внешнего устройства, но и решить другую за- дачу — сократить количество реальных операций ввода-вывода за счет кэширования данных. Дисковый кэш является непременным атрибутом подсистем ввода-вывода практически всех операционных систем, значительно сокращая время доступа к хранимым данным. 6.1.3. Разделение устройств и данных между процессами Устройства ввода-вывода могут предоставляться процессам как в монопольное, так и в совместное (разделяемое) использование. При этом ОС должна обеспечивать контроль доступа теми же спо- собами, что и при доступе процессов к другим ресурсам вычисли- тельной системы, — путем проверки прав пользователя или группы пользователей, от имени которых действует процесс, на выполнение той или иной операции над устройством. Операционная система может контролировать доступ не только к устройству в целом, но и к отдельным порциям данных, хранимых или отображаемых этим устройством. Диск является типичным при- мером устройства, для которого важно контролировать доступ не к устройству в целом, а к отдельным каталогам и файлам. Так, в файловой системе обычно для каждого каталога и файла можно задать индивидуальные права доступа. Однако одно и то же устройство в разные периоды времени мо- жет использоваться как в разделяемом, так и в монопольном ре- жиме, хотя существуют устройства, для которых обычно характерен только один из этих режимов. Операционная система должна осуществлять отслеживание процедур захвата и освобождения мо- нопольно используемых устройств, а в случае совместного исполь- зования — оптимизировать последовательность операций ввода- вывода для различных процессов в целях повышения общей произ- водительности. При разделении устройства между процессами может возникнуть необходимость в разграничении порции данных двух процессов друг от друга. Обычно такая потребность возникает при совместном ис- пользовании так называемых последовательных устройств, данные в которых, в отличие от устройств прямого доступа, не адресуются. Типичным представителем такого рода устройства является принтер, который не выделяется в монопольное владение процессам, и в то же время каждый документ должен быть напечатан в виде последова- тельного набора страниц. Для подобных устройств организуется оче- редь заданий на вывод, при этом каждое задание представляет собой
порцию данных, которую нельзя разрывать, например документ для печати. Для хранения очереди заданий используется спул-файл, ко- торый одновременно согласует скорости работы принтера и опера- тивной памяти и позволяет организовать разбиение данных на логи- ческие порции. 6 1.4. Обеспечение удобного логического интерфейса между устройствами и остальной частью системы Большое число различных устройств ввода-вывода делают осо- бенно актуальной функцию ОС по созданию экранирующего логи- ческого интерфейса между периферийными устройствами и прило- жениями. Практически все современные операционные системы поддерживают в качестве основы такого интерфейса файловую мо- дель периферийных устройств. Б этом случае любое периферийное устройство представляется программисту в виде последовательности байт, с которыми можно работать с помощью унифицированных сис- темных вызовов (например, read и write), задавая имя файла-устрой- ства и смещение от начала последовате льности байт. Достоинство этой модели файла-устройства состоит в ее простоте и унифицированности для устройств любого типа, однако во многих случаях для программирования операций ввода-вывода некоторого устройства ее недостаточно. Поэтому данная модель часто исполь- зуется только в качестве основы, на которой подсистема ввода-вы- вода строит более содержательную модель устройств конкретного типа. 6.1.5. Поддержка широкого спектра драйверов и простота включения нового драйвера в систему Основным достоинством подсистемы ввода-вывода любой уни- версальной ОС является наличие разнообразного набора драйверов для наиболее популярных периферийных устройств. Прекрасно спланированная и реализованная операционная система может по- терпеть неудачу на рынке только из-за того, что в ее состав не вклю- чен достаточный набор драйверов и пользователи вынуждены искать нужный им драйвер для имеющегося у них внешнего устройства у производителей оборудования или, что еще хуже, заниматься его разработкой. Чтобы операционная система не испытывала недостатка в драй- верах, необходимо наличие четкого, удобного и открытого интер- фейса между драйверами и другими компонентами ОС. Такой ин- терфейс нужен для того, чтобы драйверы писали не только непосред-
ствснные разработчики данной операционной системы, но и программисты тех фирм, которые выпускают внешние устройства для компьютеров Открытость интерфейса драйверов, т.е. доступ- ность его описания для независимых разработчиков программного обеспечения, является необходимым условием успешного развития операционной системы. Драйвер взаимодействует, с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, модулями системных вызовов, модулями подсистем управления процессами и памятью и т.д.), а с другой стороны — с контроллерами внешних устройств. Поэтому существуют два типа интерфейсов: интерфейс «драйвер—ядро» (Driver Kernel Interface, DKI) и интерфейс «драйвер—устройство» (Driver De- vice Interface, DDT). Интерфейс «драйвер—ядро» должен быть стан- дартизован в любом случае, а интерфейс «драйвер—устройство» имеет смысл стандартизировать тогда, когда подсистема ввода-вывода не разрешает драйверу непосредственно взаимодействовать с аппара- турой контроллера, а выполняет эти операции самостоятельно. Экра- нирование драйвера от аппаратуры является весьма полезной функ- цией, так как драйвер в этом случае становится независимым от аппа- ратной платформы. Подсистема ввода-вывода может поддерживать несколько различных типов интерфейсов DKI/DDI, предоставляя специфический интерфейс для устройств определенного класса. Для поддержки процесса разработки драйверов операционной системы обычно выпускается так называемый пакет DDK (Driver De- velopment Kit), представляющий собой набор соответствующих ин- струментальных средств — библиотек, компиляторов и отладчиков. 6.1 6. Динамическая загрузка и выгрузка драйверов Кроме проблемы разработки новых драйверов, существует также проблема включения драйвера в состав модулей работающей ОС, т.е. динамической за] рузки-выгрузки драйвера Так как набор потен- циально поддерживаемых данной ОС периферийных устройств всегда существенно шире набора устройств, которыми ОС должна управлять при установке на конкретной машине, то ценным свой- ством ОС является возможность динамически загружать в оператив- ную память требуемый драйвер (без останова ОС) и выгружать его после того, как потребность в поддержке устройства миновала, что может существенно сэкономить системную область памяти. Поддержка динамической загрузки драйверов является практи- чески обязательным требованием для современных универсальных операционных систем.
6.1.7. Поддержка нескольких файловых систем Диски представляют особый род периферийных устройств, так как именно на них хранится большая часть как пользовательских, так и системных данных. Данные на дисках организуются в файло- вые системы, и свойства файловой системы во многом определяют свойства самой ОС — ее отказоустойчивость, быстродействие, мак- симальный объем хранимых данных. Популярность файловой сис- темы часто приводит к ее миграции из «родной» ОС в другие опера- ционные системы: например, файловая система FAT появилась пер- воначально в MS DOS, но затем была реализована в OS/2, семействе MS Windows и многих реализациях UNIX. Ввиду этого поддержка нескольких популярных файловых систем для подсистемы ввода- вывода так же важна, как и поддержка широкого спектра перифе- рийных устройств. Важно также, чтобы архитектура подсистемы ввода-вывода позволяла достаточно просто включать в ее состав но- вые типы файловых систем без необходимости переписывания кода ОС 6.1.8. Поддержка синхронных и асинхронных операций ввода-вывода Операция ввода-вывода может выполняться по отношению к процессу, запросившему операцию, в синхронном или асинхрон- ном режимах. Синхронный режим означает, что процесс приостанав ливает свою работу до тех пор, пока операция ввода-вывода не будет завершена (рис. 6.1, а), а при асинхронном режиме процесс продол- жает выполняться в мультипрограммном режиме одновременно с операцией ввода-вывода (рис. 6.1, б). Отличие же заключается в том, что операция ввода-вывода может быть инициирована не только пользовательским процессом — в этом случае операция выполняется в рамках системного вызова, но и кодом ядра, напри- мер кодом подсистемы виртуальной памяти для считывания отсут ствующей в памяти страницы. Подсистема ввода-вывода должна предоставлять своим клиентам (пользовательским процессам и кодам ядра) возможность выполнять как синхронные, так и асинхронные операции ввода вывода в зави симости от их потребностей. Системные вызовы ввода-вывода, ге- нерируемые пользовательскими приложениями, чаще выполняются как синхронные процедуры в связи с тем, что такие операции длятся долго и пользовательскому процессу или потоку все равно придется ждать получения результатов операции для того, чтобы продолжить
Синхронное выполнение операции ввода-вывода Асинхронное выполнение операции ввода-вывода П1 Вызывающая процедура Процедура ввода-вывода П2 Другие процессы Рис, 6.1. Два режима выполнения операций ввода-вывода свою работу. Внутренние же вызовы операций ввода-вывода из мо- дулей ядра обычно выполняются в виде асинхронных процедур, так как кодам ядра нужна свобода в выборе дальнейшего поведения после запроса операции ввода-вывода. 6.2. Многослойная модель подсистемы ввода-вывода Многослойное построение, характерное для операционных систем, оптимально и при построении подсистемы ввода-вывода. При большом разнообразии устройств ввода-вывода, обладающих существенно различными характеристиками, иерархическая струк- тура программного обеспечения позволяет соблюсти баланс между двумя весьма противоречивыми требованиями: с одной стороны,
необходимо учесть все особенности каждого устройства, а с другой стороны, обеспечить единое логическое представление и унифици- рованный интерфейс для устройств всех типов. При этом нижние слои подсистемы ввода-вывода должны включать индивидуальные драйверы, написанные для конкретных физических устройств, а верхние слои должны обобщать процедуры управления этими устройствами, предоставляя общий интерфейс если не для всех устройств, то, по крайней мере, для групп устройств, обладающих некоторыми общими характеристиками, например для принтеров, дисков и т.п. Многослойность структуры, безусловно, облегчает решение боль- шинства задач подсистемы ввода-вывода, таких как простота вклю- чения новых драйверов, поддержка нескольких файловых систем, динамическая загрузка-выгрузка драйверов и др. Обобщенная структура подсистемы ввода-вывода представлена на рис. 6.2. Из рисунка видно, что программное обеспечение ввода-вывода делится не только на горизонтальные слои, но и на вертикальные. Это объясняется тем, что для всего разнообразия различных внешних устройств трудно обеспечить единообразие в разбиении функций управления на слои. Поэтому общий принцип многослойности оста- ется справедливым, однако для устройств определенного типа он реа- лизуется по-разному, со своим количеством слоев и их функциями. В каждой вертикальной подсистеме существует несколько слоев модулей. Нижний слой образуют так называемые аппаратные драй- веры устройств, название которых отражает тот факт, что они управ- ляют аппаратурой внешних устройств, осуществляя обмен байтами и блоками байтов, и не имеют, как правило, дела с более высокоуров- невыми вопросами логической организации данных, например с файлами, или сложными графическими объектами. Функции вы- шележащих слоев в значительной степени зависят от типа вертикаль- ной подсистемы. В подсистеме ввода-вывода наряду с модулями, отражающими спе- цифику внешних устройств и образующими вертикальные подсистемы, существуют модули универсального назначения. Эти модули органи- зуют согласованную работу всех остальных компонентов подсистемы ввода-вывода и взаимодействие с пользовательскими процессами и другими подсистемами ОС. Так же как и функции управления устройствами, эти организующие функции распределены по всем уров- ням, образуя оболочку. Эта оболочка называется менеджером ввода- вывода Задачи такого менеджера довольно разнообразны.
Прикладной программный интерфейс Графические Сетевые Рис. 6.2. Структура подсистемы ввода-вывода: VFS (Virtual File System) — общий драйвер верхнего уровня, выполняющий роль диспетчера драйверов нескольких файловых систем; UFS (UNIX File System) — драйвер файловой системы ufs; NTFS (Windows NT File System) — драйвер файловой системы NTFS; FAT (File Allocation Table) — драйвер фай- ловой системы FAT; HDD (Hard Disk Drive) — жесткий диск; FDD (Floppy Disk Drive) — гибкий диск Верхний слой менеджера составляют системные вызовы ввода- вывода, которые принимают от пользовательских процессов за- просы на ввод-вывод и переадресуют их отвечающим за опреде- ленный класс устройств модулям и драйверам, а также возвращают процессам результаты операций ввода-вывода. Таким образом этот слой поддерживает пользовательский интерфейс ввода-вывода, со- здавая для прикладных программистов максимум удобств по мани- пулированию внешними устройствами и расположенными на них данными. Нижний слой менеджера реализует непосредственное взаимодей- ствие с контроллерами внешних устройств, экранируя драйверы от особенностей аппаратной платформы компьютера — шины ввода- вывода, системы прерываний и т.п. Этот слой принимает от драйве- ров запросы на обмен данными с регистрами контроллеров в неко-
торой обобщенной форме с использованием независимых от шины ввода-вывода адресации и формата, а затем преобразует эти запросы в зависящий от аппаратной платформы формат. Важной функцией менеджера ввода-вывода является создание некоторой среды для остальных компонентов подсистемы, кото- рая бы облегчала их взаимодействие друг с другом. Эта задача может быть решена за счет создания некоторого стандартного внутреннего интерфейса взаимодействия модулей ввода-вывода между собой, который бы дополнял внешние интерфейсы подсистемы с приклад- ными процессами, другими модулями ядра и аппаратурой. Наличие такого интерфейса существенно облегчает включение новых драй- веров и файловых систем в состав ОС. Кроме того, разработчики драйверов и других программных компонентов освобождаются от на- писания общих процедур, таких как буферизация данных и синхро- низация нескольких модулей между собой при обмене данными Все эти функции берет на себя менеджер ввода-вывода. Еще одной функцией менеджера ввода-вывода является органи- зация взаимодействия модулей ввода-вывода с модулями других под- систем ОС, таких как подсистема управления процессами, виртуаль- ной памятью и др. Наличие стандартного внутреннего межмодульного интерфейса повышает устойчивость и улучшает расширяемость подсистемы ввода-вывода, хотя может несколько замедлить ее работу, так как любое разделение на слои и части приводит к дополнительным опе- рациям при взаимодействии по сравнению с монолитной организа- цией с прямыми передачами управления. 6.3. Логическая организация файловой системы Предоставление пользователю комфортной работы с данными, хранящимися на дисках, является одной из основных задач опера- ционной системы. Для этого ОС подменяет физическую структуру хранящихся данных удобной для пользователя логической структу- рой. Логическая структура файловой системы реализуется в виде дерева каталогов, символьными именами файлов и командами ра бот ы с файлами и каталогами. Базовым элементом этой структуры является файл. 6.3.1. Цели и задачи файловой системы Файл — это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Файлы
хранятся в памяти, не зависящей от энергопитания, обычно — на магнитных или электронных дисках. Использование файлов позволяет решать следующие основные задачи файловой системы. Долговременное и падежное хранение информации. Долговремен- ность достигается за счет использования запоминающих устройств, не зависящих от питания, а высокая надежность определяется сред- ствами защиты доступа к файлам. Совместное использование информации. Файлы обеспечивают ес- тественный и легкий способ разделения информации между прило- жениями и пользователями за счет наличия понятных человеку сим- вольных имен. Пользователи имеют удобные средства работы с фай- лами, включая каталоги-справочники, объединяющие файлы в группы, средства поиска файлов по признакам, набор команд для создания, модификации и удаления файлов. Файл может быть создан одним пользователем, а затем использоваться совсем другим поль- зователем, при этом создатель файла или администратор может опре- делить права доступа к нему других пользователей. Файловая система (ФС) — это часть операционной системы, включающая: • совокупность всех файлов на диске; • наборы структур данных, используемых для управления фай- лами, таких, например, как каталоги, дескрипторы файлов, таб- лицы распределения свободного и занятого пространства на диске; • комплекс системных программных средств, реализующих различ- ные операции над файлами, такие как создание, уничтожение, чтение, запись, именование и поиск файлов. Файловая система позволяет программистам обходиться набором достаточно простых операций для выполнения действий над фай- лами. При этом все вопросы, связанные с деталями действительного расположения данных на диске, буферизацией данных и другими низкоуровневыми проблемами передачи данных с долговременного запоминающего устройства, файловая система берет на себя. Фай- ловая система распределяет дисковую память, поддерживает имено- вание файлов, отображает имена файлов в соответствующие адреса во внешней памяти, обеспечивает доступ к данным, поддерживает разделение, защиту и восстановление файлов. Таким образом, файловая система играет роль промежуточного слоя, экранирующего все сложности физической организации дисков и создающего более простую логическую организацию
дисков, а также предоставляющего набор удобных в использовании команд для манипулирования файлами. Задачи, решаемые ФС, зависят от способа организации вычисли- тельного процесса в целом. Самый простой тип — это ФС в одно- пользовательских и однопрограммных ОС, к числу которых отно- сится, например, MS DOS. Основные функции в такой ФС нацелены на решение следующих задач: • именование файлов; • обеспечение программного интерфейса для приложений; • отображение логической структуры файловой системы на физи- ческую структуру дисков; • устойчивость файловой системы к сбоям питания, ошибкам ап- паратных и программных средств. Задачи ФС усложняются в однопользовательских мультипро- граммных ОС, которые хотя и предназначены для работы одного пользователя, но дают ему возможность запускать одновременно несколько процессов. Одной из первых ОС этого типа стала OS/2. К перечисленным выше задачам добавляется новая задача совмест- ного доступа к файлу из нескольких процессов. Файл в этом случае является разделяемым ресурсом, а значит, файловая система должна решать весь комплекс проблем, связанных с такими ресурсами. В частности, в ФС должны быть предусмотрены средства блокировки файла и его частей, предотвращения гонок, исключения тупиков, согласования копий и т.п. В многопользовательских системах появляется еще одна задача: защита файлов одного пользователя от несанкционированного до- ступа другого пользователя. Еще более сложными становятся функции ФС, которая работает в составе сетевой ОС. 6.3.2. Типы файлов Файловые системы поддерживают несколько основных функцио- нально различных типов файлов, в число которых, как правило, вхо- дят обычные файлы, файлы-каталоги и специальные файлы. Обычные файлы, или просто файлы, содержат информацию про- извольного характера, которую заносит в них пользователь или ко- торая образуется в результате работы системных и пользовательских программ. Современные операционные системы никак не ограни- чивают и не контролируют содержимое и структуру обычного файла. Содержание обычного файла определяется приложением, которое с ним работает.
Все операционные системы должны уметь распознавать соб- ственные исполняемые файлы. Каталоги — это особый тип файлов, которые содержат системную справочную информацию о наборе файлов, сгруппированных поль- зователями по какому-либо неформальному признаку. В большин- стве операционных систем в каталог могут входить файлы любых типов, в том числе другие каталоги, за счет чего образуется древовид- ная структура, удобная для поиска. Каталоги устанавливают соответ- ствие между именами файлов и их характеристиками, использу- емыми файловой системой для управления файлами. Б число таких характеристик входит, в частности, информация (или указатель на другую структуру, содержащую эти данные) с типе файла и распо- ложении его на диске, правилах доступа к файлу и датах его создания и модификации. Во всех остальных отношениях каталоги рассмат- риваются файловой системой как обычные файлы. Специальные файлы — это фиктивные файлы, ассоциированные с устройствами ввода-вывода, которые используются для унифика- ции механизма доступа к файлам и внешним устройствам. Специ- альные файлы позволяют пользователю выполнять операции ввода- вывода посредством обычных команд записи в файл или чтения из файла. Эти команды обрабатываются файловой системой, а затем преобразуются операционной системой в команды управления со- ответствующим устройством. Современные файловые системы поддерживают и другие типы файлов. 6.3.3. Иерархическая структура файловой системы Пользователи обращаются к файлам по символьным именам, но если файлы не структурировать, то со временем трудно будет ра- зобраться в огромном числе этих файлов или вспомнить имена от- дельных, необходимых для работы файлов. Иерархическая структура файловой системы позволяет решить эту проблему. Именно поэтому большинство файловых систем имеет иерархическую структуру, в ко- торой уровни создаются за счет того, что каталог более низкого уровня может входить в каталог более высокого уровня (рис. 6.3). Граф, описывающий иерархию каталогов, может быть деревом или сетью. Каталоги образуют дерево, если файлу разрешено входить только в один каталог (рис. 6.3, б), и сеть — если файл может входить сразу в несколько каталогов (рис. 6.3, в). Например, в MS-DOS и Windows каталоги образуют древовидную структуру, а в UNIX — се- тевую. В древовидной структуре каждый файл является листом. Ka-
Рис. 6.3. Иерархия файловых систем талог самого верхнего уровня называется корневым каталогом или корнем (root). При такой организации пользователь освобожден от запоминания имен всех файлов, ему достаточно примерно представлять, к какой группе может быть отнесен тот или иной файл, чтобы путем после- довательного просмотра каталогов найти его. Иерархическая струк- тура удобна для многопользовательской работы: каждый пользова- тель со своими файлами локализуется в своем каталоге или подде- реве каталогов, и вместе с тем все файлы в системе логически связаны. Частным случаем иерархической структуры является одноуровне- вая организация, когда все файлы входят в один каталог (рис. 6.3, а). 6.3.4. Имена файлов Все типы файлов имеют символьные имена. В иерархически ор- ганизованных файловых системах обычно используются три типа имен файлов: • простые; • составные; • относительные.
Простое, или короткое, символьное имя идентифицирует файл в пределах одного каталога. Простые имена присваивают файлам пользователи и программисты, при этом они должны учитывать ограничения ОС как на номенклатуру символов, так и на длину имени. Так, в старых версиях файловой системы FAT длина имен ограничивалась схемой 8.3 (8 символов — собственно имя, 3 сим- вола — расширение имени). Однако пользователю гораздо удобнее работать с длинными именами, поскольку они позволяют дать фай- лам легко запоминающиеся названия, ясно говорящие о том, что содержится в этом файле. Поэтому современные файловые системы, а также усовершенствованные варианты уже существовавших фай- ловых систем, как правило, поддерживают длинные простые сим- вольные имена файлов. Например, в файловых системах NTFS и FAT32 имя файла может содержать до 255 символов. В иерархических файловых системах разным файлам разрешено иметь одинаковые простые символьные имена при условии, что они принадлежат разным каталогам. То есть здесь работает схема «много файлов — одно простое имя». Для однозначной идентификации файла в таких системах используется так называемое полное имя. Полное имя (составное имя) представляет собой цепочку простых символьных имен всех каталогов, через которые проходит путь от корня до данного файла Таким образом, полное имя является составным, в котором простые имена отделены друг от друга приня- тым в ОС разделителем. Часто в качестве разделителя используется прямой или обратный слеш, при этом принято не указывать имя корневого каталога. В древовидной файловой системе между файлом и его полным именем имеется взаимно однозначное соответствие «один файл — одно полное имя». В файловых системах, имеющих сетевую струк- туру, файл может входить в несколько каталогов, а значит, иметь несколько полных имен; здесь справедливо соответствие «один файл — много полных имен». В обоих случаях файл однозначно идентифицируется полным именем. Файл может быть идентифицирован также относительным име- нем. Относительное имя файла определяется через понятие «теку- щий каталог». Для каждого пользователя в каждый момент времени один из каталогов файловой системы является текущим, причем этот каталог выбирается самим пользователем или по команде ОС. Фай- ловая система фиксирует имя текущего каталога, чтобы затем ис- пользовать его как дополнение к относительным именам для обра- зования полного имени файла. При использовании относительных
имен пользователь идентифицирует файл цепочкой имен каталогов, через которые проходит маршрут от текущего каталога до данного файла, В некоторых операционных системах разрешено присваивать од- ному и тому же файлу несколько простых имей, которые можно ин- терпретировать как псевдонимы. В этом случае, так же как в системе с сетевой структурой, устанавливается соответствие «один файл — много полных имен», так как каждому простому имени файла соот- ветствует по крайней мере одно полное имя. И хотя полное имя однозначно определяет файл, операционной системе проще работать с файлом, если между файлами и их име- нами имеется взаимно однозначное соответствие. С этой целью она присваивает файлу уникальное имя, так что справедливо соотноше- ние «один файл — одно уникальное имя». Уникальное имя суще- ствует наряду с одним или несколькими символьными именами, присваиваемыми файлу пользователями или приложениями. Уни- кальное имя представляет собой числовой идентификатор и предна- значено только для операционной системы. 6.3.5. Атрибуты файлов Понятие «файл» включает не только хранимые им данные и имя, но и атрибуты. Атрибуты — это информация, описывающая свой- ства файла. Примеры возможных атрибутов файла: • тип файла (обычный файл, каталог, специальный файл и т.п.); • владелец файла; • создатель файла; • пароль для доступа к файлу; • информация о разрешенных операциях доступа к файлу; • времена создания, последнего доступа и последнего изменения; • текущий размер файла; • максимальный размер файла; • признак «только для чтения»; • признак «скрытый файл»; • признак «системный файл»; • признак «архивный файл»; • признак «двоичный/символьный»; • признак «временный» (удалить после завершения процесса); • признак блокировки; • длина записи в файле; • указатель на ключевое поле в записи; • длина ключа.
Набор атрибутов файла определяется спецификой файловой сис- темы: в файловых системах разного типа для характеристики файлов могут использоваться разные наборы атрибутов, Например, в одно- пользовательской ОС в наборе атрибутов будут отсутствовать харак- теристики, имеющие отношение к пользователям и защите, такие как владелец файла, создатель файла, пароль для доступа к файлу, информация о разрешенном доступе к файлу. Пользователь может получать доступ к атрибутам, используя средства, предоставленные для этих целей файловой системой. Обычно разрешается читать значения любых атрибутов, а изме- нять — только некоторые. Например, пользователь может изменить права доступа к файлу (при условии, что он обладает необходимыми для этого полномочиями), но изменять дату создания или текущий размер файла ему не разрешается. Значения атрибутов файлов могут непосредственно содержаться в каталогах, как это сделано в файловой системе MS DOS (рис. 6.4, а). На рисунке представлена структура записи в каталоге, содержащая простое символьное имя и атрибуты файла. Здесь буквами обозна- чены признаки файла: R — только для чтения, А — архивный, Н — скрытый, S — системный. б) Номер индексного дескриптора Имг файла Рис. 6.4, Структура каталогов: а — структура каталога MS DOS (32 байта); б — структура записи каталога ОС UNIX (16 байт) Другим вариантом является размещение атрибутов в специальных таблицах, когда в каталогах содержатся только ссылки на эти таб- лицы Такой подход реализован, например, в файловой системе ufs ОС UNIX В этой файловой системе структура каталога очень про-
стая. Запись о каждом файле содержит короткое символьное имя файла и указатель на индексный дескриптор файла, так называется в ufs таблица, в которой сосредоточены значения атрибутов файла (рис. 6.4, б). В том и другом вариантах каталоги обеспечивают связь между именами файлов и собственно файлами. Однако подход, когда имя файла отделено от его атрибутов, делает систему более гибкой. На- пример, файл может быть легко включен сразу в несколько катало- гов. Записи об этом файле в разных каталогах могут содержать раз- ные простые имена, но в поле ссылки будет указан один и тот же номер индексного дескриптора. 6.3.6. Логическая организация файла Данные, содержащиеся в файле, имеют некую логическую струк- туру, которая является базой при разработке программы, предназна- ченной для обработки этих данных. Например, чтобы текст мог быть правильно выведен на экран, программа должна иметь возможность выделить отдельные слова, строки, абзацы и т.д. Признаками, отде- ляющими один структурный элемент от другого, могут служить опре- деленные кодовые последовательности или просто известные прог- рамме значения смещений этих структурных элементов относи- тельно начала файла. Поддержание структуры данных может быть либо целиком возложено на приложение, либо в той или иной сте- пени эту работу может взять на себя файловая система. В первом случае, когда все действия, связанные со структуриза- цией и интерпретацией содержимого файла, целиком относятся к ве- дению приложения, файл представляется <£>С неструктурированной последовательностью данных. Приложение формулирует запросы к файловой системе на ввод-вывод, используя общие для всех при- ложений системные средства, например указывая смещение от на- чала файла и количество байт, которые необходимо считать или за- писать. Поступивший к приложению поток байт интерпретируется в соответствии с заложенной в программе логикой. Модель файла, в соответствии с которой содержимое файла пред- ставляв гея неструктурированной последовательностью (потоком) байт, стала популярной вместе с ОС UNIX, а теперь она широко ис- пользуется в большинстве современных ОС, в том числе в MS DOS, Winnows NT/2000 и.т.д. Неструктурированная модель файла позво- ляет легко организовать разделение файла между несколькими при- ложениями: разные приложения могут по-своему структурировать и интерпретировать данные, содержащиеся в файле.
Другая модель файла, которая применялась в ОС OS/360, DEC RSX и VMS, а в настоящее время используется достаточно редко, — это структурированный файл. В этом случае поддержание структуры файла поручается файловой системе. Файловая система видит файл как упорядоченную последовательность логических записей. При- ложение может обращаться к ФС с запросами на ввод-вывод на уровне записей, например «считать запись 25 из файла FILE. DOC». ФС должна обладать информацией о структуре файла, доста- точной для того, чтобы выделить любую запись. ФС предоставляет приложению доступ к записи, а вся дальнейшая обработка данных, содержащихся в этой записи, выполняется приложением. Развитием этого подхода стали системы управления базами данных (СУБД), которые поддерживают не только сложную структуру данных, но и взаимосвязи между ними. Логическая запись является наименьшим элементом данных, ко- торым может оперировать программист при организации обмена с внешним устройством. Даже если физический обмен с устройством осуществляется большими единицами, операционная система должна обеспечивать программисту доступ к отдельной логической записи. Файловая система может использовать два способа доступа к ло- гическим записям: читать или записывать логические записи после- довательно (последовательный доступ) или позиционировать файл на запись с указанным номером (прямой доступ). Очевидно, что ОС не может поддерживать все возможные спо- собы структурирования данных в файле, поэтому в тех ОС, в которых вообще существует поддержка логической структуризации файлов, она существует для небольшого числа широко распространенных схем логической организации файла. К числу "аких способов структуризации относится представление данных в виде записей, длина которых фиксирована в пределах файла (рис. 6.5, а). В таком случае доступ к л-й записи осуществля- ется либо путем последовательного чтения (л - 1) предшествующих записей, либо прямо по адресу, вычисленному по ее порядковому номеру. Например, если L — длина записи, то начальный адрес л-й записи равен Lxn. Заметим, что при такой логической организации размер записи фиксирован в пределах файла, а записи в различных файлах, принадлежащих одной и той же файловой системе, могут иметь различный размер. Другой способ структуризации состоит в представлении данных в виде последовательности записей, размер которых изменяется
I ,, t I 1 * 1 1 * t 1 y 1 * Последовательность логических записей фиксированной длины Последовательность логических записей переменной длины 1 8 6 2 5 Индексная Запись 1 Запись 2 Запись 3 Запись 4 Запись 5 таблица Индексная логическая организация Индекс 1 2 3 4 5 6 Адрес 21 201 315 661 670 715 Рис. 6.5. Способы логической организации файлов в пределах одного файла. Если расположить значения длин записей так, как это показано на рис. 6.5, б, то для поиска нужной записи система должна последовательно считать все предшествующие за- писи. Вычислить адрес нужной записи по ее номеру при такой логи- ческой организации файла невозможно, а следовательно, не может быть применен более эффективный метод прямого доступа. Файлы, доступ к записям которых осуществляется последова- тельно, по номерам позиций, называются неиидексированными или I юследовательными. Другим типом файлов являются индексированные файлы, они допускают более быстрый прямой доступ к отдельной логической записи. В индексированном файле (рис. 6.5, в) записи имеют одно или более ключевых (индексных) полей и могут адресоваться путем указания значений этих полей. Для быстрого поиска данных в ин- дексированном файле предусматривается специальная индексная таблица, в которой значениям ключевых полей ставится в соответ- ствие адрес внешней памяти. Этот адрес может указывать либо не- посредственно на искомую запись, либо на некоторую область внешней памяти, занимаемую несколькими записями, в число ко-
торых входит искомая запись. В последнем случае говорят, что файл имеет индексно-последовательную организацию, так как поиск включает два этапа: прямой доступ по индексу к указанной области диска, а затем последовательный просмотр записей в указанной об- ласти. Ведение индексных таблиц берет на себя файловая система. Понятно, что записи в индексированных файлах могут иметь произ- вольную длину. Все вышесказанное в большей степени относится к обычным файлам, которые могут быть как структурированными, так и не- структурированными. Что же касается других типов файлов, то они обладают определенной структурой, известной файловой системе. Например, файловая система должна понимать структуру данных, хранящихся в файле-каталоге. 6.4. Физическая организация файловой системы Представление пользователя о файловой системе как об иерар хически организованном множестве информационных объектов имеет мало общего с порядком хранения файлов на диске. Файл, имеющий образ цельного, непрерыБающегося набора байт, на са- мом деле в большинстве случаев разбросан «кусочками» по всему диску, причем это разбиение никак не связано с логической струк- турой файла. Логически объединенные файлы из одного каталога совсем не обязаны соседствовать на диске. Принципы размещения файлов, каталогов и системной информации на реальном устрой- стве описываются физической организацией файловой системы. Очевидно, что разные файловые системы имеют разную физиче- скую организацию. 6.4.1. Диски, разделы, секторы, кластеры Основным типом устройства, которое используется в совре- менных компьютерах для хранения файлов, являются дисковые на- копители. Эти устройства предназначены для считывания и записи данных на жесткие и гибкие магнитные диски. Жесткий диск со- стоит из одного или нескольких стеклянных или металлических дисков, каждый из которых покрыт с одной или двух сторон магнит- ным материалом. Таким образом, диск в общем случае состоит из па- кета дисков и блока головок, с помощью которых осуществляется считывание и запись данных на диск (рис. 6.6). На каждой стороне каждого диска (поверхности) размечены тон- кие концентрические кольца — дорожки (traks), на которых хранятся
Сек-оры Дорожка 0 поверхности 0 Дорожка 0 поверхности I Дорожка 0 поверхности 2 Дсрожка и поверхности 3 Дорожка 0 поверхности 4 Дорожка 0 поверхности 5 Дорожка О I юверхнос ги 6 Дорожка 0 поверхности 7 Поверхность О 11оверхиость 1 Поверхность 2 Повгр.;ность 3 ПиВ“рхность 4 П >ь=рлНОСТо 5 Поверхность 6 I ю-’еркность 7 Блок головок Рие. 6.6. Схема устройства жесткого диска данные. Количество дорожек зависит от типа диска. Нумерация до- рожек начинается с нуля от внешнего края к центру диска. Когда диск вращается, головка считывает или записывает двоичные данные с или на магнитную дорожку. Головка может позиционироваться над заданной дорожкой, пе- ремещаясь над поверхностью диска дискретными шагами, каждый шаг соответствует сдвигу на одну дорожку. Запись на диск осуще- ствляется благодаря способности головки изменять магнитные свой- ства дорожки. В некоторых дисках вдоль каждой поверхности пере- мещается одна головка, а в других — имеется по головке на каждую дорожку. В первом случае для поиска информации головка должна перемещаться по радиусу диска. Обычно все головки закреплены на едином перемещающем механизме и двигаются синхронно. По- этому, когда головка фиксируется на заданной дорожке одной по- верхности, все остальные головки останавливаются над дорожками с такими же номерами. В тех же случаях, когда на каждой дорожке имеется отдельная головка, никакого перемещения головок с одной дорожки на другую не требуется, за счет этого экономится время, затрачиваемое на поиск данных.
Совокупность дорожек одного радиуса (с одинаковыми номе- рами) на всех поверхностях всех пластин пакета называется ци- линдром (cylinder). Каждая дорожка разбивается на фрагменты, на- зываемые секторами (sectors), так что все дорожки имеют равное число секторов, в которые можно максимально записать одно и то же число байт. Сектор имеет фиксированный для конкретной системы размер, выражающийся степенью двойки. Учитывая, что дорожки разного радиуса имеют одинаковое число секторов, плотность записи становится тем выше, чем ближе дорожка к центру. В большинстве современных дисковых накопителей используется так называемая зонная запись с переменным количеством секторов на дорожке. Дорожки, более удаленные от центра, а значит, и более длинные содержат большее число секторов, чем близкие к центру. Один из способов повышения емкости жесткого диска заключается в разделении внешних цилиндров на большее количество секторов по сравнению с внутренними цилиндрами (рис. 6 7). Внешняя зона Рис. 6.7. Разные способы записи данных на диск: а — стандартная запись; б — зонная запись При зонной записи цилиндры разбиваются на группы, которые называются зонами, причем по мере продвижения к внешнему краю диска дорожки разбиваются на все большее число секторов Во всех цилиндрах, относящихся к одной зоне, количество секторов на до- рожках одинаковое. Возможное количество зон зависит от типа на- копителя; в большинстве устройств их бывает 10 и более. Еще одно свойство зонной записи состоит в том, что скорость обмена данными с накопителем может изменяться и зависит от зоны, в которой в конкретный момент располагаются головки. Происходит это потому, что секторов во внешних зонах больше, а угловая скорость вращения диска постоянна (т.е. линейная ско- рость перемещения секторов относительно головки при считывании
и записи данных на внешних дорожках оказывается выше, чем на внутренних). Сектор — наименьшая адресуемая единица обмена данными ди- скового устройства с оперативной памятью, Каждый сектор состоит из поля данных и поля служебной инфор- мации, ограничивающей и идентифицирующей его, Размер сектора (точнее — емкость поля данных) устанавливается контроллером или драйвером. Например, пользовательский интерфейс DOS поддержи- вает единственный размер сектора — 512 байт. BIOS же непосред- ственно предоставляет возможности работы с секторами размером 128, 256, 512 или 1024 байт. Если управлять контроллером непосред- ственно, а не через программный интерфейс более высокого уровня (например, уровень DOS), то можно обрабатывать секторы и с дру- гими размерами. Однако в большинстве современных ОС размер сектора выбирается равным 512 байт. Физический адрес сектора на диске определяется с помощью трех «координат», т.е. представляется триадой [с-/?-^], где с — номер ци- линдра (дорожки на поверхности диска, cylinder); h — номер рабочей поверхности диска (магнитной головки, head); s — номер сектора на дорожке, Номер цилиндра с лежит в диапазоне от 0 до С - 1, где С — количество цилиндров. Номер рабочей поверхности диска h принадлежит диапазону от 0 до Н - 1, где Н — число магнитных го- ловок в накопителе. Номер сектора на дорожке л указывается в диа- пазоне от 1 до S, где 5 — количество секторов на дорожке. Например, триада [1-0-2] адресует сектор 2 на поверхности 0 (обычно верхняя рабочая поверхность) цилиндра 1. Все секторы диска имеют непрерывную нумерацию от 0 до N - 1, где N — количество секторов на диске. Таким образом, сначала (на- чиная с нуля) нумеруются секторы на нулевой дорожке нулевой по- верхности, затем — на нулевой дорожке первой поверхности, за- тем — на нулевой дорожке второй поверхности и т.д. После перену- мерации секторов на нулевых дорожках всех поверхностей описанный процесс повторяется для первой и всех последующих дорожек. Операционная система при работе с диском использует, как пра- вило, собственную единицу дискового пространства, называемую кластером (cluster). При создании файла место на диске ему выделя- ется кластерами. Например, если файл имеет размер 2560 байт, а раз- мер кластера в файловой системе определен в 1024 байта, то файлу будет выделено на диске три кластера, несмотря на то что последний кластер будет использован не полностью
Кластер представляет собой один или несколько смежных секто- ров в логическом дисковом адресном пространстве (точнее — только в области данных), На дискетах кластер занимает один или два сек- тора, а на жестких дисках — обычно четыре или восемь секторов. Число секторов в кластере всегда кратно степени двойки. Логическое разбиение области данных на кластеры как совокупности секторов взамен использования одиночных секторов имеет следующий смысл: • уменьшается возможная фрагментация файлов; • ускоряется доступ к файлу, так как в несколько раз сокращается длина цепочек фрагментов дискового пространства, выделенных для него. Однако слишком большой размер кластера ведет к неэффектив- ному' использованию области данных, особенно в случае большого количества маленьких файлов. Дорожки и секторы создаются в результате выполнения про- цедуры физического, или низкоуровневого, форматирования диска, предшествующей использованию диска. Низкоуровневое формати- рование выполняется на заводе-изготовителе, где надиск записыва- ется идентификационная информация Низкоуровневый формат диска не зависит от типа операционной системы, которая этот диск будет использовать. Разметку диска под конкретный тип файловой системы выпол- няют процедуры высокоуровневого, или логического, форматиро- вания. При высокоуровневом форматировании определяется размер кластера и на диск записывается информация, необходимая для работы файловой системы, в том числе информация о доступном и неиспользуемом пространстве, о границах областей, отведенных под файлы и каталоги, о поврежденных областях. Кроме того, на диск записывается загрузчик операционной системы — неболь- шая программа, которая начинает процесс инициализации опера- ционной системы после включения питания или рестарта компью- тера. Прежде чем форматировать диск под определенную файловую систему, он может быть разбит на разделы. Раздел — это непрерывная часть физического диска, которую операционная система представ- ляет пользователю как логическое устройство (используются также названия логический диск и логический раздел). Логическое устройство функционирует так, как если бы это был отдельный физический диск. Именно с логическими устройствами работает пользователь, обращаясь к ним по символьным именам. Операционные системы разного типа используют единое для них всех представление о раз-
делах, но создаю! на его основе логические устройства, специфиче- ские для каждого типа ОС. Так же как файловая система, с которой работает одна ОС, в общем случае нс может интерпретироваться ОС другого типа, логические устройства не могут быть использованы операционными системами разного типа. На каждом логическом устройстве может создаваться только одна файловая система. В частном случае, когда все дисковое пространство охватывается одним разделом, логическое устройство представляет физическое устройство в целом. Если диск разбит на несколько разделов, то для каждого из этих разделов может быть создано отдельное логическое устройство. Логическое устройство может быть создано и на базе не- скольких разделов, причем эти разделы не обязательно должны при- надлежать одному физическому устройству. Объединение нескольких разделов в единое логическое устройство может выполняться раз- ными способами и преследовать разные цели, основные из которых: увеличение общего объема логического раздела; повышение произ- водительности и отказоустойчивости. Примерами организации со- вместной работы нескольких дисковых разделов являются так назы- ваемые RAI D-массивы. На разных логических устройствах одного и того же физического диска могут располагаться файловые системы разного типа. На рис. 6.8 показан пример диска, разбитого на три раздела, в кото- рых установлены две файловые системы NTFS (разделы С и Е) и одна файловая система FAT (раздел D). Файловая система NTFS Файловая система FAT Файловая система NTFS С: D: Е: Рис. 6,8. Разбиение диска на разделы Все разделы одного диска имеют одинаковый размер кластеров, определенный для данного диска в результате низкоуровневого фор-
матирования. Однако в результате высокоуровневого форматирова- ния в разных разделах одного и того же диска, представленных раз- ными логическими устройствами, могут быть установлены файловые системы, в которых определены кластеры отличающихся размеров. Операционная система может поддерживать разные статусы раз- делов, особым образом отмечая разделы, которые могут быть исполь- зованы для загрузки модулей операционной системы, и разделы, в которых можно устанавливать только приложения и хранить файлы данных. Один из разделов диска помечается как загружаемый (или активный). Именно из этого раздела считывается загрузчик опера- ционной системы. 6.4.2. Физическая организация и адресаиия файла Важным компонентом физической организации файловой сис- темы является физическая организация файла, т.е. способ размеще- ния файла надиске. Основными критериями эффективности физи- ческой организации файлов являются: • скорость доступа к данным; • объем адресной информации файла; • степень фрагментированности дискового пространства; • максимально возможный размер файла. Непрерывное размещение — простейший вариант физической организации (рис. 6.9, а), при котором файлу предоставляется по- следовательность кластеров диска, образующих непрерывный участок дисковой памяти. Основным достоинством этого метода является высокая скорость доступа, так как затраты на поиск и счи- тывание кластеров файла минимальны. Также минимален объем адресной информации — достаточно хранить только номер первого кластера и объем файла. Данная физическая организация макси- мально возможный размер файла не ограничивает. Однако этот ва- риант имеет существенные недостатки, которые затрудняют его при- менимость на практике, несмотря на всю его логическую простоту. При более пристальном рассмотрении оказывается, что реализовать эту схему не так уж просто. Действительно, какого размера должна быть непрерывная область, выделяемая файлу, если файл при каждой модификации может увеличить свой размер? Еще более серьезной проблемой является фрагментация. Спустя некоторое время после создания файловой системы в результате выполнения многочис- ленных операций создания и удаления файлов пространство диска неминуемо превращается в «лоскутное одеяло», включающее боль- шое число свободных областей небольшого размера. Как всегда бы-
Рис. 6.9. Физическая организация файла: а — непрерывное размещение; б — связанный список кластеров; в — связан- ный список индексов; г — перечень номеров кластеров вает при фрагментации, суммарный объем свободной памяти может быть очень большим, а выбрать место для размещения файла цели- ком невозможно. Поэтому на практике используются методы, в ко- торых файл размещается в нескольких, в общем случае несмежных, областях диска. Следующий способ физической организации — размещение файла в виде связанного списка кластеров дисковой памяти (рис. 6 9, б). При таком способе в начале каждою кластера содер- жится указатель на следующий кластер. В этом случае адресная ин- формация минимальна: расположение файла может быть задано одним числом — номером первого кластера. В отличие от предыду- щего способа каждый кластер может быть присоединен к цепочке кластеров какого-либо файла; следовательно, фрагментация на уровне кластеров отсутствует. Файл может изменять свой размер во время своего существования, наращивая число кластеров. Недо- статком является сложность реализации доступа к произвольно за-
данному месту файла — чтобы прочитать пятый по порядку кластер файла, необходимо последовательно прочитать четыре первых клас- тера, прослеживая цепочку номеров кластеров. Кроме того, при этом способе количество данных файла, содержащихся в одном кластере, нс равно степени двойки (одно слово израсходовано на номер сле- дующего кластера), а многие программы читают данные кластерами, размер которых равен степени двойки. Популярным способом, применяемым, например, в файловой системе FAT, является использование связанного списка индексов (рис. 6.9, в). Этот способ является некоторой модификацией преды- дущего. Файлу также выделяется память в виде связанного списка кластеров. Номер первого кластера запоминается в записи каталога, где хранятся характеристики этого файла. Остальная адресная ин- формация отделена от кластеров файла. С каждым кластером диска связывается некоторый элемент — индекс Индексы располагаются в отдельной области диска — в MS DOS это таблица FAT (File Alloca- tion Table), занимающая один кластер. Когда память свободна, все индексы имеют нулевое значение. Если некоторый кластер А назна- чен некоторому файлу, то индекс этого кластера становится равным либо номеру М следующего кластера данного файла, либо принимает специальное значение, являющееся признаком того, что этот кластер является для файла последним. Индекс же предыдущего кластера файла принимает значение N, указывая на вновь назначенный кластер. При такой физической организации сохраняются все достоинства предыдущего способа: минимальность адресной информации; от- сутствие фрагментации; отсутствие проблем при изменении размера. Кроме того, данный способ обладает дополнительными преимуще- ствами. Во-первых, для доступа к произвольному кластеру файла не требуется последовательно считывать его кластеры, достаточно прочитать только секторы диска, содержащие таблицу индексов, от- считать нужное количество кластеров файла по цепочке и опреде- лить номер нужного кластера. Во-вторых, данные файла заполняют кластер целиком, а значит, имеют объем, равный степени двойки. Необходимо отметить, что при отсутствии фрагментации на уровне кластеров на диске все равно имеется определенное коли- чество областей памяти небольшого размера, которые невозможно использовать, т.е. фрагментация все же существует. Эти фрагменты представляют собой неиспользуемые части последних кластеров, назначенных файлам, поскольку объем файла в общем случае не кра- тен размеру кластера. На каждом файле в среднем теряется половина
кластера. Это потери особенно велики, когда на диске имеется боль- шое количество маленьких файлов, а кластер имеет большой размер. Размеры кластеров зависят от размера раздела и типа файловой сис- темы. Примерный диапазон, в котором может меняться размер клас- тера, составляет от 512 байт до десятков килобайт. Еще один способ задания физического расположения файла за- ключается в простом перечислении номеров кластеров, занимаемых этим файлом (рис. 6.9, г). Этот перечень и служит адресом файла. Недостаток данного способа очевиден: длина адреса зависит от раз- мера файла и для большого файла может составить значительную величину. Достоинством же является высокая скорость доступа к произвольному кластеру файла, так как здесь применяется прямая адресация, которая исключает просмотр цепочки указателей при по- иске адреса произвольного кластера файла. Фрагментаиия на уровне кластеров в этом способе также отсутствует. Последний подход с некоторыми модификациями используется в традиционных файловых системах ОС UNIX s5 и ufs. Для сокраще- ния объема адресной информации прямой способ адресации соче- тается с косвенным. В стандартной на сегодняшний день для UNIX файловой системе ufs используется следующая схема адресации кластеров файла. Для хранения адреса файла выделено 15 полей, каждое из которых со- стоит из 4 байт (рис. 6.10). Если размер файла меньше или равен 12 кластерам, то номера этих кластеров непосредственно перечи- сляются в первых 12 полях адреса. Если кластер имеет размер 8 Кбайт (максимальный размер кластера, поддерживаемого в ufs), то таким образом можно адресовать файл размером до 8192 • 12 = = 98 304 байт. Если размер файла превышает 12 кластеров, то следующее, 13-е поле содержит адрес кластера, в котором могут быть располо- жены номера следующих кластеров файла. Таким образом, 13-й эле- мент адреса используется для косвенной адресации. При размере в 8 Кбайт кластер, на который указывает 13-й элемент, может содер- жать 2048 номеров следующих кластеров данных файла и размер файла может возрасти до 8192 • (12 + 2048) = 16 875 520 байт. Если размер файла превышает 12 + 2048 = 2060 кластеров, то ис- пользуется 14-е поле, в котором находится номер кластера, содержа- щего 2048 номеров кластеров, каждый из которых хранят 2048 номе- ров кластеров данных файла. Здесь применяется уже двойная косвен- ная адресация. С ее помощью можно адресовать кластеры в файлах, содержащих до 8192 • (12 + 2048 + 20482) = 3,43766 • Ю10 байт.
Адресная информация файла Простая косвенная адресация 2048 >------„------- записей 2048 2048 Непосредственная адресация 1 (12 блоков) / Двойная косвенная адресация Рис. 6.10. Схема адресации файловой системы ufs И наконец, если файл включает более 12 + 2048 + 20482 = = 4196 364 кластеров, то используется последнее, 15-е поле для трой- ной косвенной адресации, что позволяет задать адрес файла, име- ющего следующий максимальный размер: 8192 • (12 + 2048 + 20482 + 20483) = 7,0403 • 1013 байт. Таким образом, файловая система ufs при размере кластера в 8 Кбайт поддерживает файлы, состоящие максимум из 70 трлн байт данных, хранящихся в 8 млрд кластеров. Как видно на рис. 6.10, для задания адресной информации о максимально большом файле требуется: 15 элементов по 4 байта (60 байт) в цент- ральной части адреса плюс 1 + (1 + 2048) + (1 + 2048 + 20482) = = 4 198 403 кластера в косвенной части адреса. Несмотря на огромную величину, это число составляет всего около 0,05% от объема адресуемых данных. Файловая система ufs поддерживает дисковые кластеры и мень- ших размеров, при этом максимальный размер файла будет другим. Используемая в более ранних версиях UNIX файловая система s5 имеет аналогичную схему адресации, но она рассчитана на файлы меньших размеров, поэтому в ней используется 13 адресных элемен- тов вместо 15.
Метод перечисления адресов кластеров файла задействован и в файловой системе NTFS, используемой в ОС Windows NT/2000. Здесь он дополнен достаточно естественным приемом, сокращающим объем адресной информации: адресуются не кластеры файла, а не- прерывные области, состоящие из смежных кластеров диска. Каждая такая область, называемая отрезком (run) или экстентом (extent), опи- сывается с помощью двух чисел: начального номера кластера и коли- чества кластеров в отрезке. Так как для сокращения времени опера- ции обмена ОС старается разместить файл в последовательных кла- стерах диска, то в большинстве случаев количество последовательных областей файла будет меньше количества кластеров файла и объем служебной адресной информации в NTFS сокращается по сравнению со схемой адресации файловых систем ufs/s5. Для того чтобы корректно принимать решение с выделении файлу набора кластеров, файловая система должна отслеживать ин- формацию о состоянии всех кластеров диска: свободен/занят. Эта информация может хранитьс я как отдельно от адресной информации файлов, так и вместе с ней. 6 4.3. Физическая организация FAT Как мы уже отмечали, аббревиатура FAT (file allocation table) рас- шифровывается как «таблица размещения файлов».В файловой сис- теме FAT логическое дисковое пространство любого логического диска делится на две области (рис. 6.11): системную область и об- ласть данных. |Системная область| |Область данных| Рис. 6.11. Структура логического диска с файловой системой FAT Системная область логического диска создается и инициализи- руется при форматировании, а впоследствии обновляется при ма- нипулировании файловой структурой. Область данных логического диска содержит файлы и каталоги, подчиненные корневому ката- логу. Она, в отличие от системной области, доступна через пользо- вательский интерфейс. Системная область состоит из следующих компонентов, расположенных в логическом адресном пространстве подряд:
• загрузочной записи {boot record, BR) — содержит программу началь- ной загрузки операционной системы, которая будет загружаться из этого раздела; • зарезервированных секторов (reservedsector, ResSecs); • основной копии таблицы размещения файлов (FAT1) — содержит информацию о размещении файлов и каталогов на диске; • резервной копии таблицы размещения файлов (FATZ); • корневого каталога (root directory, RDir) — занимает фиксирован- ную область размером в 32 сектора (16 Кбайт), что позволяет хра- нить 512 записей о файлах и каталогах, так как каждая запись каталога состоит из 32 байт. Область данных предназначена для размещения всех файлов и всех каталогов, хранящихся в этом разделе диска, кроме корневого каталога. Структура каталога. Корневой и некорневые каталоги имеют оди- наковую структуру. Но RDir, в отличие от других каталогов, распо- ложен в системной области логического диска, имеет ограниченный размер и не может быть фрагментированным. Каталог состоит из последовательности 32 байт элементов. Каж- дый элемент каталога описывает входящий в него файл или каталог, содержит метку тома или является свободным. Отметим, что вся слу- жебная информация о файле (каталоге), за исключением исчерпы- вающих сведений о его размещении в области данных логического диска, находится в одном из элементов того каталога, в котором он логически содержится. Сам же файл хранит только данные. Элемент каталога состоит из восьми полей (табл 6.1). Поле имени содержит имя файла (каталога), дополненное при не- обходимости пробелами справа. Код в первом байте этого поля опре- Таблица 6.1 Основные поля элемента каталога Смещение поля, байт Длина поля, байт Содержание поля 0011(0) 8 Имя файла (каталога) О8Н(8) 3 Расширение имен файла (каталога) ODH(ll) 1 Атрибуты файла ОСН(12) 10 Резерв (для будущих расширений) 16Н(22) 2 Время создания файла (каталога) 18Н(24) 2 Дата создания файла (каталога) 1АН(26) 2 Номер первого кластера файла (каталога) 1СН(28) 4 Размер файла (каталога), байт
дсляет описываемый данным элементом объект или состояние дан- ного элемента каталога. Заметим, что тип объекта здесь задается лишь частично. Для полной его идентификации привлекается и поле атрибутов. Содержимое первого байта поля имени интерпретируется следу- ющим образом: ООН — элемент каталога еще ни разу не использовался. Это обо- значает, что все последующие элементы являются пустыми, а следо- вательно, можно прекратить поиск по каталогу с уверенностью в том, что весь каталог просмотрен. Такая техника сокращает время поиска в каталогах, но элементы, по каким-либо причинам оказавшиеся размещенными после первого пустого элемента, становятся недо- ступными; 05Н — первый символ имени файла (каталога) имеет код Е5Н, т.е. является символом. Такая перекодировка используется потому, что код Е5Н применяется по другому назначению; 2ЕН — элемент каталога описывает длинный каталог (ссылка на себя). Число 2ЕН является кодом символа «точка». Если и второй байт поля имени содержит код 2ЕН. то элемент каталога описывает родительский каталог (..) длинного каталога. Остальные байты полей имени и расширения содержат пробелы; Е5Н — элемент используется файлом (каталогом), но уже осво- божден. Этот код записывается при удалении существующего файла (каталога), но больше никакие изменения в элемент каталога не вно- сится. Любое другое содержимое первого байта поля имени интерпре- тируется как код первого символа в имени файла (каталога). Поле расширения хранит расширение имени файла (реже — ката- лога), дополненное при необходимости пробелами справа (анало- гично имени). Имя и расширения можно сформировать практически из любых символов, но пользовательский интерфейс налагает свои ограни- чения Напомним, что строчные буквы при вводе автоматически перекодируются в прописные. Чтобы избежать неприятностей, ис- пользуйте для именования файлов (каталогов) только «надежные» в этом плане символы в соответствии. Используя низкоуровневые редакторы диска, можно записать в поля имени и расширения любые символы. В поле атрибутов каждый бит задает определенный атрибут файла или описывает представляемый данным элементом каталога объект. Структура этого поля показана в табл. 6.2. Если байт атрибутов со-
Таблица 6.2 Значения битов поля атрибутов Биты Маска Значение 7 6 5 4 3 2 1 0 • • • • • • • 1 01Н Файл имеет атрибут R • • • • • • 1 • 02Н Файл имеет атрибут Н • • • • • 1 • • 04Н Файл имеет атрибут S • • • • 1 • • • 08Н Элемент описывает метку том • • • 1 • • • • ЮН Элемент описывает каталог • • 1 • • • • • 20Н Файл имеет атрибут А • • • • • • • • Резерв • • • • • • • • Резерв держит код 08Н, то поля имени или расширения представляют метку тома. В случае когда в байте атрибутов записан код ЮН, считается, что данный элемент каталога описывает каталог Атрибуты имеют следующее назначение: • атрибут «архивный» (А — archive). Показывает, что файл был от- крыт программой таким образом, чтобы у нее была возможность изменить содержимое этого файла. DOS устанавливает этот разряд атрибута в состояние ON (включено) при открытии файла. Прог- раммы резервного копирования нередко устанавливают его в OFF (выключено) при выполнении резервного копирования файла. Если применяется подобная методика, то в следующую создава- емую по порядку резервную копию будут добавлены только файлы с данным разрядом, установленным в состояние ON; • атрибут каталога (D — directory). Показывает, что данный элемент каталога указывает на подкаталог, а не на файл; • атрибут тома (V — volume). Применяется только к одному элементу каталога в корневом каталоге. В нем, собственно, и хранится имя дискового тома. Этот атрибут также применяется в случае длин- ных имен файлов; • атрибут «системный» (S — system). Показывает, что файл является частью операционной системы или специально отмечен подоб- ным образом прикладной программой, что иногда делается в ка- честве составной части метода защиты от копирования; • атрибут «скрытый» (Н — hidden). Сюда откосятся, в частности, файлы с установленным в состояние ON атрибутом «системный» (S), которые не отображаются в обычном списке, выводимом по команде DIR.
• атрибут «только для чтения» (R — read only). Показывает, что дан- ный файл не подлежит изменению. Разумеется, поскольку это лишь разряд байта, хранящегося на диске, любая программа мо- жет изменить этот разряд, после чего DOS свободно разре- шила бы изменение данного файла. Этот атрибут в основном ис- пользуется для примитивной защиты от пользовательских оши- бок, т.е. он позволяет избежать неумышленного удаления или изменения ключевых файлов. Поле времени содержит время создания (последней модификации) файла или время создания каталога. Аналогично поле даты содержит дату создания (последней моди- фикации) файла или дату создания каталога. Поле со смещением 1АН содержит номер первого кластера, при- надлежащего файлу (каталогу). Список остальных кластеров хра- нится в таблице FAT. Для файлов, которым не выделено места (на- пример, для открытых и сразу закрытых файлов), это поле хранит код 0000Н. Поле размера содержит длину файла (каталога), измеряется в бай- тах. Для текстовых файлов заданная таким образом длина иногда не совпадает с реальной длиной, определяемой по первому символу EOF в файле. Напомним: это происходит потому, что для повышения быстродействия некоторые текстовые редакторы осуществляют об- мен с диском на логическом уровне не байтами (символами), а ло- гическими записями, содержащими несколько байтов. Если по- следняя логическая запись является неполной, то реальная длина файла будет меньшей, чем задано в поле размера. К неприятностям такая несогласность обычно нс приводит, так как DOS позволяет интерпретировать оба признака конца файла (переключателями /А и /В команды COPY). Ситуация, когда длина текстового файла яв- ляется большей, чем указано в элементе каталога, считается ошибоч- ной. Максимально возможный размер файла определяется DOS по содержимому FAT, т.е. исходя из наличия свободного простран- ства на диске. Таблица размещения файлов. Таблица размещения файлов явля- ется очень важной информационной структурой. Можно сказать, что она представляет собой карту (образ) области данных, в которой опи- сывается состояние каждого участка области данных. Область дан- ных разбивают на так называемые кластеры. Кластер представляет собой один или несколько смежных секторов в логическом дисковом адресном пространстве (точнее — только в области данных). В таб- лице FAT кластеры, принадлежащие одному файлу (некорневому
каталогу), связываются в цепочки. Для указания номера кластера в системе управления файлами FAT 12 используется 12-битовое слово, в FAT16 используется 16-битовое слово, следовательно, можно иметь до 216 = 65 536 кластеров (с номерами от 0 до 65 535), а в FAT32 для нумерации кластеров используется только 28 бит. Кластер — это минимальная адресуемая единица дисковой па- мяти. выделяемая файлу (или некорневому каталогу). Файл или ка- талог занимает целое число кластеров. Последний кластер при этом может быть задействован не полностью, что приведет к заметной потере дискового пространства при большом размере кластера. На дискетах кластер занимает один или два сектора, а на жестких дисках — в зависимости от объема раздела. Номер кластера всегда относится к области данных диска (про- странству, зарезервированному для файлов и подкаталогов). Первый допустимый номер кластера всегда начинается с 2. Номера кластеров соответствуют элементам таблицы размещения файлов. Логическое разбиение области данных на кластеры как совокуп- ности секторов взамен использования одиночных секторов имеет следующий смысл’ прежде всего уменьшается размер самой таблицы FAT; уменьшается возможная фрагментация файлов; ускоряется до- ступ к файлу, так как в несколько раз сокращается длина цепочек фрагментов дискового пространства, выделенных для него. Однако слишком большой размер кластера ведет к неэффектив- ному7 использованию области данных, особенно в случае большого количества маленьких файлов. Как мы только что заметили, в сред- нем на каждый файл теряется около половины кластера. Например, при размере кластера в 32 сектора (объем раздела — от 512 до 1023 Мбайт), т.е. кластер 16 Кбайт, средняя величина потерь на файл составит 8 Кбайт, и при числе файлов в несколько тысяч потери могут составлять более 100 Мбайт. Поэтому в современных файловых системах (к ним прежде всего следует отнести NTFS, FAT32 и некоторые другие поддерживаемые ОС семейства UNIX) размеры кластеров ограничиваются (обычно — от 512 байт до 4 Кбайт). В FAT32 проблема решается за счет того, что собственно сама FAT в этой файловой системе может содержать до 2’ * ютастеров. Наконец, заметим, что системы управления файлами, созданные для Windows 9х и Windows NT, могут работать с разделами размером до 4 Гбайт, на которых установлена система FAT, тогда как DOS, ес- тественно, с такими разделами работать не сможет. Достаточно наглядно идея файловой системы с использованием таблицы размещения файлов FAT проиллюстрирована рис. 6.12.
Directory Entry Начальный номер кластера 00 01 02 03 04 05 0о и7 08 04 ОА ОВ ОС 0D ОС OF 00 10 00 00 00 00 10 11 12 13 14 15 16 17 18 19 1Л 1Б IC ID IE 1F Рис. 6.12. Чтение файла с помощью FAT-таблицы Из этого рисунка видно, что файл с именем MYFILE.TXT размеща- ется, начиная с восьмого кластера. Всего файл MYFILE.TXT зани- мает 12 кластеров. Цепочка кластеров (chain) для нашего примера может быть записана следующим образом: 8, 9, ОЛ, ОВ, 15, 16, 17, 19, 1А, 1 В, IC, 1D. Кластер с номером 18 помечен специальным кодом F7 как плохой (bad), он не может быть использован для размещения данных. При форматировании обычно проверяется поверхность маг- нитного диска, и те секторы, при контрольном чтении с которых происходили ошибки, помечаются в FAT как плохие. Кластер 1D помечен кодом FF как конечный (последний в цепочке) кластер, принадлежащий данному файлу. Свободные (незанятые) кластеры помечаются кодом 00; при выделении нового кластера для записи файла берется первый свободный кластер, начиная с начала области данных. Поскольку файлы на диске изменяются — удаляются, пере- мещаются, увеличиваются или уменьшаются, то упомянутое правило выделения первого свободного кластера для новой порции данных приводит к фрагментации файлов, т е. данные одного файла могут располагаться не в смежных кластерах, а порой в очень удаленных друг от друга, образуя сложные цепочки. Естественно, что это при- водит к существенному замедлению работы с файлами. Так как FAT используется при доступе к диску очень интенсивно, она обычно загружается в ОЗУ (в буфера ввода-вывода или кэш) и остается там настолько долго, насколько это возможно. В связи с чрезвычайной важностью FAT она обычно хранится в двух идентичных экземплярах, второй из которых непосредственно следует за первым Обновляются копии FAT одновременно. Исполь- зуется же только первый экземпляр. Если он по каким-либо причи- нам окажется разрушенным, то произойдет обращение ко второму
экземпляру. Так, например, утилита проверки и восстановления фай- ловой структуры ScanDisk из ОС Windows 9х при обнаружении несо- ответствия первичной и резервной копий FAT предлагает восстано- вить главную таблицу, используя данные из копии. Файловые системы VFAT и FAT32. Одной из важнейших характе- ристик исходной FAT было использование имен файлов формата «8.3», в котором 8 символов отводится на указание имени файла и 3 символа — для расширения имени. К стандартной FAT (имеется в виду прежде всего реализация FAT 16) добавились еще две разно- видности, используемые в широко распространенных операционных системах Microsoft (конкретно — в Windows 95 и Windows NT): VFAT (виртуальная FAT) и FAT32, используемая в одной из редакций ОС Windows 95 и Windows 98. Ныне эта файловая система (FAT32) под- держивается и такими ОС, как Windows Millennium Edition, и всеми ОС семейства Windows 2000. Имеются реализации систем управления файлами для FAT32, Windows NT и ОС Linux. Файловая система VFAT впервые появилась в Windows for Work- groups 3.11 и была предназначена для выполнения файлового ввода- вывода в защищенном режиме. С выходом Windows 95 в VFAT доба- вилась поддержка длинных имен файлов (long file name, LFN). Тем не менее VFAT сохраняет совместимость с исходным вариантом FAT; это означает, что наряду с длинными именами в ней поддерживаются имена формата «8.3», а также существует специальный механизм для преобразования имен «8.3» в длинные имена, и наоборот. Именно файловая система VFAT поддерживается исходными версиями Win- dows 95, Windows NT 4. При работе с VFAT крайне важно использо- вать файловые утилиты, поддерживающие VFAT вообще и длинные имена в частности. Дело в том, что более ранние файловые утилиты DOS запросто модифицируют то, что кажется им исходной структу- рой FAT. Это может привести к потере или порче длинных имен из таблицы FAT, поддерживаемой VFAT (или FAT32). Следовательно, для томов VFAT необходимо пользоваться файловыми утилитами, которые понимают и сохраняют файловую структуру VFAT В исходной версии Windows 95 основной файловой системой была 32-разрядная VFAT. VFAT может использовать 32-разрядныс драй- веры защищенного режима или 16-разрядные драйверы реального режима. При этом элементы FAT остаются 12- или 16-разрядными, поэтому на диске используется та же структура данных, что и в пре- дыдущих реализациях FAT. VFAT обрабатывает все обращения к жесткому диску и использует 32-разрядный код для всех файловых операций с дисковыми томами.
Основными недостатками файловых систем FAT и VFAT явля- ются большие потери на кластеризацию при больших размерах ло- гического диска и ограничения на сам размер логического диска. Это привело к разработке новой реализации файловой системы с исполь- зованием той же идеи использования таблицы FAT. Поэтому в Mi- crosoft Windows 95 OEM Service Release 2 (эта версия Windows 95 часто называется Windows 95 OSR2) на смену системе VFAT пришла фай- ловая система FAT32. FAT32 является полностью самостоятельной 32-разрядной файловой системой и содержит многочисленные усо- вершенствования и дополнения по сравнению с предыдущими реа- лизациями FAT. Принципиальное отличие заключается в том, что FAT32 намного эффективнее расходует дисковое пространство. Прежде всего сис- тема FAT32 использует кластеры меньшего размера по сравнению с предыдущими версиями, которые ограничивались 65 535 класте- рами на том (соответственно, с увеличением размера диска прихо- дилось увеличивать и размер кластеров). Следовательно, даже для дисков размером до 8 Гбайт FAT32 может использовать 4-килобайт- ные кластеры. В результате по сравнению с дисками FAT 16 эконо- мится значительное дисковое пространство (в среднем 10—15%). FAT32 также может перемещать корневой каталог и использовать резервную копию FAT вместо стандартной. Расширенная загрузоч- ная запись FAT32 позволяет создавать копии критических структур данных; это повышает устойчивость дисков FAT32 к нарушениям структуры FAT по сравнению с предыдущими версиями. Корневой каталог в FAT32 представлен в виде обычной цепочки кластеров Следовательно, корневой каталог может находиться в произвольном месте диска, что снимает действовавшее ранее ограничение на раз- мер корневого каталога (512 элементов). Windows 95 OSR2 и Windows 98 могут работать и с разделами VFAT, созданными Windows NT То, что говорилось ранее об исполь- зовании файловых утилит VFAT с томами VFAT, относится и к FAT32. Поскольку прежние утилиты FAT (для FAT32 в эту кате- горию входят обе файловые системы — FAT и VFAT) могут повредить или уничтожить важную служебную информацию, для томов FAT.32 нельзя пользоваться никакими файловыми утилитами, кроме утилит FAT32. Кроме повышения емкости FAT до величины в 4 Тбайт, файловая система FAT32 вносит ряд необходимых усовершенствований в структуру корневого каталога. Предыдущие реализации требовали, чтобы вся информация корневого каталога FAT находилась в одном
дисковом кластере. При этом корневой каталог мог содержать не бо- лее 512 файлов. Необходимость представлять длинные имена и обес- печить совместимость с прежними версиями FAT привела разра- ботчиков компании «Microsoft» к компромиссному решению: для представления длинного имени они стали использовать элементы каталога, в том числе и корневого. Рассмотрим способ представления в VFAT длинного имени файла (рис. 6.13). I О [ 1 I 2 | 3 | 4 | 5 | 6 | 7 | 8 ] 9 о|11 |l ?|l з|14|l 5|lб|17|т 8|l 9ро|21 |?2|23|24|25|2б|27|?8^29|30|311 Элемент каталога для короткого имени файла (FAT 16 и FAT 12) Элемент каталога для длинного имени файла (FAT32, FAT16 и FAT32) Номер элемента | Символы 1-5 имени файла в Unicode Атрибуты Зарезервировано □ ? Символы 6-11 имени файла в Unicode 5 X э Должно быть равно нулю Символы 12 13 имени файла в Unicode 0 1 | 2 | 3 | 4 | 5 16 | 7 | 8 | 9 |10 11 121 3 14[l s| 1 б|17|18|19|20|21 |22|23j24|25 2627 28 29|30|31 Рис. 6-13. Элементы каталога для FAT, VFAT и FAT32 Первые 11 байтов элемента каталога DOS используются для хра- нения имени файла. Каждое такое имя разделяется на две части: в первых восьми байтах хранятся символы собственно имени, а в по- следних трех — символы так называемого расширения, с помощью которого реализуются механизмы предопределенных типов. Были введены соответствующие системные соглашения, и файлы опреде-
ленного типа необходимо (желательно) именовать с оговоренным расширением. Например, исполняемые файлы с расширением СОМ определяют исполняемую двоичную программу с простейшей одно- сегментной структурой. Более сложные программы имеют расшире- ние EXE. Определены расширения для большого количества типов файлов, и эти расширения используются для ассоциированного за- пуска обрабатывающих файлы программ. Если имя файла состоит менее чем из восьми символов, то в эле- менте каталога оно дополняется символами пробела, чтобы пол- ностью заполнить все восемь байт соответствующего поля. Анало- гично и расширение может содержать от нуля до трех символов. Остальные (незаполненные) позиции в элементе каталога, опреде- ляющем расширение имени файла, заполняются символами пробела. Поскольку при работе с именем файла учитываются все 11 свобод- ных мест, то необходимость в отображении точки, которая обычно вводится между именем файла и его расширением, отпадает. В эле- менте каталога она просто подразумевается. В двенадцатом байте элемента каталога хранятся атрибуты файла. Шесть из восьми указанных разрядов используются DOS. На дисках FAT 12 или FAT 16 следующие за именем десять байт не используются. Обыкновенно они заполняются нулями и счита- ются резервными значениями. А на диске с файловой системой FAT32 эти 10 байт содержат самую разную информацию о файле. При этом байт, отмеченный как «зарезервировано для NT», пред- ставляет собой, как подразумевает его название, поле, нс использу- емое в DOS или Windows 9х, но применяемое в Windows NT. Из соображений совместимости поля, которые встречаются в эле- ментах каталога для коротких имен формата FAT 12 и FAT 16, нахо- дятся на тех же местах и в элементах каталога для коротких имен формата FAF32. Остальные поля, которые встречаются только в эле- ментах каталога для коротких имен формата FAT32, соответствуют зарезервированной области длиной в 10 байт в элементах каталога для коротких имен форматов FAT 12 и FAT 16. Как видно из рис. 6.13, для длинного имени файла используется несколько элементов каталога. Таким образом, появление длинных имен фактически привело к дальнейшему уменьшению количества файлов, которые могут находиться в корневом каталоге. Поскольку длинное имя может содержать до 256 символов, всего один файл с полным длинным именем занимает до 25 элементов FAT (1 для имени 8.3 и еще 24 для самого длинного имени). Количество элемен- тов корневого каталога VFAT уменьшается до 21. Очевидно, что это
не самое изящное решение, поэтому компания «Microsoft» советует избегать длинных имен в корневых каталогах FAT при отсутствии FAT32, у которой количество элементов каталога соответственно просто увеличено Помните и о том, что длина полной файловой спецификации, включающей путь и имя файла (длинное или в фор- мате 8.3), тоже ограничивается 260 символами. FAT32 успешно справляется с проблемой длинных имен в корневом каталоге, но проблема с ограничением длины полной файловой специфика- ции остается. По этой причине «Microsoft» рекомендует ограничи- вать длинные имена 75—80 символами, чтобы оставить достаточно места для пути (180—185 символов). 6.4.4. Физическая организация s5 и ufs Файловые системы s5 (получившие название от System V, родо- вого имени нескольких версий ОС UNIX, разработанных в Bell Labs компании «AT&T») и ufs (UNIX File System) используют очень близ- кую физическую модель. Это не удивительно, так как система ufs является развитием системы s5. Файловая система ufs расширяет возможности s5 по поддержке больших дисков и файлов, а также по- вышает ее надежность. Расположение файловой системы s5 на диске иллюстрирует рис. 6.14. Раздел диска, где размещается файловая система, делится на четыре области: • загрузочный блок', 0-й блок (загрузчик) 1 -й блок (суперблок) 0 1 2 Область индексных дескрипторов Файловая система Область данных (файлов) Рис. 6.14. Расположение файловой системы s5 надиске
• суперблок (superolock) содержит самую общую информацию о файловой системе: размер файловой системы, размер области индексных дескрипторов, число индексных дескрипторов, список свободных блоков и список свободных индексных дескрипторов, а также другую административную информацию; • область индексных дескрипторов (inode list), в которой порядок рас- положения индексных дескрипторов соответствует их номерам; • область данных, в которой расположены как обычные файлы, так и файлы-каталоги, в том числе и корневой каталог: специальные файлы представлены в файловой системе только записями в со- ответствующих каталогах и индексными дескрипторами специ- ального формата, но места в области данных не занимают. Основной особенностью физической организации файловой сис- темы s5 является отделение имени файла от его характеристик, хра- нящихся в отдельной структуре, называемой индексным дескриптором (inode). Индексный дескриптор в s5 имеет размер 64 байта и содер- жит данные о типе файла, адресную информацию, привилегии до- ступа к файлу и некоторую другую информацию: • идентификатор владельца файла; • тип файла; файл может быть файлом обычного типа, каталогом, специальным файлом, а также конвейером или символьной связью; • права доступа к файлу; • временные характеристики: время последней модификации файла, время последнего обращения к файлу, время последней модификации индексного дескриптора; • число ссылок на данный индексный дескриптор, равный количе- ству псевдонимов файла; • адресная информация; • размер файла в байтах. Каждый индексный дескриптор имеет номер, который одновре- менно является уникальным именем файла. Индексные дескрипторы расположены в особой области диска в строгом соответствии со своими номерами. Соответствие между полными символьными именами файлов и их уникальными именами устанавливается с по- мощью иерархии каталогов. Система ведет список номеров свобод- ных индексных дескрипторов. При создании файла ему выделяется номер из этого списка, а при уничтожении файла номер его индекс- ного дескриптора возвращается в список. Запись о файле в каталоге состоит всего из двух полей: символь- ного имени файла и номера индексного дескриптора. Например, на рис. 6.15 показана информация, содержащаяся в каталоге /user.
Имя Номер индексного дескриптора Prog 1 23 firelights 126 doc_23.txt 51 glazing.txt 17 lambda good 147 Рис 6.15. Структура каталога в файловой системе s5 Файловая система не накладывает особых ограничений на размер корневого каталога, так как он расположен в области данных и мо- жет увеличиваться как обычный файл. Доступ к файлу осуществляется путем последовательного про- смотра всей цепочки каталогов, входящих в полное имя файла, и со- ответствующих им индексных дескрипторов. Поиск завершается после получения всех характеристик из индексного дескриптора заданного файла. Рассмотрим эту процедуру на примере файла /bin/my_shell/print, входящего в состав файловой системы, изображенной на рис. 6.16. Определение физического адреса этого файла включает следующие этапы. 1. Прежде всего просматривается корневой каталог с целью по- иска первой составляющей символьного имени — bin. Определяется номер (в данном примере — 6) индексного дескриптора каталога, входящего в корневой каталог. Адрес корневого каталога известен системе. 2. Из области индексных дескрипторов считывается дескриптор с номером 6. Начальный адрес дескриптора определяется на осно- вании известных системе номера начального сектора области ин- дексных дескрипторов и размера индексного дескриптора. Из ин- дексного дескриптора 6 определяется физический адрес каталога /bin. 3. Просматривается каталог /bin с целью поиска второй состав- ляющей символьного имени my shell. Определяется номер индекс- ного дескриптора каталога/bin/my shcll (в данном случае — 25). 4. Считывается индексный дескриптор 25, определяется физиче- ский адрес /bin/my_shcll.
Корневой каталог/ Рис. 6.16. Поиск адреса файла по его символьному имени 5. Просматривается каталог/bin/my_shell, определяется номер индексного дескриптора файла print (в данном случае — 131). 6. Из индексного дескриптора 131 определяются номера блоков данных, а также другие характеристики файла /bin/my_shell/print. Эта процедура требует в общем случае нескольких обращений к диску пропорционально числу составляющих в полном имени файла. Для уменьшения среднего времени доступа к файлу его де- скриптор копируется в специалвную системную областв оперативной памяти. Копирование индексного дескриптора входит в процедуру открытия файла Физическая организация файловой системы ufs отличается от описанной физической организации файловой системы s5 тем, что раздел состоит из повторяющейся несколвко раз последователь- ности областей «загрузчик — суперблок — блок группы цилиндров — область индексных дескрипторов» (рис. 6.17). В этих повторяющихся последовательностях областей суперблок является резервной копией основной первой копии суперблока. При повреждении основной копии супсрблока может быть использована
Загрузочный бпок Сугерблок Блок группы цилиндров Список inode Блоки данных Суперблок Блок группы цилиндров Список inode Блоки данных Рис. 6.17. Физическая организация файловой системы ufs резервная копия супсрблока. Области же блока группы цилиндров и индексных дескрипторов содержат индивидуальные для каждой последовательности значения. Блок группы цилиндров описывает количество индексных дескрипторов и блоков данных, расположен- ных на данной группе цилиндров диска. Такая группировка делается для ускорения доступа, чтобы просмотр индексных дескрипторов и данных файлов, описываемых этими дескрипторами, не приводил к слишком большим перемещениям головок диска. Кроме того, в ufs имена файлов могут иметь длину до 255 симво- лов (кодировка ASCII, по одному байту на символ), в то время как в s5 длина имени не может превышать 14 символов. 6.4.5.Физическая организация NTT’S В название файловой системы NTFS входят слова «New Technol- ogy», т.е. «новая технология». Действительно, NTFS содержит ряд значительных усовершенствований и изменений, существенно от- личающих ее от других файловых систем. С точки зрения пользова- телей, файлы по-прежнему хранятся в каталогах (часто называемых «папками» в среде Windows). Однако в NTFS в отличие от FAT работа на дисках большого объема происходит намного эффективнее; име- ются средства для ограничения в доступе к файлам и каталогам; вве- дены механизмы, существенно повышающие надежность файловой системы; сняты многие ограничения на максимальное количество дисковых секторов и/или кластеров. Основные возможности файловой системы NTFS. При проектиро- вании системы NTFS особое внимание было уделено следующим характеристикам.
Надежность. Высокопроизводительные компьютеры и системы совместного пользования (серверы) должны обладать повышенной надежностью, которая является ключевым элементом структуры и поведения NTFS. Одним из способов увеличения надежности яв- ляется введение механизма транзакций, при котором осуществляется ведение журнала, куда заносятся записи о всех выполненных файло- вых операциях. Расширенная функциональность. NTFS проектировалась с учетом возможного расширения. В ней были воплощены многие дополни- тельные возможности — усовершенствованная отказоустойчивость, эмуляция других файловых систем, мощная модель безопасности, параллельная обработка потоков данных и создание файловых атри- бутов, определяемых пользователем. Гибкость. Модель распределения дискового пространства в NTFS отличается чрезвычайной гибкостью. Размер кластера может изме- няться от 512 байт до 64 Кбайт; он представляет собой число, кратное внутреннему кванту распределения дискового пространства. NTFS также поддерживает длинные имена файлов, набор символов Uni- code и альтернативные имена формата 8.3 для совместимости с FAT NTFS превосходно справляется с обработкой больших массивов данных и достаточно хорошо проявляет себя при работе с томами объемом от 300—400 Мбайт и выше. Максимально возможные раз- меры тома (и размеры файла) составляют 16 Эбайт. Количество фай- лов в корневом и некорневом каталогах не ограничено. Поскольку в основу структуры каталогов NTFS заложена эффективная струк- тура данных, называемая «бинарным деревом», время поиска файлов в NTFS (в отличие от систем на базе FAT) не связано линейной за- висимостью с их количеством. Система NTFS также обладает определенными средствами само- восстановления. NTFS поддерживает различные механизмы про- верки целостности системы, включая ведение журналов транзакций, позволяющих воспроизвести файловые операции записи по специ- альному системному журналу. Файловая система NTFS поддерживает объектную модель без- опасности NT и рассматривает все тома, каталоги и файлы как само- стоятельные объекты. NTFS обеспечивает безопасность на уровне файлов; это означает, что права доступа к томам, каталогам и файлам могут зависеть от учетной записи пользователя и тех групп, к кото- рым он принадлежит. Каждый раз, когда пользователь обращается к объекту' файловой системы, его права доступа проверяются по спи- ску разрешений данного объекта. Если пользователь обладает доста-
точным уровнем прав, его запрос удовлетворяется; в противном слу- чае запрос отклоняется. Эта модель безопасности применяется как при локальной регистрации пользователей на компьютерах с NT, так и при удаленных сетевых запросах. Наконец, помимо огромных размеров томов и файлов, система NTFS также обладает встроенными средствами сжатия, которые можно применять к отдельным файлам, целым каталогам и даже то- мам (и впоследствии отменять или назначать их по своему усмот- рению). Структура тома с файловой системой NTFS. Одним из основных понятий, используемых при работе с NTFS, является понятие тома (volume). Возможно также создание отказоустойчивого тома, зани- мающего несколько разделов, т.е. использование RAID-технологии. Как и многие другие системы, NTFS делит все полезное дисковое пространство тома на кластеры — блоки данных, адресуемые как единицы данных. NTFS поддерживает размеры кластеров от 512 байт до 64 Кбайт; стандартом же считается кластер размером 2 или 4 Кбайт. Все дисковое пространство в NTFS делится на две неравные части (рис. 6.18). Первые 12% диска отводятся под так называемую MFT- зону — пространство, которое может занимать, увеличиваясь в раз- мере, главный служебный метафайл MFT. Запись каких-либо дан- ных в эту область невозможна. MFT-зона всегда держится пустой — это делается для того, чтобы самый главный, служебный файл (MFT) по возможности не фрагментировался при своем росте Остальные 88% тома представляют собой обычное пространство для хранения файлов. Зонэ Зон-, для размещения MFT файлов и каталогов Зона для размещения файлов и каталогов Рис. 6.18. Структура тома NTFS MFT (master file table, общая таблица файлов) представляет собой централизованный каталог всех остальных файлов диска, в том числе
и себя самого М FT поделен на записи фиксированного размера в 1 или 4 Кбайт, и каждая запись соответствует какому-либо файлу (в об- щем смысле этого слова). Первые 16 файлов носят служебный харак- тер и недоступны операционной системе — они называются мета- файлами, причем самый первый метафайл — сам М FT. Эти первые 16 элементов MFT — единственная часть диска, имеющая строго фиксированное положение. Копия этих же 16 записей хранится в се- редине тома для надежности, поскольку они очень важны. Осталь- ные части MFT-файла могут располагаться, как и любой другой файл, в произвольных местах диска — восстановить его положение можно с помощью его самого, «зацепившись» за самую основу — за первый элемент MFT. Упомянутые первые 16 файлов NTFS (метафайлы) носят служеб- ный характер; каждый из них отвечает за какой-либо аспект работы системы. Метафайлы находятся в корневом каталоге NTFS-тома Все они начинаются с символа имени «$», хотя получить какую-либо информацию о них стандартными средствами сложно. В табл. 6 3 приведены основные известные метафайлы и их назначение. Таким образом, можно узнать, например, сколько операционная система тратит на каталогизацию тома, посмотрев размер файла $MFT. Таблица 6.3 Метафайлы NTFS Имя метафайла Назначение метафайла SMFT Сам Master File Table $MFTmirr Копия первых 16 записей M FT, размещенная посере- дине тома SLogFile Файл поддержки операций журналирования S Volume Служебная информация — метка тома, версия файловой системы и т.д. SAttrDef Список стандартных атрибутов файлов на томе $. Корневой каталог $ Bitmap Карта свободного места тома $Boot Загрузочный сектор (если раздел загрузочный) $ Quota Файл, в котором записаны права пользователей на ис пользование дискового пространства (этот файл начал работать лишь в Windows 2000 с системой NTFS5.0) $ Lipcase Файл — таблица соответствия заглавных и прописных букв в именах файлов В NTFS имена файлов записыва- ются в Unicode (что составляет 65 тыс. различных сим- волов), и искать большие и малые эквиваленты в дан- ном случае — нетривиальная задача
Итак, все файлы тома упоминаются в М FT. В этой структуре хра- нится вся информация о файлах, за исключением собственно дан- ных. Имя файла, размер, положение на диске отдельных фрагментов и т.д. — все это хранится в соответствующей записи. Если для инфор- мации нс хватает одной записи MFT, то используется несколько за- писей, причем не обязательно идущих подряд. Файлы могут иметь не очень большой размер. Тогда применяется довольно удачное ре- шение: данные файла хранятся прямо в MFT, в оставшемся от ос- новных данных месте в пределах одной записи MFT. Файлы, зани- мающие сотни байт, обычно не имеют своего «физического» вопло- щения в основной файловой области — все данные такого файла хранятся в одном месте, в М FT. Все файлы на томе NTFS идентифицируются номером файла, который определяется позицией файла в MFT. Этот способ иденти- фикации файла близок к способу, используемому в файловых сис- темах s5 и ufs, где файл однозначно идентифицируется номером его записи в области индексных дескрипторов. Весь том NTFS состоит из последовательности кластеров, что от- личает эту файловую систему от рассмотренных ранее, где на кла- стеры делилась только область данных. Порядковый номер кластера в томе NTFS называется логическим номером кластера (Logical Clus- ter Number, LCN). Файл NTFS также состоит из последовательности кластеров, при этом порядковый номер кластера внутри файла на- зывается виртуальным номером кластера (Virtual Cluster Number, VCN). Базовая единица распределения дискового пространства для фай- ловой системы NTFS — непрерывная область кластеров, называемая отрезком. В качестве адреса отрезка NTFS использует логический номер его первого кластера, а также количество кластеров в от- резке к, т.е. пара (LCN, к). Таким образом, часть файла, помещенная в отрезок и начинающаяся с виртуального кластера VCN, характери- зуется адресом, состоящим из трех чисел: (VCN, LCN, к). Файл в томе с NTFS идентифицируется так называемой файловой ссылкой (File Reference), которая представляется как 64-разрядное число. Файловая ссылка состоит из номера файла, который соответ- ствует позиции его файловой записи в MFT, и номера последова- тельности. Последний увеличивается всякий раз, когда данная по- зиция в MFT используется повторно, что позволяет файловой сис- теме NTFS выполнять внутренние проверки целостности. Структура файлов NTFS. Каждый файл в NTFS представлен с по- мощью потоков (streams), т е. у него нет как таковых «просто дан-
ных», а есть «потоки». Для правильного понимания потока доста- точно указать, что один из потоков носит привычный нам смысл — данные файла. Но большинство атрибутов файла — это тоже потоки. Таким образом, получается, что базовая сущность у файла только одна — номер в MFT, а все остальное, включая и его потоки. — оп- ционально. Данный подход может эффективно использоваться, на- пример, файлу можно «прилепить» еще один поток, записав в него любые данные. В Windows 2000 таким образом записана информация об авторе и содержании файла (одна из закладок в свойствах файла, просматриваемых, например, из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами работы с файлами: наблюдаемый размер файла — это лишь размер основ- ного потока, который содержит традиционные данные Можно, к примеру, иметь файл нулевой длины, при стирании которого осво- бодится 1 Гбайт свободного места — просто потому, что какая-нибудь хитрая программа или технология «прилепила» к нему дополнитель- ный поток (альтернативные данные) такого большого размера. Но на самом деле в настоящее время потоки практически не исполь- зуются, так что опасаться подобных ситуаций не следует, хотя гипо- тетически они возможны. Просто необходимо иметь в виду, что файл в NTFS — это более глубокое понятие, чем можно себе представить, просматривая каталоги диска. Каждый файл и каталог на томе NTFS состоит из набора атрибу- тов. Важно отметить, что имя файла и его данные также рассматри- ваются как атрибуты файла, т.е. в трактовке NTFS кроме атрибутов у файла нет никаких других компонентов. Каждый атрибут файла NTFS состоит из полей: тип атрибута, длина атрибута, значение атрибута и, возможно, имя атрибута. Тип атрибута, длина и имя образуют заголовок атрибута. Имеется системный набор атрибутов, определяемых структурой тома NTFS. Системные атрибуты имеют фиксированные имена и коды их типа, а также определенный формат. Могут применяться также атрибуты, определяемые пользователями. Их имена, типы и форматы задаются исключительно пользователем. Атрибуты файлов упорядочены по убыванию кода атрибута, причем атрибут одного и того же типа может повторяться несколько раз. Существуют два способа хранения атрибутов файла — резидентное хранение в записях таблицы MFT и нерезидентное хранение вне ее, во внешних отрезках. Таким образом, резидентная часть файла состоит из резидентных атрибутов, а нерезидентная — из нерезидентных атрибутов. Сорти- ровка может осуществляться только по резидентным атрибутам.
Системный набор включает следующие атрибуты. Attribute List (список атрибутов) — список атрибутов, из которых состоит файл; содержит ссылки на номер записи MFT, где располо- жен каждый атрибут; этот редко используемый атрибут нужен только в том случае, если атрибуты файла не умещаются в основной записи и занимают дополнительные записи М FT. File Name (имя файла) — этот атрибут содержит длинное имя файла в формате Unicode, а также номер входа в таблице MFT для родительского каталога; если этот файл содержится в нескольких каталогах, то у него будет несколько атрибутов типа File Name; этот атрибут всегда должен быть резидентным. MS DOS Name (имя MS DOS) — этот атрибут содержит имя файла в формате 8.3. Version (версия) — атрибут содержит номер последней версии файла. Security Descriptor (дескриптор безопасности) — этот атрибут со- держит информацию о защите файла: список прав доступа ACL и поле аудита, которое определяет, какого рода операции над этим файлом нужно регистрировать. Volume Version (версия тома) — версия тома, используется только в системных файлах тома. Volume Name (имя тома) — имя тома. Data (данные) — содержит обычные данные файла. MFT bitmap (битовая карта MFT) — этот атрибут содержит карту использования блоков на томе. Index Root (корень индекса) — корень В-дерева, используемого для поиска файлов в каталоге. Index Allocation (размещение индекса) — нерезидентные части ин- дексного списка В-дерева. Standard Information (стандартная информация) — этот атрибут хранит всю остальную стандартную информацию о файле, которую трудно связать с каким-либо из других атрибутов файла, например время создания файла, время обновления и др. Файлы NTFS в зависимости от способа размещения делятся на небольшие, большие, очень большие и сверхбольшие. Небольшие файлы (small). Если файл имеет небольшой размер, то он может целиком располагаться внутри одной записи MFT, име- ющей, например, размер 2 Кбайт Небольшие файлы NTFS состоят, по крайней мере, из следующих атрибутов (рис. 6.19): • стандартная информация (SI — standard information); • имя файла (FN — file name);
SI I FN I Data | SD Записи MFT Рис, 6.19. Небольшой файл NTFS • данные (Data); • дескриптор безопасности (SD — security descriptor). Из-за того, что файл может иметь переменное количество атри- бутов, а также из-за переменного размера атрибутов нельзя навер- няка утверждать, что файл уместится внутри записи. Однако обычно файлы размером менее 1500 байт помещаются внутри записи MFT (размером 2 Кбайт). Большие файлы {large). Если данные файла не помещаются в одну запись MFT, то этот факт отражается в заголовке атрибута Data, ко- торый содержит признак того, что этот атрибут является нерезидент- ным, т.е. находится в отрезках вне таблицы MFT. В этом случае атри- бут Data содержит адресную информацию (LCN, VCN. к) каждого отрезка данных (рис. 6.20). Очень большие файлы {huge). Если файл настолько велик, что его атрибут данных, хранящий адреса нерезидентных отрезков данных, не помещается в одной записи, то этот атрибут помещается в другую запись MFT, а ссылка на такой атрибут помещается в основную за- пись файла (рис. 6.21). Эта ссылка содержится в атрибуте Attribute List. Сам атрибут данных по-прежнему содержит адреса нерезидент- ных отрезков данных.
Рис. 6.21. Очень большой файл NTFS Сверхбольшие файлы (extremely huge). Для сверхбольших файлов в атрибуте Attribute List можно указать несколько атрибутов, распо- ложенных в дополнительных записях MFT (рис. 6.22). Кроме того, можно использовать двойную косвенную адресацию, когда нерези- дентный атрибут будет ссылаться на другие нерезидентные атрибуты, поэтому в NTFS не может быть атрибутов слишком большой для системы длины. Каталоги NTFS. Каждый каталог NTFS представляет собой один вход в таблицу MFT, который содержит атрибут Index Root Индекс содержит список файлов, входящих в каталог. Индексы позволяют сортировать файлы для ускорения поиска, основанного на значении определенного атрибута. Обычно в файловых системах файлы сор- тируются по имени. NTFS позволяет использовать для сортировки любой атрибут, если он хранится в резидентной форме. Имеются две формы хранения списка файлов. Небольшие каталоги (small indexes). Если количество файлов в ка- талоге невелико, то список файлов может быть резидентным в за- писи в MFT, являющейся каталогом (рис. 6.23). Для резидентного хранения списка используется единственный атрибут — Index Root. Список файлов содержит значения атрибутов файла. По умолчанию это имя файла, а также номер записи MTF, содержащей начальную запись файла. Большие каталоги (large indexes). По мере того как каталог растет, список файлов может потребовать нерезидентной формы хранения. Однако начальная часть списка всегда остается резидентной в кор-
SI FN IR <a.bat, 27> <c.sys, 92> <zyx, N...> <####> SD — признак конца фаилоЕ Рис. 6.23. Небольшой каталог NTFS
невой записи каталога в таблице MFT (рис. 6.24). Имена файлов ре- зидентной части списка файлов являются узлами так называемого В-дерева (двоичного дерева). Остальные части списка файлов раз- мещаются вне MFT. Для их поиска используется специальный атри- бут Index Allocation, представляющий собой адреса отрезков, храня- щих остальные части списка файлов каталога. Одни части списков являются листьями дерева, а другие являются промежуточными уз- лами, т.е. содержат наряду с именами файлов атрибут Index Allocation, указывающий на списки файлов более низких уровней. IR <Дехе 4lexe «ltr.exe, N <####> <avia.doc, N <az.exe, N avia doc' az exe' <emax.exe, Nemaxexe> <####> IA VCN, LCN, k, VCN, LCN, k, VCN, LCN k IR <glhtm, N lh > -3 ' gl.ntrn <green.com, 3 ' green com <caw.doc, NMwdoc> <####> iR <main1.c,Nma|nlc> <zero.txt. Nzerotxt> <####> Рис. 6 24. Большой каталог NTFS Узлы двоичного дерева делят весь список файлов на несколько групп. Имя каждого файла-узла является именем последнего файла в соответствующей группе. Считается, что имена файлов сравнива- ются лексикографически, т.е. сначала принимаются во внимание коды первых символов двух сравниваемых имен; при этом имя счи- тается меныпим, если код его первого символа имеет меньшее ариф- метическое значение, при равенстве кодов первых символов сравни- ваются коды вторых символов имен и т.д. Например, файл fl.exe, являющийся первым узлом двоичного дерева, показанного на рис. 6.24, имеет имя, лексикографически большее имен avia.exe,
az.exe, emax схе, образующих первую группу списка имея ката- лога. Соответственно, файл ltr.exe имеет наибольшее имя среди всех имен второй группы, а все файлы с именами, большими ltr.exe, обра- зуют третью и последнюю группу. Поиск в каталоге уникального имени файла, которым в NTFS яв- ляется номер основной записи о файле в MFT, по его символьному имени происходит следующим образом. Сначала искомое символьное имя сравнивается с именем первого узла в резидентной части ин- декса. Если искомое имя меньше, то это означает, что его нужно ис- кать в первой нерезидентной группе, для чего из атрибута Index Alloca- tion извлекается адрес отрезка (VCNb LCN,. Kj, хранящего имена файлов первой группы. Среди имен этой группы поиск осуществля- ется прямым перебором имен и сравнением до полного совпадения всех символов искомого имени с хранящимся в каталоге именем. При совпадении из каталога извлекается номер основной записи о файле в MFT и остальные характеристики файла берутся уже оттуда. Если же искомое имя больше имени первого узла резидентной части индекса, то его сравнивают с именем второго узла, и если иско- мое имя меньше, то описанная процедура применяется ко второй нерезидентной группе имен и т.д. В результате вместо перебора большого количества имен (в худ- шем случае — всех имен каталога) выполняется сравнение с гораздо меньшим количеством имен узлов и имен в одной из групп каталога. Если одна из групп каталога становится слишком большой, то ее также делят на группы, последние имена каждой новой группы оставляют в исходном нерезидентном атрибуте Index Root, а все остальные имена новых групп переносят в новые нерезидентные атрибуты типа Index Root (на рисунке этот случай не показан). К ис- ходному нерезидентному атрибуту Index Root добавляется атрибут размещения индекса, указывающий на отрезки индекса новых групп. Если теперь при поиске искомого имени в нерезидентной части ин- декса первого уровня какое-либо сравнение показывает, что искомое имя оказывается меньше, чем одно из хранящихся там имен, то это говорит о том, что в данном атрибуте точного сравнения имени уже быть не может и нужно перейти к подгруппе имен следующего уровня дерева. 6.5. Файловые операции Файловая система ОС должна предоставлять пользователям набор операций работы с файлами, оформленный в виде системных вызо-
bob. Этот набор обычно состоит из таких системных вызовов, как creat (создать файл), read (читать из файла), write (записать в файл) и некоторых других. Чаще всего с одним и тем же файлом пользователь выполняет не одну операцию, а последовательность операций. Например, при работе текстового редактора с файлом, в котором содержится неко- торый документ, пользователь обычно считывает несколько страниц текста, редактирует эти данные и записывает их на место считанных, а затем считывает страницы из другой области файла и т п После большого количества операций чтения и записи пользователь завер- шает работу с данным файлом и переходит к другому. Какие бы операции ни выполнялись над файлом, ОС необходимо выполнить ряд универсальных для всех операций действий: а) по символьному имени файла найти его характеристики, ко- торые хранятся в файловой системе на диске; б) скопировать характеристики файла в оперативную память, так как только таким образом программный код может их использовать; в) на основании характеристик файла проверить права пользо- вателя на выполнение запрошенной операции (чтение, запись, уда- ление, просмотр атрибутов файла); г) очистить область памяти, отведенную под временное хранение характеристик файла. Кроме того, каждая операция включает ряд уникальных для нее действий, например чтение определенного набора кластеров диска, удаление файла и т.п. Операционная система может выполнять последовательность действий над файлом двумя способами (рис. 6.25): • для каждой операции выполняются как универсальные, так и уникальные действия. Такая схема иногда называется схемой без запоминания состояния операций (stateless) (рис. 6.25, а); • все универсальные действия выполняются в начале и конце по- следовательности операций, а для каждой промежуточной опера- ции выполняются только уникальные действия (рис. 6.25, б). а) б) open readl close open read2 close open read3 close open read! read2 геааЗ close --------> t t Рис. 6.25. Два способа выполнения файловых операций
Подавляющее большинство файловых систем поддерживает второй способ организации файловых операций как более экономичный и быстрый. Первый способ обладает одним преимуществом — он бо- лее устойчив к сбоям в работе системы, так как каждая операция яв- ляется самодостаточной и не зависит от результата предыдущей. По- этому первый способ иногда применяется в распределенных сетевых файловых системах (например, в Network File System, NFS компании «Sun»), когда сбои из-за потерь пакетов или отказов одного из сетевых узлов более вероятны, чем при локальном доступе к файлам. При втором способе в файловой системе вводятся два специаль- ных системных вызова: open — открытие файла и close — закрытие файла. Системный вызов открытия файла open выполняется перед нача- лом любой последовательности операций с файлом, а вызов закры- тия файла close — после окончания работы с файлом. Основной за- дачей вызова open является преобразование символьного имени файла в его уникальное числовое имя, копирование характеристик файла из дисковой области в буфер оперативной памяти и проверка прав пользователя на выполнение запрошенной операции. Вызов close освобождает буфер с характеристиками файла и делает невоз- можным продолжение операций с файлом без его повторного откры- тия. 6.6. Контроль доступа к файлам Файлы — это частный, хотя и самый популярный, вид разделя- емых ресурсов, доступ к которым операционная система должна контролировать. Существуют и другие виды ресурсов, с которыми пользователи работают в режиме совместного использования. Прежде всего это различные внешние устройства: принтеры, мо- демы, графопостроители и т.п. Область памяти, используемая для обмена данными между процессами, также является примером раз- деляемого ресурса. Да и сами процессы в некоторых случаях высту- пают в этой роли, например когда пользователи ОС посылают про- цессам сигналы, на которые процесс должен реагировать. Во всех этих случаях действует общая схема: пользователи пыта- ются выполнить с разделяемым ресурсом определенные операции, а ОС должна решать, имеют ли пользователи на это право. Пользо- ватели являются субъектами доступа, а разделяемые ресурсы — объ- ектами. Пользователь осуществляет доступ к объектам операцион- ной системы не непосредственно, а с помощью прикладных лроцес
сов, которые запускаются от его имени. Для каждого типа объектов существует набор операций, которые с ними можно выполнять. На- пример. для файлов это операции чтения, записи, удаления, выпол- нения; для принтера — перезапуск, очистка очереди документов, приостановка печати документа и т.д. Система контроля доступа ОС должна предоставлять средства для задания прав пользователей по отношению к объектам дифференцированно по операциям, на- пример, пользователю могут быть разрешены операции чтения и вы- полнения файла, а операция удаления — запрещена. Вс многих операционных системах реализованы механизмы, ко- торые позволяют управлять доступом к объектам различного типа с единых позиций. Так, представление устройств ввода-вывода в виде специальных файлов в операционных системах UN IX является при- мером такого подхода: в этом случае при доступе к устройствам ис- пользуются те же атрибуты безопасности и алгоритмы, что и при доступе к обычным файлам и каталогам. Еще дальше продвинулась в этом направлении операционная система Windows NT. В ней ис- пользуется унифицированная структура — объект безопасности, ко- торая создается не только для файлов и внешних устройств, но и для любых разделяемых ресурсов — секций. Это позволяет использовать в Windows NT для контроля доступа к ресурсам любого вида общий модуль ядра — менеджер безопасности. В качестве субъектов доступа могут выступать как отдельные пользователи, так и группы пользователей. Определение индивиду- альных прав доступа для каждого пользователя позволяет макси- мально гибко задать политику расходования разделяемых ресурсов в вычислительной системе. Однако этот способ приводит в больших системах к чрезмерной загрузке администратора рутинной работой по повторению одних и тех же операций для пользователей с одина- ковыми правами. Объединение таких пользователей в группу и зада- ние прав доступа в целом для группы является одним из основных приемов администрирования в больших системах. У каждого объекта доступа существует владелец. Владельцем мо- жет быть как отдельный пользователь, так и группа пользователей. Владелец объекта имеет право выполнять с ним любые допустимые для данного объекта операции. Во многих операционных системах существует особый пользователь (superuser, root, administrator), кото- рый имеет все права по отношению к любым объектам системы, не обязательно являясь их владельцем Под таким именем работает администратор системы, которому необходим полный доступ ко всем файлам и устройствам для управления политикой доступа.
Различают два основных подхода к определению прав доступа. Избирательный доступ имеет место, когда для каждого объекта сам владелец может определить допустимые операции с объектами. Этот подход называется также произвольным (от discretionary — пре- доставленный на собственное усмотрение) доступом, так как позво- ляет администратору и владельцам объектов определить права до- ступа произвольным образом, по их желанию. Между пользовате- лями и группами пользователей в системах с избирательным достутюм нет жестких иерархических взаимоотношений, т.е. взаимо- отношений, которые определены по умолчанию и которые нельзя изменить. Исключение делается только для администратора, по умолчанию наделяемого всеми правами. Мандатный доступ (от mandatory — обязательный, принудитель- ный) — это такой подход к определению прав доступа, при котором система наделяет пользователя определенными правами по отноше- нию к каждому разделяемому ресурсу (в данном случае файлу) в за- висимости от того, к какой группе пользователь отнесен. От имени системы выступает администратор, а владельцы объектов лишены возможности управлять доступом к ним по своему усмотрению. Все группы пользователей в такой системе образуют строгую иерархию, причем каждая группа пользуется всеми правами группы более низ- кого уровня иерархии, к которым добавляются права данного уровня. Членам какой-либо группы не разрешается предоставлять свои права членам групп более низких уровней иерархии. Мандатный способ доступа близок к схемам, применяемым для доступа к секретным документам: пользователь может входить в одну из групп, отлича- ющихся правом на доступ к документам с соответствующим грифом секретности, например «для служебного пользования», «секретно», «совершенно секретно» и «государственная тайна». При этом поль- зователи группы «совершенно секретно» имеют право работать с до- кументами «секретно» и «для служебного пользования», так как эти виды доступа разрешены для более низких в иерархии групп. Однако сами пользователи нс распоряжаются правами доступа — этой воз- можностью наделен только особый чиновник учреждения. Мандатные системы доступа считаются более надежными, но ме- нее гибкими, обычно они применяются в специализированных вы- числительных системах с повышенными требованиями к защите информации. В универсальных системах используются, как правило, избирательные методы доступа.
Выводы Основными задачами подсистемы ввода-вывода являются: • организация параллельной работы процессора и устройств ввода- вывода при обеспечении приемлемого уровня реакции каждого драйвера и минимизации общей загрузки процессора; • согласование скоростей работы процессора, оперативной памяти и устройств вБОда-вызода; • разделение устройств ввода-вывода между процессами; • обеспечение удобного логического интерфейса к устройствам ввода-вывода. Подсистема ввода-вывода обычно имеет ярко выраженную мно- гослойную структуру, которая помогает объединить большое коли- чество разнотипных драйверов в систему с общим интерфейсом. Драйверы делятся на низкоуровневые, непосредственно управля- ющие работой контроллеров внешних устройств, и высокоуровне- вые, обеспечивающие логический интерфейс к устройствам, напри- мер драйверы файловых систем. Для координации работы драйверов в подсистеме ввода-вывода может выделяться особый модуль, называемый менеджером ввода- вывода. Файл — это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Основными целями использования файлов являются: долговременное и надежное хранение информации, а также совместный доступ к данным. Файловая система представляет собой комплекс системных прог- раммных средств, реализующих различные операции с файлами, таких как создание, уничтожение, чтение, запись, именование и по- иск файлов. Под файловой системой понимают также набор всех файлов и служебных структур данных, хранящихся на внешнем устройстве. Кроме обычных файлов ОС, как правило, поддерживает такие типы файлов, как каталоги и специальные файлы. Специальный файл является универсальной моделью устройства ввода-вывода, представляя его для остальной части операционной системы и прикладных процессов в виде неструктурированного на- бора байт, т.е. в виде обычного файла. Современные файловые системы имеют иерархическую струк- туру, упрощающую именование файлов и их поиск. Физическая организация файловой системы подразумевает спо- собы размещения и адресации отдельных частей файлов в разделах
и секторах дисковой памяти, а также способы организации служеб- ной информации, описывающей размещение файлов и их атрибуты. Механизм контроля доступа к файлам позволяет администрато- рам многопользовательских ОС задавать для отдельных пользовате- лей и групп пользователей набор операций, которые им разрешается выполнять над отдельным файлом или группой файлов, объединен- ных в каталог Управление доступом в ОС осуществляется на основе одного из двух базовых подходов- избирательного доступа, когда владелец файла самостоятельно может определить права доступа к файлу, и мандатного доступа, при котором права доступа определяются членством пользователя в определенной группе и пользователь не может их произвольно изменять или делегировать. Вопросы для самоконтроля 1. За счет каких устройств удается распараллелить ввод-вывод даже в од- нопроцессорных системах? 2. Какие функции выполняет менеджер ввода-вывода? 3. Какие два типа ресурсов, связанных с диском, требуется выделить про- цессу, чтобы он выполнил запись данных на диск? 4. Каким из двух типов драйверов — блок-ориентированным или байт- ориентированным — обслуживается диск? 5. С какой целью в некоторых файловых системах характеристики файла отделяются от его имени? 6. Какие программные компоненты поддерживают структуру файла в тех ОС, где файл представлен последовательностью байт? 7. С какого каталога начинается «раскрутка» полного имени файла? 8. Операционная система выделяет файлам пространство на диске: а) секторами; б) дорожками; в) кластерами; г) цилиндрами. 9. При каких условиях можно автоматически гарантированно восстано- вить в файловой системе FAT удаленный файл? 10. Сформулируйте основную цель введения в ОС системного вызова open. 11. В какой из типов систем управления доступом — избирательной или мандатной — пользователю предоставляется большая свобода дей- ствий? 12. Что означает термин «spooling» и что означает термин «swapping»? 13. Что такое синхронный и асинхронный ввод-вывод? 14. Расскажите о кэш ировании операций ввода- вывода при работе с нако- пителям и на магнитных дисках. 15. Что такое файловая система?
16. Что обеспечивает использование той или иной файловой системы? 17. Какие файловые системы, используемые в ОС для ПК, вы знаете? 18. Опишите структуру магнитного диска (разбиение дисков на разделы). 19. Сколько (и каких) разделов может быть на магнитном диске? 20 Объясните обшие принципы файловой системы FAT. 21. Что такое кластер, от чего зависит его размер? 22. Сравните файловые системы FAT 16 и FAT32. В чем заключаются их достоинства и недостатки? 23. Что означает «журналирование» файловых операций? Что это дает?
Глава 7 ДИСКОВАЯ ОПЕРАЦИОННАЯ СИСТЕМА MS DOS Первым представителем семейства дисковых операционных систем была операционная система фирмы «Microsoft», разработан- ная в 1981 г. по заказу фирмы «1ВМ». Эта дисковая операционная система получила название MS DOS (Microsoft Disk Operating System) и поставлялась с персональными компьютерами (ПК) фирмы «1ВМ». Операционная система MS DOS — наиболее известная, но далеко не единственная представительница DOS. Другие операционные системы этого семейства можно разделить на две группы: • системы, основной целью при создании которых было стремле- ние создать конкуренцию фирме «Microsoft» и получить часть рынка операционных систем; • системы, ориентированные на ПК конкретных производителей. Среди операционных систем первой группы можно выделить: • PC DOS (Personal Computer Disk Operating System), разработчик — корпорация «IBM»; • DR DOS (Digital Research Disk Operating System), разработчик — фирма «Digital Research»; • Novell DOS7, разработчик — фирма «Novell» (дальнейшее разви- тие DR DOS). Операционные системы второй группы создают производители ПК путем модернизации системы MS DOS Типичным представите- лем таких систем является Compad DOS. Мыв этой главе будем говорить в основном о версиях MS DOS6.2/6.22. 7.1 Принципы построения и функционирования MS DOS 7.1.1. Структура MS DOS В состав MS DOS (в дальнейшем будем называть просто DOS) входят следующие компоненты (рис. 7.1): • BIOS (Basic Input/' Output System) — базовая система ввода-вывода;
Пользовательский интерфейс DOS MS DOS Shell Cl Инструментальные средства Утилиты ВМ DOS ЕМ BIOS Внешние драйверы BIOS Аппаратура ПК __ Программный /_интерфейс DOS / веэхне-о уровня Программный интерфейс DOS Поограммный интерфейс DOS нижнего уровня (функции BIOS) Рис. 7.1. Структура DOS Примечание. Компоненты MSB и SB на рисунке не показаны, так как при работе DOS они не используются. • NSB (Non- System Bootstrap) — внесистемный загрузчик; • SB (System Bootstrap) — системный загрузчик; • ЕМ BIOS (Extension Module BIOS) — модуль расширения BIOS; • внешние (устанавливаемые) драйверы устройств; • ВМ DOS (Basic Module DOS) — базовый модуль DOS; • CI (Command Interpreter) — интерпретатор команд или команд- ный процессор; • утилиты DOS; • оболочка MS-DOS Shell (факультативно); • инструментальные средства. В состав стандартной поставки DOS не входят BIOS и NSB, так как BIOS находится в ПЗУ каждого ПК, a NSB размещается на жестком диске ПК и они могут рассматриваться как компоненты любой другой операционной системы, запускаемой на ПК. В то же время они используются и работают и в DOS, поэтому их можно счи- тать частью DOS.
Все компоненты DOS, исключая BIOS, размещены на одном или нескольких магнитных дисках в специальных областях и файлах. Один из дисков обеспечивает занесение DOS в память П К и запуск ее в работу. Этот процесс называется загрузкой DOS, а диск с кото- рого возможна загрузка системы, называется системным. Рассмотрим более подробно назначение каждого из перечис- ленных компонентов. BIOS. BIOS реализует наиболее простые и универсальные функции DOS по управлению стандартными (основными) перифе- рийными устройствами (ПУ), в частности по организации ввода-вы- вода. BIOS освобождает обращающиеся к нему программы и другие компоненты DOS от учета особенностей и деталей управления тем или иным ПУ. Выделение BIOS в отдельный компонент позволяет «скрыть» архитектурные особенности конкретной модели ПК и обес- печить независимость программного обеспечения от ПУ. BIOS содержит: • драйверы стандартных ПУ; • тестовые программы; • программу начальной загрузки. Драйверы выполняют следующие основные функции: • принимают запросы на обращение к ПУ: • преобразуют запросы в команды управления устройствами с уче- том всех их особенностей работы в реальном масштабе времени; • обрабатывают прерывания от обслуживаемых ПУ. Программа начальной загрузки системонезависима и в принципе может запускать в работу' любую операционную систему на данном ПК, по этой причине она еще называется первичным загрузчиком. Доступ к BIOS осуществляется, главным образом, через аппарат прерываний. BIOS совместно с ЕМ BIOS обрабатывает прерывания низкого уровня (услуги BIOS считаются низкоуровневыми). NSB. Обеспечивает загрузку с диска одной из отмеченных специ- альным образом операционных систем. NSB является вторичным загрузчиком. SB. Ориентирован строго на DOS и способен обеспечивать загрузку только данной системы Он имеется на каждом диске, подготовленном для работы в среде DOS, даже если диск не является системным. Примечание. Все три загрузчика считываются в память и выпол- няются строго последовательно. Если загрузка DOS производится с дискеты, а не с жесткого диска, то первичный загрузчик считывает непосредственно SB (System bootstrap — системный загрузчик) и пе- редаст ему управление.
EM BIOS. EM BIOS в процессе функционирования DOS является надстройкой над BIOS, модифицируя и/или дополняя ее возмож- ности. При загрузке DOS данным модулем обеспечивается возможность как логической замены драйверов, хранящихся в BIOS, так и под- ключения новых драйверов. Необходимость в этом появляется при изменении конфигурации ПУ и при потребности использовать ПУ нестандартным образом. Драйверы могут находиться как внутри ЕМ BIOS, так и вне его, в отдельных файлах. В первом случае они назы- ваются внутренними (основными), а во втором — внешними (устанав- ливаемыми). Внутренние драйверы подключаются к системе при загрузке DOS автоматически, а внешние — по указаниям в файле конфигурации системы CONFIG.SYS. Исключение составляет драйвер DBLSPACE. BIN, обслуживающий сжатые логические диски, который подклю- чается к системе автоматически (при условии, что он обнаружен), причем до обработки файла CONFIG.SYS. Если файл CONFIG.SYS отсутствует, то никакие внешние драй- веры, за исключением вышеупомянутого, к системе не подключа- ются, а параметры DOS устанавливаются по умолчанию. ВМ DOS. ЕМ DOS — это центральный элемент DOS, реализу- ющий основные функции операционной системы — управление ре- сурсами П К и выполнением программ. Управление ПУ осуществля- ется на более высоком уровне — на основе организации обращения к драйверам. ВМ DOS также управляет и организует работу файловой системы компьютера. Основу ВМ DOS составляют обработчики прерываний верхнего уровня. Обращение к ВМ DOS возможно только через механизм пре- рываний. Именно прерывания верхнего уровня выдают большинство программ, работающих под управлением DOS. Обработчики преры- ваний, в свою очередь, могут генерировать прерывания нижнего уровня. Примечание. Компоненты подсистемы ввода-вывода, загружа- емые с диска, и ВМ DOS в процессе работы системы постоянно на- ходятся в оперативной памяти ПК (резидентно). CI. С1 отвечает в основном за поддержку пользовательского ин- терфейса DOS. Пользователь общается с системой путем передачи ей команд, которые она в состоянии интерпретировать В файл автозапуска AUTOEXEC.BAT, исполняемый в процессе загрузки, включают ко- манды DOS и запросы на выполнение программ, которые пользова-
тель должен регулярно выдавать после запуска DOS. Если файл AUTOEXEC.BAT отсутствует, то СТ выдает запрос на установку даты и времени. CI состоит из двух модулей — резидентного и транзитного. Рези- дентный модуль хранится после запуска DOS в оперативной памяти ПК постоянно и включает обработчики трех важных прерываний, а также код подзагрузки транзитного модуля CL Транзитный модуль может удаляться из оперативной памяти П К, если его место займет любая исполняемая программа, а затем вос- станавливаться путем считывания с диска. Этот модуль содержит исполнитель внутренних команд DOS и загрузчик программ в опе- ративную память для их исполнения. Утилиты. Это обслуживающие программы, которые предостав- ляют пользователю сервисные услуги. Большая часть утилит содер- жит внешние команды DOS, реализуемые нс CI, а отдельной прог- раммой — утилитой. Оболочка MS DOS Shell. Это надстройка над CI, внешне напоми- нающая Windows, которая упрощает работу пользователя в среде DOS и предоставляет ему ряд дополнительных возможностей. Инструментальные средства DOS. К инструментальным средствам DOS принадлежат. • система программирования MS DOS QBASIC (Quick Basic); • отладчик Debug, позволяющий тестировать и отлаживать испол- няемые файлы; • простейший текстовый редактор MS DOS Editor, обеспечива- ющий подготовку исходных программ. Основные функции и место расположения компонентов DOS приведены в табл. 7.1. 7.1.2. Структура системного диска Компоненты DOS хранятся на системном диске в файлах с заре- зервированными составными именами (за исключением SB). На рис. 7.2. представлены только те файлы, на размещение которых имеются достаточно жесткие ограничения. Тем не менее не все из этих файлов являются принципиально необходимыми для функ- ционирования DOS. SB содержится в стартовом секторе системного диска, т.е. в самом первом его секторе и его местоположение жестко задано и изменено быть не может. ЕМ BIOS хранится в файле TO.SYS, который должен размещаться на системном диске первым и первым же входить в корневой каталог.
Функции и местонахождение компонентов DOS Компонент Местонахождение Функции на этапе загрузки DOS функционирования DOS BIOS ПЗУ Тестирование обо- рудования ПК Считывание в память NSB Запуск NSB Управление стан- дартными ПУ NSB Стартовый (на- чальный) сектор физического жест- кого диска Считывание в память SB: Запуск SB Не используется SB Стартовый сектор каждого логиче- ского диска Считывание в па- мять ЕМ BIOS иВМ DOS Запуск ЕМ BIOS Не используется ЕМ BIOS Файл IO.SYS Определение со- стояния оборудова- ния и инициализа- ция включенных ПУ Конфигурирование системы по указа- ниям в файле CONFIG.SYS Запуск ВМ DOS Организация интер- фейса с BIOS Расширение воз- можностей BIOS Внешние драйверы устройств Отдельные файлы Не используется Управление нестан- дартными ПУ Управление стан- дартными ПУ не- стандартным спосо- бом BMDOS Файл MSDOS.SYS Считывание в па- мять CI Запуск С1 Управление ресур- сами П К и выполня- емыми программами С1 Файл COMMAND.COM Выполнение файла AUTOEXEC.BAT Прием команд DOS с клавиатуры Выполнение внут- ренних команд Выполнение ко- мандных файлов
Окончание табл. 7.1 Компонент М естонахождение Функции на этапе загрузки DOS функционирования DOS Загрузка программ в память для выпол- нения Утилиты Отдельные файлы или группы фай- лов Не используется Выполнение внешних команд DOS Реализация сер- висных услуг MS DOS Shell Файлы DOSS*.* Не используется Повышение уровня пользовательского интерфейса Предоставление пользователю до- полнительных услуг Инстру- менталь- ные сред- ства Отдельные файлы или группы фай- лов Не используется Разработка прог- рамм Подготовка простых текстовых докумен- тов ВМ DOS хранится в файле MSDOS.SYS, который должен быть размещен сразу вслед за файлом с ЕМ BIOS и входить в корневой каталог вторым. Фрагментация двух упомянутых файлов раньше не допускалась, было множество ограничений на их размещение, связанных с необ- ходимостью упрощения SB, который должен поместиться в 512 байт первого сектора. Теперь, в последних версиях DOS, эти ограничения сняты и эти два упомянутых системных файла могут находиться на системном диске где угодно и быть фрагментированными, но все же должны регистрироваться на первых двух позициях корне- вого каталога. Тем не менее полезно соблюсти все перечисленные выше ограничения, чтобы загрузка DOS выполнялась быстрее. Файлы с ЕМ BIOS и ВМ DOS имеют атрибуты R, II и 5. CIнаходится в файле COMMAND.COM, который должен содер- жаться в корневом каталоге системного диска, но на любой позиции и может занимать любую область логического дискового пространства. Если предпринять специальные меры (посредством команды конфи- гурирования системы SHELL =), то файл COMMAND.COM с CI можно «спрятать» в любом каталоге, в том числе и на другом диске.
Стартовый сектор SB FAT1 ГАТ 2 Корневой каталог Системная область системного диска IO.SYS MSDOS.SYS COMMAND.COM CONFIG.SYS AUTOEXEC ВАТ ЕМ BIOS ВМ DOS Файл конфигурации Область дачных системного диска Файл автозапуска Рис. 7.2. Структура системного диска Все перечисленные выше компоненты являются обязательными (без них загрузка невозможна). Файлы конфигурации системы и автозапуска имеют имена CON- FIG.SYS и AUTOEXEC.BAT соответственно и могут быть размешены только в корневом каталоге системного диска, но без каких-либо дополнительных ограничений; эти файлы могут и отсутствовать, но операционная система будет работать. Рассмотренную структуру системного диска формируют соответ- ствующие команды DOS, которые будут описаны ниже.
7.1.3. Загрузка и перезагрузка DOS Под загрузкой программы понимается размещение ее в ОЗУ для дальнейшего исполнения. Функцию загрузки выполняет спе- циальная программа, называемая загрузчиком В случае загрузки ОС дело обстоит несколько иначе, и вот почему: ОС является первичным программным продуктом в том смысле, что ее загрузкой и запуском на выполнение никакая другая программа не управляет. Поэтому ОС должна сама себя загружать, возможно, после небольшого «толчка» извне, а процедура загрузки должна включать запуск ОС в работу, т.е ее активизацию для управления ресурсами компьютера. Последовательность основных этапов загрузки DOS в случае, когда не возникает никаких нештатных ситуаций, представлена на рис. 7.3. Рис. 7.3. Процесс загрузки DOS
Опишем эту процедуру более подробно и обратим внимание на ситуации, при возникновении которых нормальный ход загрузки может быть нарушен, а от пользователя требуются определенные действия. Загрузка DOS начинается автоматически после включения питания ПК. Включение питания системного блока приводит к аппаратной передаче управления на программу тестирования (проверки работо- способности) оборудования, находящуюся в BIOS. Тестированию подлежат все устройства ПК, на которые подано электропитание. Оно сопровождается миганием индикаторов на ПУ и подачей звуко- вых сигналов На экране дисплея наблюдается возрастающая после- довательность чисел, быстро сменяющих друг друга. Таким образом отражаются результаты тестирования ОЗУ. Если ОЗУ функционирует нормально, то после каждого появившегося на экране числа, опре- деляющего объем проверенной области ОЗУ в Кбайт, выводится со- отве"ствующее сообщение (ОК — сокращение от английского О'Key, Passed и т и.). Когда в работе оборудования П К выявлены нарушения, на экран дисплея выдается идентифицирующее ошибку сообщение, включа- ющее код ошибки. Если ошибка некритическая (причиной может быть сбой, а не отказ оборудования), то пользователю предоставля- ется возможность возобновить процесс загрузки, начиная с тестиро- вания, нажав клавишу F1 на клавиатуре, о чем информирует сообще- ние на экране дисплея. В случае критической неисправности (отказ, не дающий возможности продолжить работу) процесс загрузки пре- кращается с выдачей на экран соответствующего сообщения. После включения питания ПК, но до окончания тестирования оборудования пользователь, желающий осуществить загрузку DOS с дискеты или не имеющий другой возможности, должен установить системную дискету в привод с именем А. Загрузка DOS с FDD осу- ществляется в следующих случаях: • когда ПК не укомплектована HDD; • когда HDD имеется, но требуется восстановить разрушенную по какой-либо причине систему или удалить компьютерные ви- русы. После успешного завершения тестирования оборудования ПК инициализируются векторы прерываний нижнего уровня таким образом, что при их возникновении будут выбираться обработчики из BIOS, вслед за чем управление передается на программу началь- ной загрузки в BIOS. Программа начальной загрузки обращается к дисководу А и, если в него установлена дискета, считывает в ОЗУ
SB, хранящийся в сс стартовом секторе (заметим, что SB имеется в стартовом секторе каждого диска, отформатированного средствами DOS, с тем чтобы при необходимости выдать сообщение об отсут- ствии системы на диске, как описано ниже). Если же дискета в при- воде А отсутствует, то осуществляется попытка загрузить SB с сис- темного логического диска в активном разделе жесткого диска (ко- нечно. при наличии последнего). Предположим, что SB считан в ОЗУ. Дальнейшая загрузка DOS продолжается с того диска, из стартового сектора которого SB про- читан (дисковод А для гибкого диска и дисковод С — для жесткого). После занесения SB в ОЗУ программа начальной загрузки пере- дает на него управление, прекращая свою работу. SB проверяет наличие на диске файлов с ЕМ BIOS и ВМ DOS. Если они находятся на своем месте и правильно помещены в корне- вой каталог системного диска, то эти модули загружаются в ОЗУ и управление получает первый из них. В противном случае SB выдает на экран следующее сообщение об ошибке (в скобках под ним при- веден перевод на русский язык): Non-syste.il disk or disk error Replace and strike any key when ready (Несистемный циск или сшибка на циске. Замените диск и затем налмите любую клавишу) Появление этого сообщения свидетельствует о разрушении ин- формации на диске или случайной попытке загрузки с действительно несистемного диска. При получении такого сообщения для поме- щенной в привод А дискеты пользователю следует: • установить в привод А действительно системную дискету, если требовалось загрузить DOS с гибкого диска; • открыть защелку FDD, если требовалось загрузить DOS с жест- кого диска. После этого достаточно нажать на клавиатуре любую алфавитно- цифровую клавишу, клавишу пробела или клавишу Enter (Ввод) для продолжения процесса загрузки DOS. Если же сообщение о несистемном диске появилось для винче- стера, то пользователю ничего не остается, как перезагрузить DOS с дискеты и выяснить причину отказа жесткого диска Получив управление, ЕМ BIOS выполняет нижеприведенные действия: 1) определяет состояние оборудования и инициализирует (уста- навливает в исходное состояние) включенные ПУ;
2) обрабатывает файл конфигурации CONFIG.SYS (если он, ко- нечно, имеется) и осуществляет конфигурирование DOS, загружая в ОЗУ и подключая к системе указанные внешние драйверы, а также устанавливая параметры системы; если файл CONFIG.SYS отсут- ствует, то никакие внешние драйверы не подключаются, а параметры DOS устанавливаются по умолчанию; 3) инициализирует (устанавливает) и переустанавливает некото- рые векторы прерываний нижнего уровня; 4) передает управление на ВМ DOS. ВМ DOS продолжает загрузку системы, реализуя следующие функции: 1) инициализирует свои внутренние таблицы; 2) инициализирует векторы обрабатываемых им прерываний верхнего уровня; 3) загружает в ОЗУ CI и передает на него управление. Получив управление, CI: 1) инициализирует три вектора прерываний, которые он обраба- тывает; 2) считывает, обрабатывает и организует выполнение файла ав- тозапуска AUTOEXEC. ВАТ; 3) если этот файл отсутствует, то CI последовательно выдает за- просы на установку даты и текущего времени, на которые допуска- ется ответить просто нажатиями клавиши Enter. С помощью файла AUTOEXEC.BAT можно автоматически вы- полнять команды DOS и программы для создания необходимой вам операционной среды. Загрузка системы завершается выдачей на экран дисплея пригла- шения (подсказки) DOS в виде А>_ или С>_ Подчеркиванием здесь обозначен курсор, Первое приглашение появляется в случае загрузки с дискеты, а второе — при загрузке с жесткого диска. Буква в приглашении ин- формирует пользователя об имени текущего дисковода. Приглашение DOS может иметь и другой вид (если предпринимаются опреде- ленные действия в файле AUTOEXEC ВАТ), а может и вообще не по- явиться (если из файла AUTOEXEC ВАТ запускается интерактивный, программный продукт) В последнем случае вы сразу попадете в его среду. В ответ на приглашение DOS можно вводить с клавиатуры ко- манды и запускать на выполнение различные программы.
Сделаем два замечания: • последовательность выдаваемых на экран дисплея сообщений во время загрузки DOS зависит от ее версии, а также от содержи- мого файлов CONFIG.SYS и AUTOEXEC.BAT; • во время обработки файла AUTO EXEC. ВАТ модулем инициали- зации CI и выполнения этого файла возможно переназначение имен поблочным логическим устройствам вследствие того, что резидентные программы-драйверы, указанные в AUTOEXEC. ВАТ, могуч обладать жесткой привязкой к именам, уже выделен- ным другим логическим устройствам. Переназначение имен устраняет их коллизии. Перезагрузку (повторную загрузку) DOS, например в случае аппа- ратного или программного сбоя, можно осуществить одним из сле- дующих способов: 1) путем выключения и последующего включения через некото- рое время системного блока ПК (так называемый холодный переза- пуск); 2) путем нажатия кнопки Reset на корпусе П К, если она имеется; 3) путем одновременного нажатия клавиш Ctrl, Alt и Del на кла- виатуре ПК, что обозначается как Ctrl-Alt-Del (так называемый го- рячий или теплый перезапуск); 4) путем ввода команды COMMAND с клавиатуры П К. Первый способ используется для полной перезагрузки DOS, начиная с тестирования оборудования. Отключение и включение питания плохо сказываются на работоспособности аппаратуры. Поэтому болыпенство моделей ПК имеют специальную кнопку Reset, при нажатии которой (второй способ) осуществляется аппа- ратная передача управления на программу тестирования оборудо- вания без отключения питания. Если необходимость в тестирова- нии ПК отсутствует, то ускорить процесс перезагрузки можно, используя третий способ. Четвертый способ наиболее быстрый, но путем ввода команды COMMAND осуществляется только ча- стичная перезагрузка DOS, а именно считывание в ОЗУ и запуск CI. 7.2. Командный файл Преимущества вычислительной техники приобретают особую наглядность, когда пользователь сталкивается с необходимостью многократного повторения одних и тех же действий. Независимо от количества итераций компьютер работает с одинаковой эффек-
тивностью. Человек же, повторяя одну и ту же работу, быстро устает и начинает делать ошибки. Задание представляет собой последовательность вводимых в ком- пьютер команд. Часто в процессе работы пользователю много раз приходится повторять одно и то же задание. На этот случай в MS DOS имеются средства, облегчающие жизнь пользователю, а именно: по- следовательность команд можно объединить и записать на диск в виде файла, называющегося командным файлом. Введенная после- довательность команд будет выполняться при каждом обращении к файлу. В данном разделе описаны характеристики командных файлов и рассмотрены способы применения командных файлов. 7.2.1 Что такое командный файл? Командный файл — это текстовый файл (в коде ASCII), состоящий из группы команд DOS Правила идентификации командных файлов совпадают с общими правилами идентификации файлов. Един- ственное исключение — командный файл всегда записывается на диск с расширением «.ВАТ» (BATch). Обратиться к командному файлу крайне просто. Набирается ко- манда старта — имя файла — и нажимается клавиша Enter. После введения команды файл выбирается из рабочего директория рабо- чего диска. При нахождении файла первая из его команд загружается в па- мять, отображается на экране и выполняется. Этот процесс повто- ряется последовательно для всех команд файла (от первой до по- следней). Выполнение командного файла можно прервать в любой момент, нажав на клавиши Ctrl-Break На экране появится сообщение: Terminate batch job (Y/N)? При введении «У» выполнение командного файла прерывается и на экран выводится стандартный системный запрос. При введении «N» отменяется выполнение только текущей команды. 7.2.2. Организация командного файла Существует несколько способов организации командных файлов. Файл можно создать с помощью простейшего текстового редактора. Еще один способ — введение команд непосредственно с клавиа- туры. В этом случае ввод оформляется файлом и записывается на диск.
В DOS клавиатура называется «CON» (CONsole). Для организа- ции файла используется команда сору сот. Наберите команду и имя создаваемого файла. Например, для создания файла «sample.bat» вве- дите: С>сору con: sa.Tipls.bat После этого введите составляющие файл команды. Набрав по- следнюю команду, одновременно нажмите клавиши Ctrl-Z (или функциональную клавишу F6) и клавишу Enter. На рабочем диске будет организован командный файл sample.bat. Если в рабочем ди- ректории файл sample.bat уже имеется, то старый файл заменяется новым. Командные файлы удобно использовать, скажем, для архивации системных файлов или для копирования простых файлов данных. Предположим, что вы в редакторе обрабатываете файл «essay.doc». Его потеря крайне нежелательна, поэтому вы копируете файл после каждой корректировки. Организовав командный файл, вы избавитесь от этой работы — файл будет копироваться автоматически. Пусть редактор в нашем примере называется «wp.exe». Для создания командного файла введите: Осору con: backup.bat wp.exe copy essay.doc a: AZ <— вы нажмете клавиши Clrl-Z и Enter При нажатии клавиш Ctrl-Z и Emer подключается требуемый ди- сковод и на диске С организуется командный файл «backup.bat». На экран выдается свидетельствующее об этом сообщение и стан- дартный системный запрос. Чтобы запустить командный файл, введите его имя: C>backup Перед выполнением команды файла выводятся на экран. По этому сразу после введения «backup» на экране появится: C>WP.EXE Редактор стартует. После выхода из редактора управление пере- дается DOS. На экране автоматически отображается стандартный системный запрос и следующая команда файла: C>COPY ESSAY.DOC А:
Файл «essay.doc» копируется на дискету А, и выполнение команд- ного файла завершается. На экран выводится стандартный систем- ный запрос (С>) — DOS готова принять команду. 7.2.3. Замещаемые параметры Внутри командного файла допускается использование замеща- емых параметров. Параметр — это символьная переменная, распо- ложенная в командной строке после имени команды. Он содержит дополнительную информацию, необходимую операционной системе при обработке команды. Параметром, например, может быть имя файла, к которому отно- сится действие команды. Замещаемый параметр — это специальная переменная, которая в процессе выполнения команды подменяется обычным параметром (например, именем файла). В командном файле замещаемый параметр обозначается знаком процента (%) и цифрой от 0 до 9. Таким образом, командный файл может включать до десяти замещаемых параметров. Символьные переменные, предназначенные для подмены заме- щающего параметра, вводятся в командной строке при обращении к командному файлу — набирается команда старта (имя файла) и список параметров в порядке, соответствующем последователь- ности замещаемых параметров внутри файла. Параметры заменяются в порядке следования символьных пере- менных в командной строке. Первая переменная подменяет пара- метр %1, вторая — параметр % 2 и т.д. Вместо замещаемого пара- метра %0 автоматически подставляется спецификация командного файла. При введении замещаемых параметров командный файл стано- вится более гибким. Поясним это на примере Предположим, что на диске имеется несколько файлов, которые нужно копировать после каждой корректировки. В рассмотренном выше примере ко- мандный файл использовался для копирования конкретного файла. Этим же командным файлом можно воспользоваться и для копиро- вания любого файла. В этом случае вместо имени копируемого файла подставляется замещаемый параметр. Имя копируемого файла будет вводиться в командной строке при обращении к командному файлу. Назовем наш командный файл copyall.bat. Введем: С>сору com: copyall.bat wp.exe сору%1 а: AZ <— Еы нажмете клавиши Ctrl-Z и Enter
При нажатии клавиш Ctrl-Zи Enter на диске С создается команд- ный файл copyall.bat. При обращении к файлу набирается его имя и через пробел — имя копируемого файла (в нашем примере «shoplist.doc»). Введите ко- манду: C>copyall shoplist.doc OWP.EXE Сначала стартует редактор После выхода из редактора управ- ление возвращается DOS и передается в командный файл. На экран выводится его вторая команда: C>COPY SHOPLIST.DOC А: 1 File(s) copied DOS автоматически подставила имя файла на место замещаемого параметра %1. Усложним пример. Организуем командный файл difnum.bat, ав- томатически копирующий любой указанный файл и присваивающий копии любое указанное имя: Сзсору con: difnum.bat wp.exe сору%1 а:%2 AZ 1 File(a) copied Для обращения к этому файлу наберите его имя, имя копируемого файла (в нашем примере «new.doc») и имя копии («old.doc»): C>difnum new.doc old.doc Сначала стартует редактор. После выхода из редактора управ- ление возвращается DOS и на экране появляется следующая команда файла difnum.bat: C>COPY MEW.DOC A: OLD.DOC 1 File(s) copied Первое имя в командной строке («new.doc») поставлено вместо замещаемого параметра %1, второе имя («oid.doc») — вместо заме- щаемого параметра %2. 7.2.4. Замещаемые параметры и замещаемые символы Параметр в командной строке команды старта командного файла может включать замещаемые символы «?» и «*». Если замещаемый
символ вводится для обозначения группы параметров, то команда выполняется по количеству параметров в группе (т.е. один раз для каждого параметра) Рассмотрим командный файл: С>сору con: display.bat copyil con: AZ 1 Fils(s) copied Этот файл копирует на экран (сои) файл, описанный замещаемым параметром %1. Имя копируемого файла указывается в командной строке при обращении к командному файлу. Если указанный файл найден, его содержимое выводится на экран. Итак, командный файл «display.bat» записан на диск. Введем ко- манду: C>display ’.txt Все файлы рабочего диска с соответствующей спецификацией будут выведены на экран. Если имя копируемого файла включает обозначение процента, то при введении его в командную строку знак процента набирается два раза подряд. Например, имя «hiho%.txt> в командной строке должно быть представлено как «hiho%%.txt». 7.2.5. Команды, используемые в командных файлах Команда pause. Если необходимо временное прерывание выпол- нения командного файла, то можно воспользоваться командой pause. При введении этой команды откладывается выполнение текущей команды файла На экране появляется сообщение: Strike any key when ready... Нажав любую клавишу (кроме Ctrl-С), вы вернете управление ко- манде, выполнение которой было отложено. Нажав клавиши Ctrl-C, вы получите сообщение. Abort batch job (Y/N)?_ При введении «У» управление возвращается DOS, на экране по- является стандартный системный запрос. При введении «N» управ- ление возвращается в командный файл — отложенная команда вы- полняется. Следующий пример показывает, что pause удобно использовать, если в процессе работы командного файла может возникнуть необ- ходимость замены диска на рабочем дисководе. Командный файл
copytwo.bat выполняет двукратное копирование любого указанного файла. При этом первой и второй копиям могут присваиваться лю- бые допустимые имена. Копии можно разнести на разные диски. После создания первой копии выполнение командного файла пре- рывается и пользователь получает возможность поменять диски на устройстве А: С>сору con: copytwo.bat wp.exs соруИ a.%2 pause copyil a:%3 AZ 1 File(s) copied При обращении к этому файлу наберите «copytwo», через про- бел — имя копируемого файла, имя первой и имя второй копии. На- жмите клавишу Enter Процесс работы файла будет фиксироваться на экране. C>copytwo nsw.doc oldl.doc old2.doc C>WP.EXE Вызывается редактор. После выхода из редактора выполняется следующая команда файла: C>COPY NEW.DOC А: OLD1.DOC 1 File(s) copied C>PAUSE Strike any key when ready..,5 C>COPY NEW.DOC A: OLD2.DOC 1 Fiie(s) copied Еще раз отметим, что параметры в командной строке команды старта заменяют соответствующие замещаемые параметры внутри командного файла. Файл «new.doc» копируется. Затем команда pause откладывает вы полнение следующей команды (сору). Пользователь может заменить диск на дисководе А. Нажатием любой клавиши (в нашем примере 5) управление возвращается отложенной команде и файл «new.doc» ко- пируется еще раз. Созданием второй копии завершается работа ко мандного файла. Команда pause может служить для вывода сообщений на экран дисплея. В этом случае после имени команды через пробел набира- ется текстовая строка длиной до 121 символа. В процессе работы командного файла текст выводится на экран'
C>copy con: copytwo.bat яр. exs copy%1 a:%2 pause put disk number2 in drive a copyil a:%3 AZ 1 File(s) copied Теперь в отличие от предыдущего случая при выполнении ко- манды pause на экран выводится сообщение: C>COPY NEW.DOC А: OLDJ.DOC 1 F.ile(s) copied C>PAUSF PUT DISK NUMBER2 TN DRIVE A Strike any key when ready...5 C>COPY NEW.DOC A: OLD2.DOC 1 File(s) copied Команда rem. Команда rem (remark) служит исключительно для вывода сообщений на экран дисплея в процессе работы командного файла. Она вводится в командный файл вместе с требуемым сооб- щением. Длина сообщения нс может превышать 123 символов. Вве- дем, например, в наш командный файл следующие сообщения: С>сору con: copytwo.bat wp.exe rem making copy number 1 copy%l a:%2 pause put disk number2 in drive a rem making copy number 2 copy%l a:%3 AZ 1 File(s) copied Команда rem дает возможность пользователю следить за ходом выполнения командного файла: OREM MAKING COPY NUMBER1 OCOPY NEW.DOC A: OLD1.DOC 1 Filefs) copied OPAUSE PUT DISK NUMBER2 IN DRIVE A Strike any key when ready...5 OREM MAKING COPY NUMBER2 OCOPY NEW.DOC A: OLD2.DOC 1 File's) copied
7.2.6. Файл AUTOEXEC.BAT Для удобства пользователя в системе предусмотрен специальный командный файл AUTOEXEC.BAT. Если он находится в корневом директории рабочего диска, то при загрузке DOS автоматически вы- полняются его команды. Назначение файла — экономия времени (он состоит из обычно вводимых при загрузке команд). В общем слу- чае AUTOEXEC ВАТ определяет спецификаторы пути каждого ди- ректория, назначает рабочий директорий каждого диска, а также производит загрузку управляющей программы операционной сис- темы. Если AUTOEXEC ВАТ не включает команды lime и date, то пользователю при загрузке самому приходится вводить время и дату. Ниже приведен пример файла AUTOEXEC.BAT echo off rem rem Set prompt to display working directory of default drive prompt SpSg rem rem Set the search path and append path path c:\dos; c:\misc; c:\kermit; c:\procom24; c:\utils; append \e \x append c:\mltmate; c:\vedit; c:\masm rem rem Set environment variables set comspec-c:\command.com set procomm=c:\procom24\ rem rem Establish default drive, working directories cd c:\book\newchp cd a: newchp rem rem Start text editor vplus rem rem XCOPY all new or changed files xcopy * a: \m Команда echo. Как уже отмечалось, команды командного файла непосредственно перед выполнением отображаются на экране. Ко- манда echo позволяет управлять выводом этих команд. Команда echo вводится в командный файл в следующем виде. Набирается имя команды — «echo» и режим ее работы — on или off. При введении echo on команды отображаются в обычном (описан-
ном выше) режиме, echo off подавляет выдачу команд на экран, включая и команды rem. Однако на экране будут появляться все сообщения, генерируемые системой в процессе работы командного файла. При отсутствии echo в командном файле по умолчанию работает режим on. Если произошло прерывание выполнения командного файла (аварийное или нормальное), то команда echo автомати- чески переходит в режим on. При введении имени команды («echo») на экране отображается режим ее работы в текущий мо- мент времени. Рассмотрим работу команды на примере команд- ного файла: С>сору con: exa.Tiple.bat rem Это сообщение выводится на экран rem т.к. echo в режиме он echo off <— ECHO переходит в режим off rem Это сообщение не выводится на экран rem т.к echo в режиме off echo <— выводится режим ECHO echo on <— ECHO переходит в режим on rem echo опять в режиме on echo <— выводится режим ECHO AZ 1 File(s) copied C>examplel OREM ЭТО СООБЩЕНИЕ ВЫВОДИТСЯ НА ЭКРАН OREM Т.К. ECHO В РЕЖЕ ON OECHO OFF ECHO is off OREM ECHO ОПЯТЬ В РЕЖИМь ON OECHO ECHO is on Первые две команды rem выводятся на экран, так как echo по умолчанию находится в режиме on. Третья команда переводит echo в режим off, поэтому следующие две команды rem на экране не появляются. Шестая команда (echo) отображает текущий режим echo — off. Седьмая — переводит echo в режим on. Если echo вводится в командный файл вместе с сообщением, то оно появится на экране вне зависимости от режима работы ко- манды: С>оору con: exampls2.bat acho off
reiji данное сообщение не выводится echo а это выведется на экран echo on ren сообщение появится на экране echo и это тоже... дважды AZ 1 File(s) copied C>example2 С>ЕСНО OFF А ЭТО ВЫВЕДЕТСЯ НА ЭКРАН OREM СООБЩЕНИЕ ПОЯВИТСЯ НА ЭКРАНЕ ОКНО И ЭТО ТОЖЕ ДВАЖДЫ И ЭТО ТОЖЕ... ДВАЖДЫ Первая команда переводит echo в режим off. Поэтому первая гет не выводится на экран. Следующая команда — echo находится в ре- жиме off; следовательно, и эта команда не появится на экране, од- нако сообщение, находящееся в области действия команды (а это выведется на экран), будет отображено. Четвертой командой echo переводится в режим on, и поэтому следующая за ней команда rem появляется иа экране. Последняя команда файла — echo появится на экране вместе с относящимся к ней сообщением. Текст на экране воспринимается легче, когда он разбит пустыми строками, отделяющими один смысловой абзац от другого. Для вве- дения пустой строки можно воспользоваться командой echo. Команда «echo.» (echo и десятичная точка) посылает на экран пу- стую строку. DOS позволяет отменить вывод строки командного файла на экран дисплея. В этом случае первым символом строки должен быть символ «@». Этим пользуются, скажем, для подавления изобра- жения команды echo off, если опа является первой командой команд- ного файла. В процессе работы следующего, например, файла на экране не появится ни одной команды: @edic off rem Это тест При отсутствии символа «@» на экране отображается команда echo off. Команда goto. Команда служит для передачи управления в грани- цах области действия командного файла. Метка строки командного файла состоит из двоеточия (:), за которым следует от 1 до 8 симво- лов. Введите, например, следующие строки:
C>copy con: gxamplo3.bat rem Это первая строчка гgm Это вторая строчка goto four rem Это третья строчка : four rem Это четвертая строчка AZ 1 Filets? copied C>example3 OREM ЭТО ПЕРВАЯ СТРОЧКА C>REM ЭТО ВТОРАЯ СТРОЧКА OGOTO FOUR OREM ЭТО ЧЕТВЕРТАЯ СТРОЧКА Сначала выполняются первые две команды. Затем — команда под меткой «four». Далее продолжается последовательное выполнение команд до конца файла. Метка goto может представлять собой замещаемую переменную. В этом случае позволяется переходить на метку, заданную командой старта командного файла. Рассмотрим пример: С>сору con: examplg3.bat goto%l : ong rem this is one goto finish : two rem this is two goto finish : three rem this is three : finish AZ 1 File(s) copied C>exa.nple3 three C>GOTO THREE OREM THIS IS THREE Команда старта включает параметр three. При выполнении пер- вой команды командного файла, замещаемая переменная % 1 заме- няется на <three». Далее выполняется команда помеченная: Three — команда rent (this is three). Последняя строка командного файла — это метка строки. В про- цессе работы командного файла метки не выводятся на экран.
Команда if. Обычно команда if используется для выделения ко- манд. выполняющихся в случае, если выполняются некоторые задан- ные условия. Существует три типа условий, которые могут тестиро- ваться командой if: IF EXIST; IF строка! = строке2; IF ERROR- LEVEL. Первый тип условий называется условием типа EXIST. По этому условию производится проверка на существование указанного файла. Если файл существует, то условие считается выполненным и выделенные команды выполняются. Рассмотрим команду: if exist somefile.dat type somefile.dat При ее выполнении производится проверка на наличие файла «somefile.dat» на рабочем диске. Если файл существует, то выполня- ется команда type В противном случае команда type пропускается и выполняется следующая по порядку команда. Команда if exist может использоваться для проверки наличия фай- лов не только на рабочем диске В этом случае перед именем файла необходимо указать шифр дисковода (например, а: или Ь ). Однако необходимо помнить, что проверка производится только для файлов в рабочих директориях. Чтобы произвести проверку фай- лов в другом директории, нужно назначить его рабочим: IF STRING1 == STRING2 Второй тип условия — проверка идентичности двух символьных строк Рассмотрим командный файл: С>сору con: example4.bat echo off if %l==roses goto roses if %l==candy goto candy if %l==perfume goto perfume echo у Вас большие неприятности goto finish : roses echo Вы послали розы. Как трогательно, goto finish : candy echo Вы послали конфеты. Как сладко, goto finish ; perfume echo Вы послали духи. Как романтично : finish AZ
1 File(s) copied C>example4 perfume C>FCHO OFF ВЫ ПОСЛАЛИ ДУХИ. КАК РОМАНТИЧНО. Каждая команда if производит сравнение замещаемого параметра с символьной переменной. Отметим, что при сравнении знак тож- дества обозначается двойным знаком равенства (==). В командную строку команды старта вводится параметр — символьная перемен- ная, которая в процессе работы командного файла подставляется вместо замещаемого параметра % 1. Если результат сравнения положительный, то выполняется ко- манда области действия данного if. В нашем примере это команда перехода на метку строки PERFUME. В противном случае выполня- ется следующая по порядку команда. Отметим, что первая команда командного файла — echo off. По- этому на экране отображается только результат его выполнения. IF ERRORLEVEL n ERRORLEVEL — это имя переменной операционной системы. Она контролирует работу команд DOS. Большинство команд, если при их выполнении произошла ошибка, присваивают ERROR LEVEL некоторое значение. Это значение (код ошибки) устанавливается в зависимости от типа ошибки. Команда IF ERRORLEVEL n command означает, что если значение ERRORLEVEL больше или равно значе- нию п, то выполняется команда command. Команда if not. Команда if not служит для проверки некоторого условия. Однако команда в области действия if not выполняется, если результат проверки отрицательный. Рассмотрим команду: if not exist somefile.bak copy somefile.txt somefile.bak Эта команда производит проверку наличия файла. Если файл не найден, то выполняется команда в области действия if. if not можно использовать для проверки любого допустимого условия. Команда for. По команде for команда командного файла выпол- няется несколько раз подряд — один раз для каждого из группы за- данных параметров. Команда for имеет усложненный синтаксис, поэтому для начала рассмотрим пример: for%%a IN (filel file2 file?) DO del fcfca
Данное предложение начинается командой for. За ней следует пустая переменная. Пустая переменная в командном файле обозна- чается двойным знаком процента (%%). Затем следует слово IN, ко- торое обязательно должно набираться заглавными буквами. После IN в скобках перечисляются параметры, впоследствии обрабатыва- емые следуемой за ними командой (det). Эта группа параметров обычно состоит из имен файлов. В нашем примере их три. Группа параметров замыкается словом «DO», также набранным заглавными буквами. Затем набирается имя команды — в нашем примере «del %%а». Она выполняется три раза, последова- тельно уничтожая файлы file 1, file2 и file3. Команда for оказывается незаменимой, когда одной командой требуется обработать несколько файлов, имена которых нельзя объ- единить замещаемыми символами. Предположим, что на диске име- ются файлы: cxample.bat. program.txt и letter — и каждый из них не- обходимо распечатать Можно ввести команду сору example.batргп и ждать, пока файл распечатается, затем ввести ту же команду для файла program.txt, опять подождать и ввести ту же команду для третьего файла. При этом много времени теряется на ожидание. Команда for, введенная в командный файл, избавит вас от потери времени: for %%а IN (example.bat program.txt letterO DO copy %%a prn Три файла распечатываются одной командой. Количество команд for в командном файле не ограничено. Ко- манда может работать и как стандартная команда DOS. Если она используется вне командного файла, то пустой переменной должен предшествовать только один знак процента (%). Любой файл, используемый в качестве параметра команды for, должен находиться в рабочем директории рабочего диска. Команда shift. Команда shift позволяет вводить более десяти па- раметров в командной строке команды старта файла типа «batch». Напомним, что командный файл может включать до десяти заме- щаемых параметров. В процессе работы командного файла пара- метры командной строки последовательно заменяют замещаемые параметры. Первый параметр подставляется вместо замещаемого параметра %1, второй — вместо %2 и т.д. Замещаемый пара- метр %0 резервируется системой под спецификацию командного файла. Команда shift смешает параметры командной строки на один влево, т.е. первый параметр подменяет замещаемый параметр %0,
второй — % 1 и т.д. При выполнении shift каждый раз производится смещение на один параметр. Следующий командный файл иллюстрирует работу команды: С>сору con: example6.bat scho off echo %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 shift echo %0 %1 %2 %3 %4 %5 %6 V %8 %9 shift echo %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 shift echo %0 %1 %2 %3 %4 %5 %6 VJ %8 %9 AZ 1 File(s) copied C>example6 00 0102 03 040506070809 10 OECHO OFF EXAMPLE? 00 01 02 03 04 05 06 07 08 00 01 02 03 04 05 06 07 08 09 01 02 03 04 05 06 07 08 09 10 02 03 04 05 06 O’? 08 09 10 В результате выполнения командного файла на экран четыре раза выдаются рабочие значения замещаемых параметров В первый раз параметр %0 (команда echo) подменяется переменной «EXAMPLE6», параметр %1 — значением 00, %2 — 01 и т.д. Второй раз, после вы- полнения команды shift параметру %0 присваивается значение 00, параметру % 1 — значение 01, параметру % 1 — 02 и т.д. Отметим, что после выполнения третьей shift значения присваиваются только пер- вым девяти замещаемым параметрам. Более практичное применение shift иллюстрируется в конце раздела на примере командного файла 1N1T.BAT. Команда call. В настоящее время концепция модульного прог- раммирования получила очень широкое распространение. Принцип модульного программирования состоит в разбиении большой при- кладной программы на несколько отдельных подпрограмм — моду- лей таким образом, чтобы каждый модуль выполнял некоторую от- дельную функцию (например, обработку файла, копирование файла и т.д.). Программисты пытаются писать универсальные модули, т.е. такие, к которым могли бы обращаться самые разнообразные программы. Такой способ избавляет пользователя от необходимости «изобре- тения колеса». Еще одно преимущество модульного программиро-
вания — удобство и простота отладки маленькой программы по срав- нению с большой. Обращение к модулю осуществляется с помощью команды call. Программирование командных файлов — первый шаг на пути создания универсальных командных модулей. Рассмотрим, например, принцип работы следующих командных файлов: С>сору con one.bat scho starting ons two scho ending two AZ 1 File(s) copied C> copy con two.bat echo starting two echo ending two AZ 1 Filets) copied При обращении к файлу ONE.BAT происходит следующее: С>опе C>echo starting one starting one C>two C>e?ho starting two starting two C>e?ho ending two ending two C> Команда echo файла ONE.BAT выводит на экран стартовое сооб- щение, затем производится обращение к файлу TWO ВАТ. В про цессе работы этого файла на экране появляются сообщения начала и окончания работы. Файл завершает выполнение. Однако, в боль шинстве случаев после этого управление возвращается DOS, а не в файл ONE.BAT. Его конечное сообщение так и не появится на экране. Этой ошибки можно избежать, немного изменив файл ONE.B AT, а именно; для обращения к файлу TWO ВАТ вводится ко манда call C>copv con on?.bat echo starting one call two echo ending two
Az 1 File(s) copied Теперь после завершения TWO.BAT управление передается сле- дующей после call команде файла ONE.ВАТ. С>спе C>echo starting one starting one C>call two C>echo starting two starting two Oecho ending two ending two Oecho ending one ending one Использование переменных операционной среды. Командные файлы DOS могут обрабатывать переменные операционной среды, используя и изменяя их значения. Для обращения к переменной опе- рационной среды набирается ее имя, заключенное в два знака про- цента. Таким образом, команда echo%path% выведет на экран специ- фикатор пути от корневого до рабочего директория. Командный файл ADD2PATH .ВАТ можно использовать для до- полнения имеющейся переменной операционной среды PATH до- бавочными спецификаторами пути. Командный файл вызывается командой следующего формата: add2path newpathl; newpath2: newpath3... где каждая переменная newpath — это спецификатор пути (например, a:\subdir2\subdir2). Командный файл состоит из цикла, выполня- ющегося для каждой переменной newpath, выбранной из командной строки. Каждый раз после выполнения цикла к имеющемуся значе- нию переменной операционной среды PATH добавляется значение замещаемого параметра %1. Затем команда shift вводит следующую переменную командной строки newpath, подставляя ее вместо заме- щаемого параметра %1. Команда, расположенная после метки конца цикла, производит проверку на наличие невыбранных newpath в ко- мандной строке. Обратите внимание на то, что параметр %1 заклю- чен в кавычки: echo off echo Л [ [sA К1АЛ [ [КЛ Г [u rem rem ADD2PATH.BAT
ram rem Этот файл дополняет системную переменную PATH rem добавочным спецификатором пути. rem Синтаксис обращения к файлу: rem rem ADD2PATH newpathl; newpath2... rem rem Каждая переменная newpathl, newpath2.„ представляет собой rem дополнительный спецификатор пути, добавляемый к rem существующей rem системной переменной PATH, Переменные newpath могут rem отделяться rem двоеточием, пробелом, символом табуляции или другим rem подобным символом rem rem Для обращения к переменной PATH в файле предусмотрена rem команда «%ра1М». Количество символов, которые могут rem добавляться к переменной PATH, ограничивается rem следующими rem факторами: (1) максимально допустимым количеством rem символов rem командной строки; (2) максимально допустимым rem количеством rem символов, вводимых в операционную среду (см.гл.12). При rem нарушении последнего ограничения будет выдано rem сообщение: rem rem Out of environment space rem rem Для каждого введенного спецификатора ADD2PATH rem единожды rem производит выполнение цикла. После выборки всех rem спецификаторов из командной строки файл завершает rem выполнение. rem На экране появляется новое значение переменной rem операционной rem среды FATH. rem rem ЗАМЕЧАНИЕ. Для корректного выполнения второй команды rem echo rem необходимо, чтобы в качестве драйвера клавиатуры rem использовался файл ANSI.SYS. rem : loop rem Переход на метку exit, если выбраны все параметры rem командной
ram строки if “%1"=="" goto exit геш Добавление?,! к имеющейся path set path=%path%;%l rem Сдвиг на параметр влево shift goto loop exit echo PATH=%path% echo Файлом ADD2PATH удобно пользоваться при необходимости дополнить переменную PATH, не набирая ее значения с клавиатуры. При изменении значения PATH с клавиатуры (с помощью команды seipath=) пользователь ограничен 149-символьным буфером клави- атуры, поэтому он рискует не получить значение нужной длины. При использовании файла ADD2PATH программист ограничен только размерами переменной операционной среды. Этот файл также можно использовать при введении специфика- тора пути, с которым не работают, но который требуется для некото- рой отдельной программы. Следующий файл настраивает DOS на ра- боту с редактором WP. находящимся вне рабочего директория. echo off rem rem WP_INIT.BAT rem rem Файл настраивает MS DOS на работу c WP rem rem Добавление спецификатора пути директория, включающего rem WP, rem к существующему значению переменной PATH rem cal 1 add2path \wp rem rem Назначение рабочих директориев с: cd \letters\aug_81 cd a:\letters\aug_81 rem rem Загрузка редактора wp rem rem Копирование вновь созданных или отредактированных rem файлов сору *. * а:
Этот файл присоединяет дополнительный спецификатор пути редактора WP к текущему значению переменной операционной среды PATH В результате пользователь получает возможность рабо- тать с текстовым редактором, который записан в директории, не включающем обрабатываемые редактором файлы. 7.3. Конфигурационные файлы Большинство информации о конфигурации системы хранится в двух файлах: • файл CONFIG.SYS — это текстовый файл, который содержит ко манды о конфигурации аппаратных компонентов вашего ком- пьютера (память, клавиатура, «мышь», принтер и т.д.) для DOS. Другие приложения также могут использовать эту информацию. Когда DOS стартует, первыми выполняются команды, записан- ные в файле CONFIG.SYS; • файл AUTOEXEC.BAT — это командный файл, который DOS запускает сразу же после выполнения команд, указанных в файле CONFIG.SYS. Файл AUTOEXEC ВАТ может содержать любые команды, которые вы хотите выполнять при запуске ком- пьютера. К примеру, команда, указывающая порт, к которому присоединен принтер, очистка экрана или запуск ваших люби- мых программ. Эти файлы обычно расположены в корневой директории загру- жаемого диска (обычно диск С). Пока вы не указали обратное, DOS выполняет команды в обоих файлах CONFIG.SYS и AUTOEXEC.BAT каждый раз при запуске компьютера. При инсталляции DOS Setup создает базовую системную конфи- гурацию, которая работает на большинстве компьютеров. Однако, возможно, вы захотите изменить ее: 1) для указания DOS, как использовать аппаратное обеспечение, память и файлы; 2) добавления новых аппаратных компонентов или переконфи- гурации существующих; 3) указания команд, которые вы хотите выполнять каждый раз при запуске компьютера; 4) определения более чем одной системной конфигурации. К примеру, если два человека работают на одном компьютере, каж- дый из них может указать различную конфигурацию. Как это сделать, будет описано в данном разделе.
7.3.1. Использование команд в файле C0NF1C.SYS для конфигурирования системы При запуске компьютера DOS выполняет команды, которые кон- фигурируют аппаратное обеспечение и резервируют пространство в памяти для информационных процессов. Файл, содержащий эти команды, назван CONFIG.SYS. DOS Setup создает этот файл и со- храняет его в корневой директории вашего загружаемого диска. Если файл CONFIG.SYS уже существует, Setup по необходимости его мо- дифицирует. Вы можете редактировать файл CONFIG.SYS для добавления но- вых и изменения существующих команд. Для редактирования файла CONFIG.SYS нужно использовать простейшие текстовые редакторы, сохраняющие информацию в ASCII формате. DOS читает файл CONFIG.SYS только при запуске компьютера. После модификации этого файла вы должны перезапустить компью- тер, чтобы ваши изменения были учтены. Для изменения файла CONFIG.SYS рекомендуется выполнить следующие действия: 1) сделайте загружаемый диск, вставив дискету в дисковод А и за- тем набрав команду: format a: /s 2) скопируйте файл CONFIG SYS на дискету, набрав команду: серу c:\config.sys а: 3) откройте файл CONFIG.SYS на вашем жестком диске, исполь- зуя текстовый редактор; 4) добавьте или измените необходимые команды. Каждая команда должна начинаться с новой строки. Список всех команд, которые мо- гут быть использованы в файле CONFIG.SYS, приведен ниже; 5) по окончании редактирования сохраните изменения и затем выйдите из текстового редактора. Удалите все дискеты из дисководов и перезапустите компьютер, нажав CTRL-ALT-DEL. Примечание. Установки в файле CONFIG.SYS управляют базо- выми компонентами вашей системы, такими как память, и другими аппаратными устройствами. Если ваши изменения или новые уста- новки неверны, ваша система может запуститься некорректно. Если это произошло, перезапустите компьютер, вставив созданную вами загружаемую дискету в дисковод А и нажав CTRL+ALT- DEL.
Команды в файле CONFIG.SYS загружают специальные прог- раммы или определяют, как должно работать аппаратное обеспе- чение. Большинство CONFIG.SYS, команд могут быть использованы только в этом файле, исключая команды, которые могут быть ис- пользованы в файле AUTOF.XEC.BAT или набраны на приглашение DOS. Таблица 7.2 кратко описывает каждую команду. Таблица 7.2 Перечень команд файла CONFIG.SYS Команда Назначение break Указывает, с какой периодичностью DOS будет проверять комбинации клавиш CTRL+Cи CTRL+BREAK buffers Указывает количество памяти, резервируемое для передачи информации между памятью и диском country Устанавливает языковые соглашения для вашей системы device Загружает устанавливаемый драйвер устройства — прог- рамму, которая управляет аппаратными компонентами, такими как «мышь» или память devicchigh Загружает устанавливаемый драйвер устройства в «верхнюю» память dos Указывает, будет ли DOS использовать «высшую» память (НМА) и поддерживать доступ к блокам «верхней» памяти (UMB) drivparm Устанавливает характеристики дисковода files Указывает количество файлов, которые могут быть открыты одновременно install Устанавливает резидентную программу lastdrive Указывает количество дисков numlock Указывает, включен или выключен режим NUM LOCK на цифровом поле клавиатуры rem Указывает, что данная строка является примечанием, а не командой set Устанавливает значение переменной окружения, как PROMPT или TEMP shell Конфигурирует COM MAN D.COM или устанавливает дру- гой интерпретатор команд stacks Устанавливает количество памяти, резервируемое для ра- боты аппаратных прерываний switches Указывает специальные опции для DOS Файл CONFIG.SYS может также содержать команды: include, menu- color, menudcfault, menuitem и submenu. О них мы будем говорить позже.
Примечание. Большинство команд могут появляться в файле CONFIG.SYS в любом порядке. Однако порядок команд device п de- vicehigh очень важен. Для получения более детальной информации о каждой из команд наберите строку: help команда 7.3.2. Конфигурирование аппаратных устройств Каждый компьютер имеет аппаратные компоненты, названные устройствами. Клавиатура, «мышь», монитор, принтер, дисководы и память — все это устройства. Каждое устройство имеет различные характеристики. DOS использует программы, названные драйверами устройств, для управления каждым устройством. К примеру, DOS использует встроенный драйвер устройства для управления дисководами. DOS также имеет встроенные драйверы для клавиатуры, монитора, жест- кого диска и портов. Имея встроенные драйверы, необязательно указывать специальные драйверы для этих устройств. Другие устройства поставляются со своими драйверами. Такие драйверы устройств называются устанавливаемыми, потому что они устанавливаются отдельной командой в файле CONFIG.SYS. DOS включает несколько устанавливаемых драйверов устройств. Для использования устанавливаемого драйвера устройства необ- ходимо добавить команду device в файл CONFIG.SYS. При запуске системы драйвер устройства будет загружен в память. К примеру, для загрузки драйвера MOUSE.SYS, который расположен в директории С:\ MOUSE, необходимо добавить команду: devicc-c: \mouse\mouse.sys Когда DOS получит эту команду, драйвер MOUSE.SYS будет за- гружен в память. Примечание. Много аппаратных устройств поставляются с инсо- ляционными программами, которые автоматически добавляют не- обходимую команду в файл CONFIG SYS. DOS поставляется со следующими устанавливаемыми драйверами устройств (табл. 7.3.). 7.3.3. Определение порядка команд в файле CONFIG.SYS Большинство команд могут быть расположены в файле CONFIG. SYS в любом порядке, например команды dos. files, buffers.
Таблица 7.3 Драйверы, входящие в состав DOS Драйвер Назначение ANS1.SYS Поддерживает эмуляцию терминала по «Американ- скому институту национальных стандартов» (ANSI) DISPLAY. SYS Поддерживает переключение кодовых страниц для мониторов DBLSPACE.SYS Передвигает DBLSPACE.BIN в конец памяти DRIVE R.SYS Создает логический диск, который вы можете исполь- зовать для присоединения к физическому дисководу EGA.SYS Сохраняет и восстанавливает экран, когда DOS или Windows производит переключение задач с EGA-мо- нитором EMM386. EXE Эмулирует расширяемую память и поддерживает до- ступ к «верхней» памяти на компьютерах с процессо- рами 80386 или выше с дополнительной памятью HIMEM.SYS Управляет дополнительной памятью на компьютерах с процессорами 80286 или выше с дополнительной памятью (DOS Setup устанавливает этот драйвер авто- матически при конфигурировании системы) RAMDRIVE.SYS Эмулирует жесткий диск, создавая виртуальный диск в памяти вашей системы SETVER. EXE Загружает таблицу версий DOS SMARTDRVEXE Выполняет двойную буферизацию, поддерживающую совместность для контроллеров жестких дисков, кото- рые не могут работать с памятью, предоставляемой EMM386, или Windows, запущенном в 386 расширен- ном режиме Порядок расположения команд device и devicehigh очень важен, потому что некоторые драйверы устройств устанавливают устрой- ства, которые нужны для работы других драйверов Например, драй- вер HIMEM.SYS, управляющий «расширенной» памятью, должен быть загружен перед любым драйвером, использующим эту память. Следующий список показывает, в каком порядке должны появ- ляться драйверы устройств в файле CONFIG.SYS. 1. HIMEM.SYS, если ваш компьютер оборудован «расширенной» памятью. 2. Драйвер, управляющий «расширяемой» памятью, если ваш компьютер имеет плату «расширяемой» памяти. 3. EMM386 EXE, если ваш компьютер оборудован процессором 80386 и «расширенной» памятью. (Если ваш файл CONFIG.SYS со-
держит команды, загружающие оба драйвера, управляющих «расши- ряемой» памятью, при загрузке EMM386.EXE вы должны указать опцию noerns.) 4. EMM386 может предоставлять доступ к «верхней» памяти. ЕММ386 может также использовать «расширенную» память для эму- ляции «расширяемой» памяти на компьютерах, не оборудованных платой «расширяемой» памяти. 5. Любые другие драйверы устройств. Примечание. Этот список только рекомендует порядок для драй- веров устройств. Файл CONFIG.SYS необязательно должен содер- жать эти команды. Содержимое этого файла зависит от типа ком- пьютера, количества и типа памяти, аппаратной конфигурации и имеющихся программ Ниже показано содержимое файла CONFIG.SYS на компьютере с процессором 80386 и двумя или более мегабайтами «расширенной» памяти: dsvice=c:\dcs\sstver.ехе device=e. \dcs\himem.sys device=c:\dos\e-Tiin386.exe ram devicehigh=c: \mouse\mouse. sys buffars=20 fiies=40 braak=on dos=high, umb В этом примере: • команды device загружают драйверы устройств SETVER.EXE, HIMEM.SYS и EMM38fv.EXE. Драйвер SETVER.EXE управляет таблицей версий MS DOS Драйвер HIMEM.SYS управляет «рас- ширенной» памятью. Опция ram указывает драйверу EMM386, ЕХЕ обеспечивать доступ к «верхней» памяти и эмулировать «рас- ширяемую» память; • команда devicchigh загружает драйвер MOUSE SYS, который обес- печивает доступ к «мыши», в «верхнюю» память; • команда buffers резервирует 20 буферов для обмена информации с дисками: • команда files сообщает DOS, что одновременно могут быть от- крыты 40 файлов; • команда break определяет частоту проверки комбинаций клавиш CTRL+Cи CTRL +BREAK, • команда dos~high. umh запускает DOS в «высшей» памяти и обес- печивает программам доступ к «верхней» памяти.
Если ваш компьютер использует сеть и оборудован процессором 80286 и платой «расширяемой» памяти, файл CONFIG.SYS может выглядеть следующим образом: device=c:\ensdrv\ensdrv.sys device=c\mouse\mouse.sys device- e:\net\network.sys device=c:\dcs\ramdrive.sys 256 /a lastdrive=z buffers=20 files=30 break=on В этом примере: • первые три команды device нагружают драйвера устройств для платы «расширяемой» памяти, «мыши» и сети; • команда device=c:\dos\rantdrive.sys 256/а запускает программу RAMDrive и создаст виртуальный диск на 256 килобайт, опция /а указывает, что диск должен открываться в «расширяемой» памяти; • команда lastdrive резервирует место для 26 логических дисков, ко- торым могут быть присвоены буквы от А до Z. 7.3.4. Подтверждение выполнения каждой команды файла CONFIG.SYS Если вы встретились с проблемой, которая, по вашему мнению, связана с командами в файле CONFIG.SYS, можно сделать, чтобы DOS запрашивала подтверждение на выполнение каждой команды при запуске компьютера. Для подтверждения выполнения каждой команды файла CON - FIG.SYS необходимо выполнить следующие действия. Е Запустить или перезапустить компьютер. После запуска ком- пьютера DOS покажет сообщение: Starting MS-DOS... 2. Пока этот текст находится на экране, нажать и отпустить кла- вишу F8. DOS выдаст следующее сообщение: MS-DOS will prompt you to confirm each CONFIG.SYS command. DOS будет показывать каждую команду в файле CONFIG.SYS и запрашивать подтверждение на ее выполнение К примеру, когда DOS достигнет команды dos=high, будет выдано следующее сообще- ние-
DOS=HIGH [Y, NJ? Для выполнения текущей команды необходимо нажать У Для пропуска этой команды нажать N. Для выполнения всех оставшихся команд нажать ESC Для пропуска всех оставшихся команд нажать 15. 3. Когда DOS закончит выполнение файла CONFIG.SYS, будет выдано следующее сообщение: Process AUTOEXEC.BAT [Y, N]? Для выполнения всех команд в файле AUTOEXEC.BAT необхо- димо нажать К Для пропуска файла AUTOEXEC.BAT нажать N. 7.3.5. Использование нескольких конфигураций Один файл CONFIG.SYS может определять несколько различных конфигураций системы. Это обычно используется, когда несколько человек работают на одном компьютере или если необходимо иметь возможность выбирать конфигурацию. Для этого надо: 1) создать меню в файле CONFIG.SYS. Каждый раз при запуске компьютера будет показан список кон- фигураций с возможностью выбора нужной конфигурации; 2) создать блок конфигураций в файле CONFIG.SYS и подтверж- дение на его выполнение. Блок начинается с заголовка блока — имени, заключенного в квадратные скобки. Каждый блок содержит команды, которые бу- дут' выполняться при выборе нужной конфигурации из меню. Следующий пример показывает структуру файла CONFIG.SYS, в котором определены меню и две различные конфигурации. [menu] menuitem-Green menuitem=Purple [green] fiies=40 de vice=c: \devicel.sys [purple] files: 10 devic=c:\device2.sys В этом примере: • первый блок конфигурации определяет меню. Меню содержит два пункта — Green и Purple. Каждый пункт связан с отдельным блоком конфигураций; • блок конфигураций [green] содержит команды, которые будут вы- полнены при выборе пункта меню Green. Когда компьютер за-
пустит конфигурацию блока Green, DOS установит значение files, равное 40, и загрузит драйвер устройства DEVICE1 .SYS; • блок конфигураций [purple] содержит команды, которые будут выполнены при выборе пункта меню Purple. Когда компьютер запустит конфигурацию блока Ршр1е, DOS установит значение files, равное 10, и загрузит драйвер устройства DEVICE2.SYS Когда компьютер запустит файл CONFIG.SYS, появится следу- ющее меню: MS-DOS6.22 Startup Menu Green Purple Enter a choice: 1 Если выбрать пункт Green, DOS запустит команды из блока [green]; при выборе пункта Purple DOS запустит команды из блока [purple]. Для использования нескольких конфигураций необходимо опре- делить меню. Для гою чтобы сделать это, необходимо создать блок конфигураций, который начинается с команды [menu]. Таблица 7.4 описывает все команды, которые может содержать этот блок. Таблица 7.4 Список команд, используемых при создании меню Команда Назначение menuitem Определяет пункт меню. Эта команда указывает блок кон- фигураций, связанный с этим пунктом, и, возможно, текст меню для этого пункта menudefault Указывает пункт меню по умолчанию. Эта команда является необязательной; если она отсутствует, по умолчанию уста- навливается пункт 1. Команда menudefault может включать интервал времени; если за указанное время вы не сделали выбор, DOS запустит компьютер, используя конфигурацию по умолчанию menucolor Устанавливает цвета текста в фона меню submenu Указывает, что пункт меню является подменю numlock Устанавливает состояние режима NUM LOCK при запуске компьютера Ниже показан образец блока [menu]: [menu] menuitem=Net, Start the network menuitem=No_Net, Do not start the network
msnucolor=15Д menudsf ault=Net, 20 В этом примере: • две команды menuitem определяют пункты, содержащиеся в меню. В первой команде значение «Net,» указывает имя блока конфигу- рации, связанного с этим пунктом. Следующее значение является необязательным и определяет текст, который будет показан в меню («Start the network»). Если этот текст не указан, DOS ис- пользует имя блока конфигурации, • первая команда menuitem связана с блоком [net], а следующая — с блоком [no net]; • команда menucolor устанавливает цвет текста 15 (ярко-белый) и цвет фона 1 (синий); • команда tnenudefauh указывает, что блок [net] будет выбран по умолчанию, и устанавливает интервал времени 20 с. Если по истечении этого интервала не будет сделан выбор, DOS за- пустит компьютер с конфигурацией по умолчанию. Блок конфигурации — это команды файла CONFIG.SYS, которые выполняются при выборе из меню. Блок конфигурации начинается с заголовка блока — имени блока, заключенного в квадратные скобки. Имя блока должно состоять из одного слова, но может быть любой длины. Когда DOS запускается с частичной конфигурацией, выполняются все команды, расположенные между заголовком блока для этой конфигурации и началом следующего блока. Блок конфигурации может содержать только команды, допусти- мые в файле CONFIG.SYS. Следующие команды могут быть осо- бенно полезны в блоке конфигурации: • команда set устанавливает переменную окружения. Можно ис- пользовать эту команду, чтобы установить уникальные значения для каждой конфигурации; • команда include перенаправляет DOS на выполнение команд из следующего блока. Общие команды для всех блоков конфигураций могут быть поме- щены в блок с именем [common], DOS выполняет команды, распо- ложенные в блоке [common], для каждой конфигурации. Можно иметь любое количество этих блоков, и DOS будет выполнять ко- манды из этих блоков в порядке их появления. Можно также поместить блок [common] в конец файла CONFIG. SYS, даже если он не содержит ни одной команды. Некоторые при- ложения при установке добавляют команды в файл CONFIG.SYS.
Если файл CONFIG.SYS заканчивается блоком [common], приложе- ния могут добавить команды, которые DOS будет выполнять для всех конфигураций. Следующий файл CONFIG.SYS определяет две конфигурации и включает несколько общих для них команд: лепи] menuitem=Steve menuitem=Lisa 'common] dos=high buffers=15 device=c: \dos\hime_Ti. sys [stevs] filas=20 device=c:\dcs\emm386.exe 2048 [lisa] filas=40 device=c:\nat\network.sys [common] Этот файл CONFIG.SYS содержит конфигурации для Steve или Lisa. Для обоих конфигураций DOS выполняет три команды в пер- вом [common] блоке: dos=high, buffers=15, device=c:\dos\himem.sys. В этом случае блок [common] расположен первым, так как содер- жит команду device для драйвера HIMEM.SYS, который должен быть загружен перед другими командами. Steve использует издательскую систему, которая требует «расширяемой» памяти, для этого в конфи- гурацию включена команда, загружающая драйвер EMM386. Она не работает в сети. Lisa использует сеть, но не издательскую систему. Ее конфигурация запускает драйвер сети. Блок [common] находится в конце файла для команд, которые могут быть добавлены при уста- новке новых приложений. Можно также включать содержимое одного блока конфигураций в другой, используя команду include, которая указывает имя блока. Команда include может быть использована только внутри блока кон- фигурации. В следующем файле CONFIG.SYS определено несколько блоков конфигурации и используется команда include для включения блоков [windows] и [network] в блок [winnet]: [menu] menuitem=Windows, Configure for Windows menuitem=Network, Start the network menuitem=WinNet, Configure for Windows and start the network
[coitmon] fjles=40 buffsrs=20 device=c:\dos\himem.sys dos=high 'windows] set path=c: Windows; c\dos set temp=c: Windows\temp [network] devjce=c:\ net \network.sys set path=c\dos; c:\network lastdrive=z [winnet] include=windows ±jiclude=network set path=c: \windows; e: '.network; c: \dos [ common] Этот файл CONFIG.SYS содержит три конфигурации: Windows, Network и WinNet Блок [winnet] включает команды блоков [windows] и [network] и дополнительно содержит команду path Первый блок [common] включает команды, общие для всей конфигурации. По- следний блок [common] — пустой для команд, которые могут быть добавлены в файл CONFIG.SYS при установке новых приложений. 7.4. Программная модель микропроцессора В организации вычислительного процесса важную роль играют регистры микропроцессора, на базе которого построен компьютер, и именно они и составляют программную модель, которая доступна программисту на уровне команд. В процессорах Pentium эти ре- гистры делятся на несколько групп- • регистры общего назначения; • регистры сегментов; • указатель инструкций; • регистр флагов; • управляющие регистры; • регистры системных адресов; • регистры отладки и тестирования, а также регистры математиче- ского сопроцессора, выполняющего операции с плавающей точ- кой. В процессоре Pentium имеется восемь 32-разрядных регистров общего назначения. Четыре из них, которые можно условно назвать
А, В. С и D, используются для временного хранения операндов ариф- метических, логических и других команд. Программист может обра- щаться к этим регистрам как к единому целому, используя обозна- чения EAX, ЕВХ, ЕСХ, EDX, а также к некоторым их частям, как это показано на рис. 7.4. Здесь обозначение AL (L — Low) относится к первому, самому младшему байту регистра ЕАХ, АН (Н — High) — к следующему по старшинству байту, а АХ обозначает оба младших байта регистра Приставка Е в обозначении этих регистров (а также некоторых других) образована от слова «extended» (расширенный), что указывает на то, что в прежних моделях процессоров Intel эти регистры были 16-разрядными, а затем их разрядность была увели- чена до 32 бит. Регистры сегментов Регистры обшего назначения Указатель инструкций и регистр флагов IP FLAGS EIP EFLAGS 31 16 15 О Рис. 7.4 Основные регистры процессора Pentium (программная модель) Остальные четыре регистра общего назначения — ESI, EDI, EBP и ESP — предназначены для задания смещения адреса относительно начала некоторого сегмента данных. Эти регистры используются совместно с регистрами сегментов в системе адресации процессора Pentium для задания виртуального адреса, который затем с помощью таблиц страниц отображается на физический адрес.
Регистры сегментов CS, SS, DS, ES, FS и GS в защищенном ре- жиме ссылаются на дескрипторы сегментов памяти — описатели, в которых содержатся такие параметры сегментов, как базовый адрес, размер сегмента, атрибуты защиты и некоторые другие. Ре- гистры сегментов хранят 16-разрядное число, называемое селекто- ром, в котором 12 старших разрядов представляют собой индекс в таблице дескрипторов сегментов, 1 разряд указывает, в какой из двух таблиц, GDT (Global Descriptor Table) или LDT (Local De- scriptor Table), находится дескриптор, а три разряда поля RPL (Re- quested Privilege Level) хранят значение уровня привилегий запроса к данному сегменту Регистр CS (Code Segment) предназначен для хранения индекса дескриптора кодового сегмента, регистр SS (Stack Segment) — дескриптора сегмента стека, а остальные регистры ис- пользуются для указания на дескрипторы сегментов данных. Все регистры сегментов, кроме CS, программно доступны, т.е. в них можно загрузить новое значение селектора соответствующей коман- дой. Значение регистра CS изменяется при выполнении команд меж- сегментных вызовов call и переходов JMP, а также при переключе- нии задач. Указатель инструкций EIP содержит смещение адреса текущей инструкции, которое используется совместно с регистром CS для получения соответствующего виртуального адреса. Регистр флагов EFLAGS содержит признаки, характеризующие результат выполнения операции, например флаг знака, флаг нуля, флаг переполнения, флаг паритета, флаг переноса и некоторые дру- гие. Кроме того, здесь хранятся некоторые признаки, устанавлива- емые и анализируемые механизмом прерываний, в частности флаг разрешения аппаратных прерываний IF. В процессоре Pentium имеется пять управляющих регистров — CRO, CR1, CR2, CR3 и CR4, которые хранят признаки и данные, характеризующие общее состояния процессора (рис. 7.5). Регистр CRO содержит все основные признаки, существенно влияющие на работу процессора, такие как рсальный/защищенный режим работы, включение/выключение страничного механизма сис- темы виртуальной памяти, а также признаки, влияющие на работу кэша и выполнение команд с плавающей точкой. Младшие два байта регистра CRO имеют название Mashine State Word, MSW — «слово состояния машины». Это название использовалось в процессоре 80286 для обозначения управляющего регистра, имевшего аналогич- ное назначение. Регистр CR1 в настоящее время не используется (зарезервирован).
11 j : 11«4 ____Адрес таблицы разделов страниц CR3 ____Линейный адрес стр ничнсго отказа CR3 CR1 II , TllTlIcRO 31 16I 15 О MSW Линейные базовые адреса 47 _____________16 15_______Границы_____О GDTR I IDTR ” ТЕ I DTR 15 Селекторы 0 32-оазрядные 32-разрядные линейные адреса_____границы_____Атрибуты Дескрипторные регистры (загружаются автоматически) Системные сегментные регистры Рис. 7.5. Управляющие и системные регистры процессора Pentium Регистры CR2 и CR3 предназначены для поддержки работы сис- темы виртуальной памяти. Регистр CR2 содержит линейный вирту- альный адрес, который вызвал так называемый страничный отказ (отсутствие страницы в оперативной памяти или отказ из-за нару- шения прав доступа). Регистр CR3 содержит физический адрес таб- лицы разделов, используемой страничным механизмом процессора. В регистре CR4 хранятся признаки, разрешающие работу так на- зываемых архитектурных расширений, например возможности ис- пользования страниц размером 4 Мбайт и т.п. Регистры системных адресов содержат адреса важных системных таблиц и структур, используемых при управлении процессами и па- мятью. Регистр GDTR (Global Descriptor Table Register) содержит физический 32-разрядный адрес глобальной таблицы дескрипторов GDT сегментов памяти, образующих общую часть виртуального адресного пространства всех процессов. Регистр IDTR (Interrupt De- scriptor Table Register) хранит физический 32-разрядный адрес таб- лицы дескрипторов прерываний IDT, используемой для вызова про- цедур обработки прерываний в защищенном режиме работы процес- сора. Кроме этих адресов, в регистрах GDTR и IDTR хранятся 16-битные лимиты, задающие ограничения на размер соответству- ющих таблиц. Два 16-битных регистра хранят не физические адреса системных структур, а значения индексов дескрипторов этих структур в таблице
GDT, что позволяет косвенно получить соответствующие физиче- ские адреса. Регистр TR (Task Register) содержит индекс дескриптора сегмента состояния задачи TSS (Task State Segment). Регистр LDTR (Local Descriptor Table Register) содержит индекс дескриптора сег- мента локальной таблицы дескрипторов LDT сегментов памяти, образующих индивидуальную часть виртуального адресного про- странства процесса. Регистры отладки хранят значения точек останова, а регистры тестирования позволяют проверить корректность работы внутренних блоков процессора. 7.5. Системные функции MS DOS и BIOS Обращение к системным функциям DOS и BIOS осуществляется с помощью программных прерываний (команда inf). В начале оперативной памяти от адреса OOOOh до O3ffh располага- ется таблица векторов прерываний, в которой под каждый вектор прерывания отводится 4 байта, содержащих адрес программы обра- ботки прерывания (ПОП). В два старших байта каждого вектора за писывается сегментный адрес ПОП, в два младших — относитель- ный адрес точки входа в ПОП в сегменте. Векторы, как и соответ ствующие им прерывания, имеют номера, называемые типами, причем вектор с номером 0 (вектор типа 0) располагается начиная с адреса 0, вектор типа 1 — с адреса 4, вектор типа 2 — с адреса 8 и т.д. Вектор с номером N занимает, таким образом, байты памяти от Wx 4 до №х 4 + 3. Всего в выделенной на векторы прерывания области памяти помещаются 256 векторов. Получив сигнал на выполнение процедуры прерывания с опре- деленным номером, процессор сохраняет в стеке выполняемой прог- раммы слово флагов, а также сегментный и относительный адрес сегмента команд (содержимое CS и IP) и загружает CS и IP из соот ветствующего вектора прерываний, осуществляя тем самым переход на ПОП (рис 7.6). Программа обработки прерывания обычно заканчивается коман- дой возврата из прерывания iret, выполняющей обратные действия — загрузку CS и IP и регистра флагов из стека, что приводит к возврату в основную программу, в точку, где она была прервана. Запросы на выполнение процедуры прерываний могут иметь раз- личную природу. Прежде всего различают аппаратные прерывания от периферийных устройств или других компонентов системы и программные прерывания, вызываемые командой int, которая ис
Адреса Рис. 7.6. Процедура прерывания пользуется, в частности, для обращения к функциям DOS и BIOS. Сигналы, вызывающие аппаратные прерывания, могут иницииро- ваться самим процессором, например, при попытке деления на О, а могут приходить и от внешних устройств. Независимо от источника прерывания процедура обработки прерывания, описанная выше, всегда выполняется одинаково как для аппаратных, так и для прог- раммных прерываний. Большая часть векторов прерываний зарезервирована для выпол- нения определенных действий, часть из них автоматически заполня- ется адресами системных программ при запуске системы. Векторы прерываний можно условно разбить на следующие группы: • векторы аппаратных прерываний (08h—OFh, 70h-77h); • функции BIOS (10h, 13h, 16йит.д.); • функции DOS (21 h, 22h, 23h и т.д.); • адреса системных таблиц BIOS (IDh, lEh, 43h и т.д.). Системные программы, адреса которых хранятся в векторах пре- рываний, в большинстве своем являются всего лишь диспетчерами, открывающими доступ к большим группам программ, реализующих
системные функции, например вектор 211т, через который осуще- ствляется практически вызов всех функций DOS. Обращение из прикладной программы к системным функциям осуществляется единообразно. В регистр АН записывается номер функции (не путать с типом прерывания), а в другие регистры — ис- ходные данные, необходимые для выполнения конкретной систем- ной функции. После этого выполняется команда int с числовым аргументом, указывающим тип (номер) прерывания, например int21h. Большинство функций DOS и многие функции BIOS возвращают в флаге переноса CF код завершения Если функция выполнена успешно, CF = 0, в случае же любой ошибки CF = 1. В последнем случае в одном из регистров (чаще всего в АХ) возвращается еще и код ошибки. Таким образом, типичная процедура обращения к си- стемным функциям выглядит следующим образом: MOV АН, funk ; funk - номер функции ; Заполнение тех или иных регистров (AL, ВХ, ES, ВР и др.) ; параметрами, необходимыми для выполнения данной функции INT 21h ; переход в DOS JC error ; Строка выполняется сразу ; после возврата из DOS ; Продолжение программы error: CMP AX, 1 JE errl CMP AX, 2 JE err2 ; Анализ кеда завершения Аналогично вызываются и функции BIOS. Справочный материал по функциям DOS и BIOS описан в большом числе различной лите- ратуры. Выводы В состав DOS входят следующие компоненты: • BIOS (Basic Input/ Output System) — базовая система ввода-вы- вода; • NSB (Non- System Bootstrap) — внесистемный загрузчик; • SB (System Bootstrap) — системный загрузчик; • EM BIOS (Extension Module BIOS) — модуль расширения BIOS; • внешние (устанавливаемые) драйверы устройств;
• BM DOS (Basic Module DOS) — базовый модуль DOS; • CI (Command Interpreter) — интерпретатор команд или команд- ный процессор; • утилиты DOS; • оболочка MS DOS Shell (факультативно); • инструментальные средства. Все компоненты DOS, исключая BIOS, размещены на одном или нескольких магнитных дисках в специальных областях и файлах. Один из дисков обеспечивает занесение DOS в память ПК и запуск ее в работу. Этот процесс называется загрузкой DOS, а диск, с кото- рого возможна загрузка системы, называется системным или загру- зочным. BIOS реализует наиболее простые и универсальные функции DOS по управлению стандартными (основными) периферийными устрой- ствами (ПУ), в частности по организации ввода-вывода. BIOS осво- бождает обращающиеся к ней программы и другие компоненты DOS от учета особенностей и деталей управления тем или иным ПУ. NSB обеспечивает загрузку с диска операционной системы из ак- тивного раздела диска. SB ориентирован строго на DOS и способен обеспечивать за- грузку только данной системы. Он имеется на каждом диске, подго- товленном для работы в среде DOS, даже если диск не является си- стемным. ЕМ BIOS в процессе функционирования DOS является надстрой- кой над BIOS, модифицируя и/или дополняя се возможности. При загрузке DOS данным модулем обеспечивается возможность как логической замены драйверов, хранящихся в BIOS, так и под- ключение новых драйверов. Необходимость в этом появляется при изменении конфигурации ПУ и при потребности использовать ПУ нестандартным образом. Драйверы могут находиться как внутри ЕМ BIOS, так и вне его, в отдельных файлах. В первом случае они назы- ваются внутренними (основными), а во втором — внешними (уста- навливаемыми). BM DOS — это центральный элемент DOS, реализующий основ- ные функпии операционной системы: управление ресурсами ПК и выполнением программ. Управление ПУ осуществляется на более высоком уровне — на основе организации обращения к драйверам. BM DOS также управляет и организует работу файловой системы компьютера. CI отвечает в основном за поддержку пользовательского интер- фейса DOS. CI состоит из двух модулей — резидентного и транзит-
ного. Резидентный модуль хранится после запуска DOS в оператив- ной памяти ПК, а транзитный подгружается по мере необходимости. Утилиты — это обслуживающие программы, которые предостав- ляют пользователю сервисные услуги. Большая часть утилит содер- жит внешние команды DOS, реализуемые не CI, а отдельными про- граммами. Командный файл — это текстовый файл (в коде ASCII), состоя- щий из группы команд DOS. Правила идентификации командных файлов совпадают с общими правилами идентификации файлов. Единственное исключение — командный файл всегда записывается на диск с расширением «.ВАТ» (BATch). Для удобства пользователя в системе предусмотрен специальный командный файл AUTOEXEC.BAT. Если он находится в корневом директории рабочего диска, то при загрузке DOS автоматически вы- полняются его команды. Назначение файла — экономия времени (он состоит из обычно вводимых при загрузке команд). В общем слу- чае AUTOEXEC ВАТ определяет спецификаторы пули каждого ди- ректория, назначает рабочий директорий каждого диска, а также производит загрузку управляющей программы операционной сис- темы. CONFIG.SYS — это текстовый файл, который содержит команды о конфигурации аппаратных компонентов компьютера (память, кла- виатура, «мышь», принтер и т.д.) для DOS. Другие приложения также могут использовать эту информацию. Когда DOS стартует, первыми выполняются команды, записанные в файле CONFIG.SYS Вопросы для самоконтроля 1. Перечислите основные компоненты, входящие в состав MS DOS. 2. Входят ли BIOS и NSB в состав стандартной поставки MS DOS? 3. Являются ли BIOS и NSB частью MS DOS? 4. Какой диск называется системным или загрузочным? 5. Какие задачи реализует BIOS? 6. В чем отличие между NSB и SB? 7. Какие функции выполняет ЕМ BIOS? 8. Какие драйверы называются внутренними, а какие — внешними? 9. Какой модуль MS DOS реализует основные функции операционной системы? 10. Из каких двух частей состоит командный интерпретатор? 11. Что такое утил иты? 12. Какие программы входя! в состав инструментальных средств? 13. Перечислите места расположения основных компонентов MS DOS.
14. Объясните структуру системного диска. 15. Перечислите основные этапы загрузки MS DOS и их последователь- ность. 16. Какие способы перезагрузки существуют? 17. Какие типы команд MS DOS вы знаете и почему они так называются? 18. Какое назначение командных файлов? 19. Какие команды используются при написании командных файлов? 20. Какое назначение файла AUTOEXEC ВАТ? 21. Какие команды используются при написании файла AUTOEXEC.BAT? 22. Какое назначение файла CONFIG.SYS? 23 Какие команды используются при написании файла CONFIG.SYS? 24. Каков порядок команд в файле CONFIG SYS? 25. Каким образом можно использовать несколько конфигураций в одном файле? 26. Что называется программной моделью микропроцессора? 27. Какие группы регистров входят в состав микропроцессора Pentium? 28 Какую информацию содержит регистр флагов? 29 Каким образом осуществляется обращение к системным функциям операционной системы? 30. На какие группы можно разбить векторы прерываний?
Глава 8 СЕРВИСНЫЕ ПРОГРАММНЫЕ СРЕДСТВА 8.1. Программы оболочки Какие бы работы мы ни выполняли на компьютере, нам часто приходится сталкиваться с необходимостью сохранять данные или программы в файлах на разных дисках компьютера, создавать или удалять каталоги, форматировать диски, копировать отдельные файлы или целиком каталоги, их просматривать или корректировать и выполнять многие другие вспомогательные операции. Почти все эти операции можно выполнить с помощью рассмотренных в главе 7 команд операционной системы MS DOS. Однако ввод команд связан с некоторыми трудностями: необходимо их помнить, не допускать ошибок при вводе, затрачивать время на ввод или исправление. Кроме того, не все команды предоставляют пользователю возмож- ность наглядного просмотра результатов своего выполнения. По- этому широкое распространение получили различные пакеты прог- рамм, существенно упрощающие выполнение подобных операций на компьютере. Одним из наиболее известных таких пакетов прог- рамм является пакет Norton Commander корпорации Symantec Программа-оболочка — это программа, один из модулей которой, называемый резидентным, постоянно находится в оперативной па- мяти компьютера и для выполнении каких-либо заданных пользо- вателем функций загружает с диска в свободные области памяти необходимые исполнительные модули. 8.2. Программы архивации Одним из наиболее широко распространенных видов сервисных программ являются программы, предназначенные для архивации, упаковки файлов путем сжатия хранимой в них информации. Сжатие информации — это процесс преобразования информации, хранящейся в файле, к виду, при котором уменьшается избыточность в ее представлении и, соответственно, требуется меньший объем па- мяти для хранения этой информации.
Сжатие информации производится за счет устранения избыточ- ности различными способами, например за счет упрощения кодов, исключения из них постоянных битов или представления повторя- ющихся символов или повторяющейся последовательности симво- лов в виде коэффициента повторения и соответствующих символов. Применяются различные алгоритмы подобного сжатия информации. Сжиматься могут как один, так и несколько файлов, которые в сжатом виде помещаются в так называемый архивный файл или архив. Архивный файл — это специальным образом организованный файл, содержащий в себе один или несколько файлов в сжатом или несжатом виде и служебную информацию об именах файлов, дате и времени их создания или модификации, размерах и т.п. Целью упаковки файлов обычно являются обеспечение более компактного размещения информации на диске, сокращение вре- мени и, соответственно, стоимости передачи информации по кана- лам связи в компьютерных сетях. Кроме того, упаковка в один ар- хивный файл группы файлов существенно упрощает их перенос с одного компьютера на другой, сокращает время копирования фай- лов на диски, позволяет защитить информацию от несанкциониро- ванного доступа, способствует защите от заражения компьютерными вирусами. Степень сжатия файлов характеризуется коэффициентом Кс, определяемым как отношение объема сжатого файла Ц к объему исходного файла Vq, выраженное в процентах: Kc=VJVq - 100%. Степень сжатия зависит от используемой программы, метода сжа- тия и типа исходного файла. Наиболее хорошо сжимаются файлы графических образов, текстовые файлы, файлы данных, для которых степень сжатия может достигать 5—40%; меньше сжимаются файлы исполняемых программ и загрузочных модулей — 60—90%. Почти не сжимаются архивные файлы. Программы для архивации отлича- ются используемыми методами сжатия, что соответственно влияет на степень сжатия. Архивация (упаковка) — помещение (загрузка) исходных файлов в архивный файл в сжатом или несжатом виде. Разархивация (распаковка) — процесс восстановления файлов из архива точно в таком виде, какой они имели до загрузки в архив. При распаковке файлы извлекаются из архива и помешаются на диск или в оперативную память.
Программы, осуществляющие упаковку и распаковку файлов, называются программами - архиваторами. Большие по объему архивные файлы могут быть размешены на нескольких дисках (томах). Такие архивы называются многотом- ными. Том — это составная часть многотомного архива. Создавая архив из нескольких частей, можно записать его части на несколько дискет. Программы-архиваторы позволяют создавать и такие архивы, для извлечения из которых содержащихся в них файлов нс требуются какие-либо программы, так как сами архивные файлы могут содер- жать программу распаковки. Такие архивные файлы называются са- мораспаксвывающимися. Самораспаковывающийся архивный файл — это загрузочный, ис- полняемый модуль, который способен к самостоятельной разархи- вации находящихся в нем файлов без использования программы- архиватора. Самораспаковывающийся архив получил название SFX-архив (SelF-eXtracting), и такие архивы обычно создаются в форме ЕХЕ-файла. Многие программы-архиваторы производят распаковку файлов, выгружая их на диск, но имеются и такие, которые предназначены для создания упакованного исполняемого модуля (программы). В ре- зультате такой упаковки создается программный файл с теми же име- нем и расширением, который при загрузке в оперативную память самораспаковывается и сразу запускается. Вместе с тем возможно и обратное преобразование программного файла в распакованный формат. 8.3. Антивирусные программы 8.3.1. Вирусы Компьютерным вирусом называется специально написанная прог- рамма, способная самопроизвольно присоединяться к другим прог- раммам, создавать свои копии и внедрять их в файлы, системные области компьютера и в вычислительные сети с целью нарушения работы программ, порчи файлов и каталогов, создания всевозмож- ных помех в работе на компьютере. Причины появления и распространения компьютерных вирусов, с одной стороны, скрываются в психологии человеческой личности и ее теневых сторонах (зависти, мести, тщеславии непризнанных
творцов, невозможности конструктивно применить свои способ- ности); с другой стороны, обусловлены отсутствием аппаратных средств защиты и противодействия со стороны операционной сис- темы персонального компьютера. Несмотря на принятые во многих странах законы о борьбе с ком- пьютерными преступлениями и разработку специальных прог- раммных средств защиты от вирусов, количество новых прог- раммных вирусов постоянно растет. Это требует от пользователя персонального компьютера знаний о природе вирусов, способах заражения вирусами и защиты от них. Основными путями проникновения вирусов в компьютер явля- ются съемные диски (гибкие и лазерные), а также компьютерные сети. Заражение жесткого диска вирусами может произойти при за- грузке компьютера с дискеты, содержащей вирус. Такое заражение может быть и случайным, например если дискету не вынули из дис- ковода А и перезагрузили компьютер, при этом дискета может и не быть системной. Заразить дискету гораздо проще. На нее вирус может попасть, даже если дискету просто вставили в дисковод зара- женного компьютера и, например, прочитали ее оглавление. Зараженный диск — это диск, в загрузочном секторе которого на- ходится программа-вирус. После запуска программы, содержащей вирус, становится воз- можным заражение других файлов. Наиболее часто вирусом заража- ются загрузочный сектор диска и исполняемые файлы, имеющие расширения EXE, COM, SYS или ВАТ. Крайне редко заражаются текстовые и графические файлы. Зараженная программа — это программа, содержащая внедрен- ную в нее программу-вирус. При заражении компьютера вирусом очень важно своевременно его обнаружить. Для этого следует знать об основных признаках про- явления вирусов. К ним можно отнести следующие признаки: • прекращение работы или неправильная работа ранее успешно функционировавших программ; • медленная работа компьютера; • невозможность загрузки операционной системы; • исчезновение файлов и каталогов или искажение их содержи- мого; • изменение даты и времени модификации файлов; • изменение размеров файлов; • неожиданное значительное увеличение количества файлов на диске;
• существенное уменьшение размера свободной оперативной па- мяти; • вывод на экран непредусмотренных сообщений или изображе- ний; • подача непредусмотренных звуковых сигналов; • частые зависания и сбои в работе компьютера. По способу заражения вирусы делятся на резидентные и нерези- дентные. Резидентный вирус при заражении (инфицировании) ком- пьютера оставляет в оперативной памяти свою резидентную часть, которая потом перехватывает обращение операционной системы к объектам заражения (файлам, загрузочным секторам дисков и т.п.) и внедряется в них. Резидентные вирусы находятся в памяти и явля- ются активными вплоть до выключения или перезагрузки компью- тера. Нерезидентные вирусы не заражают память компьютера и явля- ются активными ограниченное время. По степени воздействия вирусы можно разделить на следующие виды: • неопасные, не мешающие работе компьютера, но уменьшающие объем свободной оперативной памяти и памяти на дисках, дей- ствия таких вирусов проявляются в каких-либо графических или звуковых эффектах; • опасные, которые могут привести к различным нарушениям в ра- боте компьютера; • очень опасные, воздействие которых может привести к потере программ, уничтожению данных, стиранию информации в сис- темных областях диска. По особенностям алгоритма вирусы трудно классифицировать из-за большого разнообразия Про- стейшие вирусы — паразитические, они изменяют содержимое файлов и секторов диска и могут быть достаточно легко обнару- жены и уничтожены. Можно отметить вирусы-репликаторы, на- зываемые червями, которые распространяются по компьютерным сетям, вычисляют адреса сетевых компьютеров и записывают по этим адресам свои копии. Известны вирусы-невидимки, назы- ваемые стеле-вирусами, которые очень трудно обнаружить и обез- вредить, так как они перехватывают обращения операционной системы к пораженным файлам и секторам дисков и подставляют вместо своего тела незараженные участки диска. Наиболее трудно обнаружить вирусы-мутанты, содержащие алгоритмы шиф- ровки-расшифровки, благодаря которым копии одного и того же вируса не имеют ни одной повторяющейся цепочки байтов. Име- ются и так называемые квазивирусные или «троянские» прог-
раммы, которые хотя и не способны к самораспространению, но очень опасны, так как, маскируясь под полезную программу, разрушают загрузочный сектор и файловую систему дисков 8.3.2. Характеристика антивирусных программ Для обнаружения, удаления и защиты от компьютерных вирусов разработано несколько видов специальных программ, которые по- зволяют обнаруживать и уничтожать вирусы. Такие программы на- зываются антивирусными. Различают следующие виды антивирусных программ: • программы-детекторы; • программы-доктора или фаги; • протраммы-ревизоры; • программы-фильтры; • программы-вакцины или иммунизаторы. Программы-детекторы осуществляют поиск характерной для кон- кретного вируса последовательности байтов (сигнатуры вируса) в оперативной памяти и в файлах и при обнаружении выдают соот- ветствующее сообщение. Недостатком таких антивирусных программ является то, что они могут находить только те вирусы, которые из- вестны разработчикам таких программ. Программы-доктора или фаги, а также программы-вакцины не только находят зараженные вирусами файлы, но и «лечат» их, т.е. удаляют из файла тело программы-вируса, возвращая файлы в исходное состояние. В начале своей работы фаги ищут вирусы в оперативной памяти, уничтожая их, и только затем переходят к «ле- чению» файлов. Среди фагов выделяют полифаги, т.е. программы- доктора, предназначенные для поиска и уничтожения большого ко- личества вирусов. Наиболее известными полифагами являются прог- раммы Aidsrest, Scan, Norton Anti Virus и Doctor Web Учитывая, что постоянно появляются новые вирусы, программы- детекторы и программы-доктора быстро устаревают и требуется ре- гулярное обновление их версий. Программы-ревизоры относятся к самым надежным средствам за- щиты от вирусов. Ревизоры запоминают исходное состояние прог- рамм, каталогов и системных областей диска тогда, когда компьютер не заражен вирусом, а затем периодически или по желанию пользо- вателя сравнивают текущее состояние с исходным. Обнаруженные изменения выводятся на экран видеомонитора. Как правило, срав- нение состояний производят сразу после загрузки операционной системы. При сравнении проверяются длина файла, код цикличе-
ского контроля (контрольная сумма файла), дата и время модифи- кации, другие параметры. Программы-ревизоры имеют достаточно развитые алгоритмы, обнаруживают стелс-вирусы и могут даже от- личить изменения версии проверяемой программы от изменений, внесенных вирусом. К числу программ-ревизоров относится широко распространенная в России программа ADinf фирмы «Диалог-На- ука». Программы-фильтры или «сторожа» представляют собой неболь- шие резидентные программы, предназначенные для обнаружения подозрительных действий при работе компьютера, характерных для вирусов. Такими действиями могут являться: • попытки коррекции файлов с расширениями СОМ и EXE; • изменение атрибутов файлов; • прямая запись на диск по абсолютному адресу; • запись в загрузочные сектора диска; • загрузка резидентной программы. При попытке какой-либо программы произвести указанные дей- ствия «сторож» посылает пользователю сообщение и предлагает за- претить или разрешить соответствующее действие. Программы- фильтры весьма полезны, так как способны обнаружить вирус на са- мой ранней стадии его существования до размножения Однако они не «лечат» файлы и диски. Для уничтожения вирусов требуется при- менить другие программы, например фаги К недостаткам про- грамм-сторожей можно отнести их «назойливость» (например, они постоянно выдают предупреждение о любой попытке копирования исполняемого файла), а также возможные конфликты с другим программным обеспечением. Примером программы-фильтра явля- ется программа Vsafe, входящая в состав пакета утилит операцион- ной системы MS DOS. Вакцины или иммунизаторы — это резидентные программы, пред- отвращающие заражение файлов Вакцины применяют, если отсут- ствуют программы-доктора, «лечащие» этот вирус. Вакцинация воз- можна только от известных вирусов. Вакцина модифицирует прог- рамму или диск таким образом, чтобы это не отражалось на их работе, а вирус будет воспринимать их зараженными и поэтому не внедрится В настоящее время программы-вакцины имеют огра- ниченное применение. Своевременное обнаружение зараженных вирусами файлов и дисков, полное уничтожение обнаруженных вирусов на каждом компьютере позволяют избежать распространения вирусной эпиде- мии на другие компьютеры.
8.4. Диагностические программы Когда в работе компьютера возникает проблема, для ее решения следует прежде всего понять, в чем она состоит. Чем раньше и чем точнее проблема будет выявлена, тем меньше будет отрицательный эффект и тем проще будет привести компьютер в норму. Для диагнос- тики компьютера можно использовать как стандартные средства опе- рационной системы, так и специальные диагностические программы. 8.4.1. Стандартные средства диагностики Работа по устранению неполадки в работе компьютера осуще- ствляется в два этапа. На первом этапе выполняется локализация неисправности, а на втором этапе — ее устранение, так как устранить неисправность можно только в том случае, если известно, чем она вызвана. Самым трудным обычно оказывается первый этап — диаг- ностический, так как любая неисправность может быть вызвана це- лым рядом различных причин. Для помощи в диагностике неисправности в современных опера- ционных системах предусмотрен целый ряд инструментов, которые позволят облегчить эту работу. Рассмотрим их работу на примере операционной системы Windows ХР. Для решения этой задачи в операционной системе Windows ХР можно использовать следующие инструменты: • сведения о системе; • справочную систему; • средства диагностики DirectX; • диагностику сети; • восстановление системы; • доктор Ватсон. Сведения о компьютерной системе. Программа «Сведения о сис- теме» является информационным центром, обобщающим разнооб- разные сведения о компьютерной системе. Все сведения разделены на категории. Каждую категорию можно развернуть и получить до- ступ к ее подкатегориям. Для поиска неполадок могут быть использованы категории «Ре- сурсы аппаратуры» и «Компоненты». В категории «Ресурсы аппаратуры» с помощью подкатегории «Конфликты»/«Совместное использование» можно посмотреть дан- ные об устройствах, использующих общие ресурсы, такие как каналы DMA (direct memory access — прямой доступ к памяти), линии IRQ и адреса памяти.
Как правило, совместное использование ресурсов нс приводит к сбоям, однако исследование потенциальных конфликтов может помочь при устранении неполадок. Если устройство работает непра- вильно, необходимо изучить данные о возможных конфликтах со- вместного использования Найти это устройство в области сведений в столбце «Устройство», а затем определить используемый ресурс по столбцу «Ресурс». Устройства, совместно использующие один и тот же ресурс, можно обнаружить по одинаковым значениям, ото- бражающимся в столбце «Ресурс». Например, это могут быть два адаптера, которые используют одну и ту же линию запроса прерыва- ния, такую как IRQ5. Если неправильно работающее устройство раз- деляет ресурс с другим устройством, неполадку можно объяснить конфликтом устройств. Для устранения неполадки можно восполь- зоваться диспетчером устройств. Узнать о проблемах в работе устройств позволяет и подкатегория «Устройства с неполадками», категории «Компоненты». В ней ото- бражаются данные об устройствах, в работе которых имеются непо- ладки, в том числе код устройства и код ошибки. Для обнаружения и устранения неполадок в работе устройств следует использовать диспетчер устройств. Программа «Сведения о системе» запускается командой Пуск —> Программы —> Стандартные —> Служебные —> Сведения о системе. Средства диагностики DirectX. Если установленная программа ис- пытывает проблемы с воспроизведением графики и звука, то поиск неполадок следует начинать с проверки работоспособности библио- теки DirectX. Средство диагностики DirectX вызывается из прог- раммы Сведения о системе —> Сервис —> Средство диагностики DirectX. Каждому компоненту библиотеки DirectX соответствует отдельная вкладка, которая предназначена для проверки данного компонента и частичной его настройки. Все тесты компонентов библиотеки Di- rectX носят интерактивный характер. Пользователь сам оценивает, насколько правильно выглядит и звучит то, что он видит и слышит. Доктор Ватсон. Программа «Доктор Ватсон» предназначена для перехвата и анализа сбоев в работе операционной системы и прог- рамм. При сбое создается «снимок», образ текущего состояния сис- темы и выдается описание возможной причины сбоя. Этот снимок можно использовать для выявления и устранения возникшего сбоя. Программа «Доктор Ватсон» вызывается из программы Сведения о системе —> Сервис —> Доктор Ватсон. Диагностика сети. С помощью средства «Диагностика сети» можно проверить все сетевые функции компьютера. Результаты тес-
тирования выдаются на экран монитора и могут быть сохранены в файле на Рабочем столе и в служебной папке операционной сис- темы. Имя файла выбирается автоматически. Диагностика сети может быть запущена из программы Сведения о системе —> Сервис —> Диагностика сети Восстановление системы. С помощью средства «Восстановление системы», при возникновении проблем можно восстановить преды- дущее состояние компьютера без потери личных файлов (таких как документы Microsoft Word, перечень просмотренных страниц, ри- сунки, избранные файлы и сообщения электронной почты). Прог- рамма «Восстановление системы» ведет наблюдение за изменениями системы и некоторыми файлами приложений и автоматически со- здает легко идентифицируемые точки восстановления. Эти точки восстановления позволяют вернуть систему к состоянию на данный момент времени. Они создаются ежедневно, а также во время суще- ственных системных событий (таких как установка приложения или драйвера). Пользователь также имеет возможность в любое время создавать именованные точки восстановления. Восстановление системы может быть запущено из программы Сведения о системе Сервис Восстановление системы. Справочная система. Справочная система Windows ХР включает в себя диалоговую систему поиска и устранения неисправностей. Система диалогового поиска и устранения неисправностей вызыва- ется с помощью команды Пуск Справка и поддержка —> Устранение неполадок. Система поиска неисправностей предлагает список возможных причин неполадок и для каждого варианта предлагает свой порядок их устранения, но в основном это элементарные неисправности, и система может помочь только в том случае, если возникшая не- исправность присутствует в предложенном списке. 8.4.2. Внешние средства диагностики Если необходимо получить исчерпывающую информацию о ком- пьютере и выполнить профессиональное тестирование его отдельных компонентов, обычных инструментов операционной системы недо- статочно. Для этого следует обратиться к специальным диагности- ческим программам, не входящим в состав операционной системы. Таких средств много, и все они делают одну и ту же работу, хотя не- большие функциональные различия в них есть. Эти программы спо- собны провести глубокую диагностику компьютера, дать исчерпы- вающие сведения о его устройствах, операционной системе и црог-
раммах, а также предложить варианты оптимизации системы или улучшения аппаратной конфигурации, если это необходимо. Все диагностические программы можно разделить на специали- зированные, рассчитанные на диагностику определенного типа обо- рудования, и интегрированные, которые включают в себя большой набор различных диагностических программ, позволяющих провести диагностику компьютера в целом. Специализированные диагностические программы обычно выпус- каются фирмами, разрабатывающими различное оборудование для компьютеров. Например, винчестеры, материнские платы или мо- ниторы. Такие программы обычно используются для профессио- нальной диагностики оборудования. Интегрированные средства позволяют диагностировать работу компьютера в целом, собрать сведения с системе и выполнить диаг- ностику отдельных составляющих по желанию пользователя. Также они позволяют получить сведения о производительности компью- тера и дать рекомендации по его настройке. 8.5, Утилиты Утилиты — это специализированные программы, предназна- ченные для обслуживания и оптимизации работы компьютера и рас- ширения и дополнения возможностей установленной операционной системы. Утилиты можно классифицировать по функциональному назна чению: • программы контроля тестирования и диагностики, которые ис- пользуются для сбора информации о системе, проверки устройств компьютера, поиска неисправности и помощи в ее устранении; • програм мы-архиваторы, которые позволяют записывать инфор- мацию на различные носители более плотно, чем в обычном представлении, а также объединять копии нескольких файлов в один архивный файл; • антивирусные программы, предназначенные для защиты компью- тера от компьютерных вирусов; • программы оптимизации и контроля качества дискового про- странства; • программы восстановления информации, форматирования, защиты данных: • коммуникационные программы, организующие обмен информа- цией между компьютерами;
• программы для управления памятью, обеспечивающие более гиб- кое использование оперативной памяти; • программы для записи CD-ROM, DVD-ROM и многое другое. Часть утилит входит в состав операционной системы, а другая часть функционирует независимо от нее, т.е. автономно. Многие автономные утилиты представляют собой серьезные ком- мерческие продукты, но большинство утилит, относящихся к разряду условно-бесплатного программного обеспечения (shareware), можно найти в свободном доступе в сети Интернет. Назначение и принцип работы большей части утилит были рас- смотрены в данной главе.
список РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ 1. Богумирский Б.С. Руководство пользователя ПЭВМ [Текст]: в 2 ч. / Б.С. Богумирский. СПб.: Ассоциация OILCO, 1992 357 с. 2. Дейтел Г. Введение в операционные системы [Текст]: в 2 т. / цер. с ангд. Л.А. Теплицкого, А.Б. Ходулева, В.С. Штаркмана; подред. В.С. Штарк- мана/ Г. Дейтел. М.: Мир, 1987. 3. Олифер Н.Д., Сетевые операционные системы [Текст] / Н.А. Олифер, В.Г. Олифер. СПб.: Питер, 2001. 4. Рейчард К., UNIX [Текст]: справочник/ К. Рейчард, Э. Фостер-Джон- сон. СПб . Питер, 2000. 384 с. 5. Ресурсы Microsoft Windows NT Workstation 4.0: пер. с англ. СПб.: BHV, 1998. 800 с. 6. Робачевский А.М. Операционная система UNIX [Текст] / А.М. Робачев- ский. СПб.: BHV, 1997. 528 с. 7. Соловоев Г.Н., Операционные системы ЭВМ [Текст]: учеб, пособие / Г.Н Соловьев, В.Д. Никитин. М. Высшая школа, 1989. 255 с.
ОГЛАВЛЕНИЕ ПРЕДИСЛОВИЕ ...............................3 ВВЕДЕНИЕ......................................................5 Глава 1. ЭВОЛЮЦИЯ ОПЕРАЦИОННЫХ СИСТЕМ И ИХ КЛАССИФИКАЦИЯ................................................6 1.1. Системное программное обеспечение............................6 1.2. Появление первых операционных с и сем........................8 1.3. Появление первых мультипрограммных операционных систем......10 1.4. Появление первых операционных сисем для глобальных сетей....13 1.5. Операционные системы мини-компью’еров и первые локальные сети....................................................... 14 1.6. Развитие операционных систем в конце XX века............... 16 1.7. Особенности современного этапа раззития операционных систем.21 1.8. Классификация операционных сисем............................22 1 .8.1. Особенности алгоритмов управления ресурсами.........22 1 8.2. Особенности аппаратных платформ......................25 1 8.3. Особенности областей использования...................26 1 .8.4 Особенности методов построения.......................28 Выводы...........................................................30 Вопросы для самоконтроля.........................................32 Глава 2. НАЗНАЧЕНИЕ И ФУНКЦИИ ОПЕРАЦИОННОЙ СИСТЕМЫ..........................................................зз 2.1. Операционные системы автономного компьютера.................33 2.1.1. Расширенная виртуальная машина ......................34 2.1.2. Управление ресурсами................................ 35 2.2. Основные функции операционной сисемы автономного компью тера ...............................................36 2.2.1. Управление процессами................................36 2.2.2. Управление памятью...................................33 2.2.3. Управление файлами и внешними устройствами...........39 2.2.4. Защита данных и администрирование....................40 2.2.5. Интерфейс прикладного программирования...............41 2.2.6. Пользовательский интерфейс...........................41 2.3. Сетевые операционные системы................................42
2.3.7. Функциональные компоненты сетевой операционной системы....44 2.3.2. Сетевые службы и сетевые сервисы.....................46 2.3.3. Встроенные сетевые службы и сетевые оболочки.........46 2.3.4. Одноранговые и серверные сетевые операционные системы..48 2.3.5. Операционные системы в одноранговых сетях............49 2.3.6. Операционные системы в сетях с выделенными серверами...50 2.4. Требования к современным операционным системам..............52 Выводы...........................................................54 Вопросы для самоконтроля.........................................56 Глава 3. АРХИТЕКТУРА ОПЕРАЦИОННОЙ СИСТЕМЫ........................58 3.1. Ядро и вспомогательные модули операционной системы ....... 58 3.2. Ядро в привилегированном режиме........................... е>0 3.3. Многослойная структуре операционной системы ................63 3.4. Аппаратная зависимость и переносимость операционных систем....66 3.4.7. Типовые средства аппаратной поддержки операционной системы.....................................................67 3 4.2. Машинно зависимые компоненты операционной системы.69 3.4.3. Переносимость операционной система!..................70 3.5. Микроядерная архитектура....................................71 3.5.7. Преимущества и недостатки микроядерной архитектуры.....73 3.6. Совместимости и множественные прикладные среды..............75 3 6.7. Двоичная совместимость и совместимость исходных текстов.....................................................75 3.6.2. Трансляция библиотек.................................76 3.6.3. Способы реализации прикладных программных соед . ... 77 Выводы...........................................................81 Вопросы для самоконтроля.........................................82 Глава 4. ПРОЦЕССЫ И ПОТОКИ 85 4.1. Планирование процессов и потоков............................85 4.7.7. Понятия «процесс» и «поток»..........................85 4.7.2. Назначение подсистемы управления процессами и потоками.86 4.7.3. Создание процессов и потоков.........................87 4 7.4. Планирование и диспетчеризация потоков............88 4 1.5 Состояния потока......................................90 4.7.6. Вытесняющие и невытесняющие алгоритмы планирования.....91 4.7.7. Алгоритмы планирования, основанные на квантовании....92 4.7.8. Алгоритмы планирования, основанные на приоритетах......94 4.7.9. Смешанные алгоритмы планирования.....................97 4.1.10. Планирование в системах реального времени...........98
4. J. 11. Моменты перепланировки ............................. 99 4.2. Мультипрогоаммироаание на основе прерываний......................ют 4.2.7. Назначение и типы прерываний.............................101 4.2.2. Механизм прерываний......................................103 4.2.3. Программные прерывания...................................107 4.2.4. Диспетчеризация и приоритезация прерываний в ОС..........108 4.25. Системные вызовы.........................................109 4.3. Синхронизация процессов и потоков...............................112 4 3.7. Цели и средства синхронизации...........................112 4 3.2. необходимосто синхронизации и гонки .....................113 4.3.3. Критическая секция и блокирующие переменные..............115 4.3.4. Семафоры.................................................118 4.3.5. Тупики...................................................120 Вывопы................................................................121 Вопросы для самоконтроля..............................................123 Глава 5. УПРАВЛЕНИЕ ПАМЯТЬЮ ..........................................126 5.1. Функции операционной системы по управлению памятью..............126 5.2. Типы адресов....................................................127 5.3. Ал'оритмы распределения памяти..................................134 5 3.7 Распределение памяти фиксированными разделами............................ 134 5 3.2. Распределение памяти динамическими разделами.............136 5.3.3. Перемещаемые разделы.....................................138 5.4. Свопинг и виртуальная память ............................. 139 5.4.7. Сегментное распределение памяти..........................140 5.4.2. Страничное распределение памяти..........................145 5.4.3. Сегментно-страничный способ организации памяти...........149 5.5. Разделяемые сегменты памяти ................................. 152 5.6. Кэширование данных..............................................154 5 6 7. Иерархия запоминающих устройств............................................................... 154 5 6.2. Кэш-память...............................................156 5.6.3. Принцип действия кэш-памяти..............................157 5 6.4. Проблема согласования данных ............................159 5.6.5. Способы отобоажения основной памяти на кэш . . .160 Выводы................................................................164 Вопросы для самоконтроля..............................................166 Глава б. ВВОД-ВЫВОД И ФАЙЛОВАЯ СИСТЕМА................................168 6.1. Функции операционной системы по управлению файлами и устройствами........................................................169
6.1.1. Организация параллельной работы устройств ввода-вывода и процессора...............................................169 6.1.2. Согласование скоростей обмена и кэширование данных..170 6.1.3. Разделение устройств и данных между процессами.......171 6.1.4. Обеспечение удобного логического интерфейса между устройствами и остальной частью системы ....................172 6.1.5. Поддержка широкого спектра драйверов и простота включения нового драйвера в систему.........................172 6 1.6. Динамическая загрузка и выгрузка драйверов........173 б. / .7. Поддержка нескольких файловых систем.............174 6 1.8. Поддержка синхронных и асинхронных операций евода-вывода.... 174 6.2. Многослойная модель подсистемы ввода-вывода.................175 6.3. Логическая организация файловой системы.....................178 6.3.1. Цели и задачи файловой системы................... 178 6.3.2. Типы файлов.........................................180 6.3.3. Иерархическая структура файловой системы............181 6.3.4. Имена файлов........................................182 6.3.5. Атрибуты файлов.....................................184 6.3.6. Логическая организация файла........................136 6.4. Физическая ооганизация файловой системы................... 189 6.4.1 . Диски, разделы, секторы, класт,еры..................189 6.4.2 Физическая организация и адресация файла..............195 6 4.3. Физическая организация FAT ......................200 6 .4.4. Физическая организация $5 и ufs..................211 6.4.5 .Физическая организация NTFS.........................215 6.5 Файловые операции......................................... 226 6 6 Контрог ь доступа к файлам.............................228 Выводы......................................................... 231 Вопросы для самоконтроля........................................232 Глава 7. ДИСКОВАЯ ОПЕРАЦИОННАЯ СИСТЕМА MS DOS...................234 7.1. Принципы построения и функционирования MS DOS..............234 7.1.7. Структура MS DOS....................................234 7 1.2. Структура системного диска.......................238 7.7.3. Загрузка и перезагрузка DOS.........................242 7.2. Командный файл ............................................246 7.2.7. Что такое командный файл?...........................247 7.2.2. Организация командного файла .......................247 7.2.3. Замещаемые параметры................................249 7.2.4. Замещаемые параметры и замещаемые символы...........250 7.2.5. Команды, используемые в командных файлах............251
7.2.6. Файл AUTOEXEC.BAT................................254 7.3. Конфигурационные файлы..................................266 7.3.7. Использование команд в файле CONFIG.SYS для конфигурирования системы........................... 267 7.3.2. Конфигурирование аппаратных устройств............269 7 3.3. Определение порядка команд в файле CONFIG.SYS.269 7.3.4. Подтверждение выполнения каждой команды файла CONFIG.SYS..............................................272 7.3 5. Использование нескольких конфигураций...........273 7.4. Программная модель микропроцессора......................277 7.5. Системные функции MS DOS и 3IOS.........................281 Выводы.......................................................283 Вопросы для самоконтроля.....................................285 Глава 8. СЕРВИСНЫЕ ПРОГРАММНЫЕ СРЕДСТВА......................287 8.1. Программы оболочки..................................... 287 8.2. Программы архивации.....................................287 8.3. Антивирусные программы..................................289 8.3.1. Вирусы...........................................289 8.3.2. Характеристика антивирусных программ.............292 8.4. Диагностические программы...............................294 S .4.1 Стандартные средства диагностики................294 8 4.2. Внешние средства диагностики....................296 8.5. Утилиты................................................ 297 СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ..............................299