Лекция 8 МОДУЛЬ 2 АРХИТЕКТУРА И МЕХАНИЗМЫ ОПЕРАЦИОННЫХ

Лекция 8 МОДУЛЬ 2. АРХИТЕКТУРА И МЕХАНИЗМЫ ОПЕРАЦИОННЫХ СИСТЕМ

3. Варианты архитектуры операционных систем 2

3. 1. Классическая архитектура ОС ОС, как и любая другая сложная система, должна иметь рациональную и понятную структуру (состав частей и связи между ними), то есть удачно разделяться на части – модули, имеющие вполне законченное функциональное назначение с четко оговоренными правилами взаимодействия. Понимание роли каждого модуля ОС облегчает освоение, модификацию и развитие системы. Сложную неструктурированную систему часто даже проще разработать заново, чем модернизировать. Функциональная сложность ОС неизбежно приводит к сложности ее архитектуры, под которой обычно понимается: § структурная организация ОС на основе различных программных модулей; § логическая организация ОС с точки зрения ее пользователей. В состав ОС обычно входят: 1) исполняемые и объектные модули стандартных форматов данной ОС; 2) модули исходного текста программ; 3) библиотеки разных типов; 4) программные модули специального формата (загрузчик ОС, драйверы вводавывода); 5) конфигурационные файлы; 6) файлы документации; 7) модули справочной системы и др. Большинство современных ОС представляет собой достаточно хорошо структурированные, развиваемые, расширяемые и переносимые на новые аппаратные платформы модульные системы. А какой-то единой для всех ОС архитектуры вообще не существует, но разработчики часто используют некоторые общие подходы 3 к структурированию ОС.

Наиболее общий подход к структурированию ОС – разделение всех ее модулей на две группы (рис. 3. 1): § ядро – модули, выполняющие основные функции ОС; § вспомогательные модули ОС. Операционная система Вспомогательные модули ОС (3) (4) (1) (2) Ядро (1) Модули, (2) Модули, решающие обеспечивающие Утилиты Сервисные Библиотеки Системные внутриподдержку обрабатывающие программы процедур системные приложений различного программы задачи назначения Рис. 3. 1. Две группы модулей в структуре ОС Ядро. Модули ядра выполняют такие базовые функции ОС, как управление процессами, памятью, устройствами ввода-вывода (УВВ) и другие. Ядро составляет сердцевину, без которой ОС становится полностью неработоспособной и не сможет выполнить ни одной своей функции. В состав ядра входят: 1) модули, решающие внутрисистемные задачи организации вычислительного процесса (переключение контекстов, загрузка-выгрузка страниц, обработка прерываний). Эти функции недоступны для приложений; 4

2) модули, обеспечивающие поддержку приложений (т. е. создание прикладной программной среды). Приложения могут обращаться к ядру с запросами (системными вызовами) для выполнения тех или иных действий, например, открытия и чтения файла, вывода графической информации, получения системного времени и других. Функции ядра, вызываемые приложениями, образуют интерфейс прикладного программирования (Application Programming Interface, API). Функции, выполняемые модулями ядра, являются наиболее часто используемыми функциями ОС. Поэтому скорость их выполнения определяет производительность всей системы в целом. Для обеспечения высокой скорости работы ОС все модули ядра или большая их часть постоянно находятся в ОП. Ядро является движущей силой всех вычислительных процессов в компьютерной системе, и крах ядра равносилен краху всей системы. Поэтому разработчики ОС уделяют особое внимание надежности кодов ядра, что может затягивать процесс их отладки на многие месяцы. Обычно ядро оформляется в виде программного модуля некоторого специального формата, отличного от формата пользовательских приложений. Такое ядро ОС называют монолитным. Остальные, вспомогательные модули ОС выполняют хотя и весьма полезные, но менее обязательные функции, например, архивирование данных, дефрагментацию диска, редактирование текстов. Вспомогательные модули ОС оформляются либо в виде приложений, либо в виде библиотек процедур. 5

А поскольку некоторые компоненты ОС оформлены как обычные приложения (в виде исполняемых модулей стандартного формата данной ОС), то часто бывает сложно провести четкую грань между составом ОС и приложениями. В конечном счете, решение о том, является ли (сегодня) какая-либо программа частью ОС или нет, принимает производитель ОС. При этом многое зависит от вероятности ее массового спроса у потенциальных пользователей данной ОС. Вспомогательные модули ОС обычно подразделяются на следующие 4 группы: 1) утилиты – программы, решающие отдельные задачи управления и сопровождения компьютерной системы, например, программы сжатия дисков, архивирования данных; 2) системные обрабатывающие программы – компиляторы, компоновщики, отладчики, профайлеры и т. п. ; 3) сервисные программы, предоставляющие пользователю дополнительные услуги – специальный вариант ГИП, калькулятор, игры и т. д. ; 4) библиотеки процедур различного назначения, упрощающие разработку приложений – библиотека математических функций, библиотека функций ввода-вывода и т. д. Как и обычные приложения, все вспомогательные модули обращаются к функциям ядра посредством системных вызовов. Выводы. 1. Разделение ОС на ядро и модули-приложения обеспечивает легкую расширяемость системы. Чтобы добавить новую высокоуровневую функцию, достаточно разработать новое приложение, не модифицируя важнейших функций ядра ОС. 6

2. Но внесение изменений в функции ядра может оказаться гораздо сложнее из-за сложностей структурной организации самого ядра. Иногда исправление ядра требует его полной перекомпиляции. 3. Архитектура ОС, основанная на монолитном ядре, давно стала классической. Важным ее свойством является возможность защиты кодов и данных ОС за счет выполнения функций ядра в привилегированном режиме. 3. 2. Монолитное ядро и привилегии ОС Для надежного управления ходом выполнения приложений ОС должна иметь по отношению к ним определенные привилегии, чтобы 1) не дать некорректно работающему приложению вмешаться в работу ОС и разрушить часть ее кодов. Модули ОС должны быть надежно защищены от приложений; 2) играть роль арбитра в споре приложений за ресурсы компьютера в мультипрограммном режиме. Ни одно приложение не должно иметь возможности без ведома ОС получать дополнительную область ОП, занимать процессор дольше положенного периода времени, непосредственно управлять совместно используемыми УВВ. Обеспечить привилегии ОС нельзя без специальных средств аппаратной поддержки. Аппаратура компьютера должна поддерживать как минимум два режима работы – пользовательский режим (user mode) и привилегированный режим или так называемый режим ядра (kernel mode) или режим супервизора (supervisor mode). Тогда ОС или ее части (и в первую очередь, ядро) работают в привилегированном режиме, а все приложения – в пользовательском режиме. 7

Приложения подчинены ОС за счет запрета выполнения в пользовательском режиме некоторых критичных команд, связанных с 1) переключением процессора с задачи на задачу, 2) управлением УВВ, 3) доступом к механизмам распределения и защиты памяти. Более того, выполнение некоторых инструкций в пользовательском режиме запрещается безусловно, например, инструкции перехода в привилегированный режим. Выполнение же некоторых других инструкций ограничивается специальными условиями. Например, инструкции ввода-вывода могут быть запрещены приложениям при доступе к контроллеру жесткого диска, хранящего данные, общие для ОС и всех приложений, но разрешены при доступе к последовательному порту, монопольно выделенному данному приложению. При этом особенно важно то, что сами условия разрешения выполнения критичных инструкций находятся под полным контролем ОС. Этот контроль обеспечивается применением набора инструкций, безусловно запрещенных для пользовательского режима. Аналогичным образом обеспечиваются привилегии ОС при доступе к памяти. Например, выполнение инструкции доступа к памяти для приложения разрешается, если эта память – его адресное пространство, и запрещается, если чужое (ОС или другого приложения). А полный контроль ОС над доступом к памяти достигается за счет того, что сами инструкции конфигурирования механизмов защиты памяти (например, изменение ключей защиты памяти в мэйнфреймах корпорации IBM или указателя таблицы дескрипторов памяти в процессорах Intel Pentium) разрешается выполнять только в привилегированном режиме. 8

Но механизмы защиты памяти используются ОС не только для защиты своих областей памяти от приложений, но и для взаимной защиты областей памяти разных приложений. Поскольку каждое приложение работает в своем адресном пространстве, ОС локализует некорректно работающее приложение в его области памяти так, что его ошибки не оказывают влияния на ОС и остальные приложения. Например, в архитектуре x 86 существует 4 уровня привилегий или кольца. В процессоре без аппаратной поддержки виртуализации в кольце 0, имеющем максимальные привилегии, выполняется ядро ОС, имея полный доступ к процессору. Выполнение инструкций в кольце 0 соответствует привилегированному режиму. Кольца 1 и 2 не используются, а в кольце 3 работают приложения. Выполнение инструкций в кольце 3 соответствует пользовательскому режиму. А число уровней привилегий, поддерживаемых конкретной ОС на базе реализуемых аппаратно, для разных систем различно. Например, на базе 4 уровней для процессоров Intel: в ОС OS/2 построена трехуровневая система привилегий, а в ОС семейств MS Windows, UNIX и некоторых других – двухуровневая. То есть ОС может обеспечить сколь угодно развитую программную систему защиты. Эта система защиты может поддерживать, например, многоуровневую иерархию привилегий, что позволяет более тонко распределять полномочия, как между модулями ОС, так и между приложениями. А появление внутри ОС более и менее привилегированных частей позволяет повысить ее устойчивость к внутренним ошибкам программных кодов, так как эти ошибки будут касаться только модулей определенного уровня привилегий. 9

Разграничение привилегий в среде приложений позволяет строить сложные прикладные ПС, в которых часть более привилегированных модулей может получать доступ к данным менее привилегированных и управлять их выполнением. На основе двух режимов привилегий процессора ОС может построить и сложную систему индивидуальной защиты ресурсов, например, файлов и каталогов. Такая система позволяет задать для любого пользователя определенные права доступа к каждому из файлов и каталогов. Платой за повышение устойчивости ОС при переходе в привилегированный режим является некоторое замедление выполнения системных вызовов. Системный вызов привилегированного ядра инициирует переключение процессора из пользовательского режима в привилегированный, а при возврате к приложению – назад в пользовательский. Из-за такой двухкратной задержки переключения процессора вызов процедуры со сменой режима выполняется медленнее, чем без смены. Классическую архитектуру ОС, основанную на привилегированном монолитном ядре и приложениях пользовательского режима, используют многие версии ОС семейства UNIX (например, BSD, Linux), OS/2, частично Windows NT и последующие. Но иногда разработчики отходят от этого варианта архитектуры, позволяя наиболее важным приложениям ОС выполняться в привилегированном режиме. Это касается, например, загружаемых модулей сетевой ОС Net. Ware компании Novell (Net. Ware Loadable Modules, NLM). При этом повышается производительность, но ослабляется защита ОС от работающих приложений, надежность которых в этом случае должна равняться надежности самой ОС (!!). 10

3. 3. Многослойная структура ОС ВС, работающую под управлением ОС на основе монолитного ядра, можно представить в виде трехуровневой иерархии слоев: нижний – аппаратура, средний – ядро ОС, верхний – вспомогательные модули ОС. Утилиты Системные обрабатывающие программы Библиотеки процедур Приложения пользователей Пользовательский режим Привилегированный режим Ядро ОС Аппаратура компьютера Рис. 3. 2. Иерархия слоев ВС, работающей под управлением ОС на основе ядра Особенностью этой иерархии является то, что отдельный слой может взаимодействовать только со смежными слоями. Например, приложения не могут сами взаимодействовать с аппаратурой. Многослойный подход является универсальным и эффективным способом декомпозиции сложных систем любого типа, в том числе и ПС. В соответствии с ним: 1) система состоит из иерархии слоев (рис. 3. 3); 2) каждый слой обслуживает вышележащий слой, выполняя для него некоторый набор функций межслойного интерфейса; 11

Слой (k+1) Слой (k-1) Рис. 3. 3. Иерархия слоев системы 3) на основе функций нижележащего слоя следующий, вышележащий слой строит свои функции – более сложные и более мощные. Они являются основой для создания еще более мощных функций следующего вышележащего слоя; 4) строгие правила касаются только взаимодействия (↕) между слоями системы, а между модулями внутри слоя связи (↔) могут быть произвольными; 5) отдельный модуль может выполнить свою работу либо самостоятельно, либо обратиться за помощью к нижележащему слою через межслойный интерфейс. 12

Такая организация системы имеет много достоинств. Она существенно упрощает разработку ОС: позволяет сначала определить «сверху вниз» функции слоев и межслойные интерфейсы, а затем при детальной реализации постепенно наращивать мощность функций слоев, двигаясь «снизу вверх» . Кроме того, при модернизации ОС можно изменять модули внутри слоев без необходимости изменений в остальных слоях, если при таких внутренних изменениях остаются в силе межслойные интерфейсы. Многослойный подход обычно распространяется и на структуру самого ядра ОС, которое может иметь следующие 5 слоев (рис. 3. 4). 5. Интерфейс системных вызовов 4. Менеджеры ресурсов 3. Базовые механизмы ядра 2. Машинно-зависимые компоненты ОС 1. Средства аппаратной поддержки ОС Рис. 3. 4. Слои ядра ОС 1. Средства аппаратной поддержки ОС. Часть функций ОС может выполняться аппаратными средствами, непосредственно участвующими в организации вычислительных процессов. Это средства поддержки привилегированного режима, система прерываний, средства переключения контекстов процессов, средства защиты областей памяти и другие. 13

2. Машинно-зависимые компоненты ОС – это программные модули, отражающие специфику конкретной аппаратной платформы компьютера. В идеале этот слой должен изолировать вышележащие слои ядра от особенностей аппаратуры. Это позволяет разрабатывать вышележащие слои из машинно-независимых модулей, существующих в единственном экземпляре для всех типов аппаратных платформ, поддерживаемых данной ОС. Например, машинно-зависимые компоненты ОС содержит слой аппаратной абстракции (Hardware Abstraction Layer, HAL) в ОС Windows NT. 3. Базовые механизмы ядра. Этот слой выполняет наиболее примитивные операции ядра: программное переключение контекстов процессов; диспетчеризация прерываний; перемещение страниц из ОП на диск и обратно и т. п. Модули данного слоя не принимают решений о распределении ресурсов, они только отрабатывают принятые «наверху» решения, почему и называются исполнительными механизмами для модулей верхних слоев. Например, решение о том, что в данный момент нужно прервать выполнение текущего процесса A и начать выполнение процесса B, принимает менеджер процессов в вышележащем слое (4), а слою базовых механизмов (3) передается только директива, что нужно выполнить переключение с контекста текущего процесса A на контекст нового процесса B. 4. Менеджеры ресурсов. Этот слой состоит из мощных функциональных модулей, реализующих стратегические задачи по управлению основными ресурсами ВС. Обычно в этом слое работают менеджеры (диспетчеры) процессов, ввода-вывода, ФС и ОП. Разбиение на менеджеры может быть и несколько иным. (1 час) 14

Например, менеджер ФС иногда объединяют с менеджером ввода-вывода, а функции управления доступом пользователей к системе в целом и ее отдельным объектам поручают отдельному менеджеру безопасности. Каждый менеджер ведет учет свободных и используемых ресурсов определенного типа и планирует их распределение по запросам приложений. Например, менеджер виртуальной памяти управляет перемещением страниц из ОП на диск и обратно. Он должен отслеживать: интенсивность обращений к страницам, время пребывания их в ОП, состояния процессов, использующих данные, и многие другие параметры, на основании которых он время от времени принимает решения о том, какие страницы необходимо выгрузить и какие – загрузить. Для исполнения принятых решений менеджер обращается к нижележащему слою базовых механизмов (3) с запросами о загрузке (выгрузке) конкретных страниц. А внутри слоя менеджеров существуют тесные взаимные связи, отражающие то, что для своего выполнения процессу может быть нужен доступ одновременно к нескольким ресурсам – процессору, области памяти, а также, возможно, к определенному файлу или УВВ. Например, при порождении процесса менеджер процессов обращается к менеджеру памяти, который должен выделить процессу определенную область ОП для его кодов и данных. 5. Интерфейс системных вызовов – самый верхний слой ядра, взаимодействует непосредственно с приложениями и системными утилитами, образуя API ОС. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения. 15

Пример. В UNIX с помощью системного вызова fd = open (“/doc/a. txt”, O_RDONLY) приложение открывает файл a. txt, хранящийся в каталоге /doc, а с помощью системного вызова read (fd, buffer, count) читает из этого файла в область своего адресного пространства, имеющую имя buffer, некоторое число байтов. Для осуществления таких комплексных действий системные вызовы обычно обращаются за помощью к функциям слоя менеджеров ресурсов (4), причем для выполнения одного системного вызова может понадобиться несколько таких обращений. Приведенное разбиение ядра ОС на слои является достаточно условным. В реальной системе число слоев и распределение функций между ними может быть и иным. Так, в системах, предназначенных для аппаратных платформ одного типа, например, в сетевой ОС Net. Ware, слой машинно-зависимых модулей (2) обычно не выделяется, сливаясь со слоем базовых механизмов (3) и, частично, со слоем менеджеров ресурсов (4). Не всегда оформляются в отдельный слой (3) и базовые механизмы. В этом случае менеджеры ресурсов не только планируют использование ресурсов, но и самостоятельно реализуют свои планы. Но ядро может состоять и из большего числа слоев. Например, сами менеджеры ресурсов могут обладать многослойной структурой. Прежде всего, это менеджер ввода-вывода, нижний слой которого составляют драйверы устройств (жесткого диска, сетевого адаптера), работающие с физической организацией информации, а верхние слои – драйверы ФС, имеющие дело с логической организацией информации. 16

Способ взаимодействия слоев в реальной ОС может отличаться от описанной выше схемы. Для ускорения работы ядра в некоторых случаях происходит непосредственное обращение с верхнего слоя к функциям нижних слоев, минуя промежуточные слои. Типичный пример такого «неправильного» взаимодействия – начальная стадия обработки системного вызова. На многих аппаратных платформах для реализации системного вызова используется инструкция программного прерывания. Этим приложение фактически вызывает модуль первичной обработки прерываний, находящийся в слое базовых механизмов (3), а уже этот модуль вызывает нужную функцию из слоя системных вызовов (5). Сами функции системных вызовов (слой 5) также иногда нарушают субординацию слоев, обращаясь прямо к базовым механизмам ядра (слой 3). Выбор числа слоев ядра является сложным и ответственным делом: увеличение числа слоев ведет к некоторому замедлению работы ядра за счет дополнительных накладных расходов на межслойное взаимодействие, а уменьшение – ухудшает расширяемость и логичность системы. Обычно ОС с большой историей (UNIX) имеют неупорядоченное ядро с небольшим числом четко выделенных слоев, в то время, как у «молодых» ОС (семейства MS Windows) ядро разделено на большее число слоев и их взаимодействие формализовано в гораздо большей степени. 3. 4. Аппаратная зависимость и переносимость ОС Известно, что многие ОС успешно работают на различных аппаратных платформах без существенных изменений в своем составе. 17

Несмотря на различия в деталях, средства аппаратной поддержки ОС большинства компьютеров приобрели сегодня множество типовых черт, серьезно влияющих на работу компонентов ОС. В результате в ОС можно выделить достаточно компактный слой машинно-зависимых компонентов ядра (слой 2 на рис. 3. 4) и сделать остальные слои (3 -5) общими для разных аппаратных платформ. 3. 4. 1. Типовые средства аппаратной поддержки ОС Четкая граница между программной и аппаратной реализацией функций ОС отсутствует. Подобные решения принимают разработчики аппаратного и программного обеспечения компьютера. Но практически все современные аппаратные платформы имеют некоторый типовой набор средств аппаратной поддержки ОС, в который входят следующие 6 средств (рис. 3. 5). Средства аппаратной поддержки ОС 1. Средства поддержки привилегированного режима 2. Средства трансляции адресов 3. Средства переключения процессов 4. Система прерываний 5. Системный таймер 6. Средства защиты областей памяти Рис. 3. 5. Типовой набор средств аппаратной поддержки ОС 1. Средства поддержки привилегированного режима обеспечивают смену режима работы процессора. 18

Основой для них является системный регистр процессора – так называемое «слово состояния процессора» (ССП) или «слово состояния машины» (ССМ). Этот регистр содержит некоторые признаки режимов работы процессора, в том числе признак текущего режима привилегий. Смена режима привилегий выполняется за счет изменения ССП в результате прерывания или выполнения привилегированной команды. А число градаций привилегированности у разных типов процессоров различное. Наиболее часто используются 2 уровня (ядро – пользователь) или 4 уровня (ядро– супервизор–выполнение–пользователь (у процессоров VAX) или 1 -2 -3 -4 (у процессоров Intel x 86/Pentium). При этом обязательна проверка допустимости выполнения активной программой инструкций процессора при текущем уровне привилегированности. 2. Средства трансляции адресов преобразуют виртуальные адреса в кодах процесса в адреса физической ОП. Для трансляции используются таблицы большого объема в ОП, а аппаратура процессора содержит только указатели на эти области ОП. Средства трансляции адресов используют эти указатели для доступа к элементам таблиц при более быстром аппаратном выполнении алгоритма преобразования адреса. 3. Средства переключения процессов предназначены для быстрого сохранения контекста приостанавливаемого процесса и восстановления контекста процесса, который становится активным. Содержимое контекста обычно включает содержимое всех регистров общего назначения процессора, регистра флагов операций (нуля, переноса, переполнения и т. п. ), а также тех системных указателей, которые связаны с отдельным процессом, а не с самой ОС, например, указателя на таблицу трансляции адресов процесса. 19

Для хранения контекстов приостанавливаемых процессов обычно используются области ОП, поддерживаемые указателями процессора. Переключение контекста выполняется по определенным командам процессора, например, по команде перехода на новую задачу. Такая команда автоматически вызывает загрузку данных из сохраненного контекста в регистры процессора, после чего процесс продолжается с ранее прерванного места. 4. Система прерываний позволяет компьютеру: 1) реагировать на внешние события; 2) синхронизировать выполнение процессов и работу УВВ; 3) быстро переключаться с одной программы на другую. Механизм прерываний нужен для того, чтобы оповестить процессор о возникновении в ВС некоторого непредсказуемого или не синхронизированного с циклом работы процессора события, для чего источник прерывания вырабатывает определенный электрический сигнал. Известный переход на процедуру обработки прерывания сопровождается заменой ССП (или даже всего контекста процесса), что позволяет перейти в привилегированный режим. Даже системные вызовы от приложений выполняются на многих аппаратных платформах с помощью специальной инструкции прерывания, вызывающей переход к выполнению соответствующих процедур ядра. 5. Системный таймер реализуется в виде быстродействующего регистра-счетчика и необходим ОС для выдержки требуемых интервалов времени. Для этого в регистр таймера программно загружается значение интервала в условных единицах, из которого затем с определенной частотой начинает вычитаться по единице. При достижении нулевого значения таймер инициирует прерывание. 20

Прерывания от системного таймера используются ОС, прежде всего, для слежения за тем, как отдельные процессы расходуют время процессора. 6. Средства защиты областей памяти обеспечивают проверку возможности чтения, записи или выполнения кода данной области ОП. Эти средства обычно встраиваются в механизм трансляции адресов. Аппаратные функции защиты памяти состоят в сравнении уровней привилегий текущего кода процессора и сегмента памяти, к которому производится обращение. 3. 4. 2. Машинно-зависимые компоненты и переносимость ОС Известно, что одна и та же ОС не может без каких-либо изменений устанавливаться на компьютерах, различающихся типом процессора или способом организации всей аппаратуры. Дело в том, что в модулях ядра не могут не отразиться такие особенности аппаратной платформы, как: 1) число типов прерываний и формат таблицы ссылок на процедуры обработки прерываний; 2) состав регистров общего назначения и системных регистров, состояние которых нужно сохранять в контексте процесса; 3) особенности подключения УВВ и многие другие. Но ядро можно спроектировать и так, что только несколько его модулей окажутся машинно-зависимыми. В хорошо структурированном ядре машинно-зависимые модули локализованы и образуют программный слой, примыкающий сверху к слою аппаратуры. Это обстоятельство существенно упрощает перенос ОС на другую аппаратную платформу. При этом объем машинно-зависимых компонентов ОС прямо зависит от степени различия используемых аппаратных платформ. 21

Например, 32 -разрядная ОС для переноса на машину с 16 -битными адресами практически должна быть переписана заново. Одно из наиболее очевидных различий – несовпадение системы команд процессора – преодолевается достаточно просто. ОС программируется на языке высокого уровня, а затем соответствующим компилятором вырабатывается код для конкретного типа процессора. Но бывают и более глубокие различия. Например, двухпроцессорный вариант компьютера требует применения в ОС иного алгоритма распределения процессорного времени, а отсутствие аппаратной поддержки виртуальной памяти – иной реализации подсистемы управления памятью. Идея! Для уменьшения числа машинно-зависимых модулей производители ОС обычно ограничивают универсальность машинно-независимых модулей. Это означает, что независимость становится условной и распространяется только на несколько близких типов процессоров и соответствующих аппаратных платформ. Так, разработчики ОС Windows NT ограничили число типов процессоров четырьмя и поставляли различные варианты кодов ядра для одно- и многопроцессорных компьютеров. Особое место среди модулей ядра занимают низкоуровневые драйверы УВВ. С одной стороны эти драйверы, как и высокоуровневые, входят в состав менеджера вводавывода, то есть относятся к достаточно высокоуровневому слою (см. Раздел 6 !!!). С другой стороны, низкоуровневые драйверы отражают все особенности управляемых УВВ, поэтому их можно отнести и к слою машинно-зависимых модулей. Такая двойственность низкоуровневых драйверов еще раз подтверждает схематичность 22 модели ядра со строгой иерархией слоев.

Для компьютеров на основе процессоров Intel x 86/Pentium разработка экранирующего машинно-зависимого слоя несколько упрощается за счет встроенной в постоянную память компьютера BIOS содержит драйверы всех устройств, входящих в базовую конфигурацию компьютера: жестких и гибких дисков, клавиатуры, дисплея и других. Эти драйверы выполняют весьма примитивные функции с управляемыми устройствами, например, чтение группы секторов данных с определенной дорожки диска, но за счет этих операций как раз и экранируются различия аппаратных платформ ПК и серверов на процессорах Intel разных производителей. А разработчики ОС могут выбирать: 1) пользоваться слоем драйверов BIOS как частью машинно-зависимого слоя ОС; 2) заменить все или часть драйверов BIOS создаваемыми компонентами своей ОС. Итак, если код ОС сравнительно легко может быть перенесен на процессор или аппаратную платформу другого типа, то это переносимая (портируемая, portable) или мобильная ОС. Но при этом остается вопрос, насколько легко или какой ценой это можно сделать? Чтобы обеспечить свойство мобильности ОС, надо учесть следующие 3 правила. 1. Большая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда планируется перенос. Язык Си удовлетворяет этому правилу, обеспечивая мобильность UNIX. Ассемблер удобен при переносе ОС в рамках постоянства системы команд. В остальных случаях он используется только для тех непереносимых частей ОС, которые должны непосредственно взаимодействовать с аппаратурой (например, обработчик прерываний) или требуют максимальной скорости (например, целочисленная арифметика повышенной точности). 23

2. Объем машинно-зависимых частей кода, непосредственно взаимодействующих с аппаратными средствами, должен быть по возможности минимизирован. 3. Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, не быть распределен по всей системе. В идеале слой машинно-зависимых компонентов ядра полностью экранирует остальную часть ОС от конкретных деталей аппаратной платформы (таких как кэш, контроллеры прерываний ввода-вывода и т. п. ), по крайней мере, для набора платформ, поддерживаемых данной ОС. В результате происходит подмена реальной аппаратуры некой унифицированной виртуальной машиной, одинаковой для всех вариантов аппаратной платформы. А все слои ОС, лежащие выше слоя машиннозависимых компонентов, могут быть написаны для управления именно этой виртуальной аппаратурой. Таким образом, у разработчиков появляется возможность создавать один вариант машинно-независимой части ОС, включая компоненты ядра, утилиты, системные обрабатывающие программы, для всего набора поддерживаемых платформ. 3. 5. Архитектура на основе микроядра является альтернативой рассмотренному классическому способу построения ОС, когда все функции ядра выполняются в привилегированном режиме. Ее суть: в привилегированном режиме остается работать только очень небольшая часть ядра (микроядро), защищенная от остальных частей ОС и приложений. 24

Состав микроядра: 1) машинно-зависимые модули; 2) модули, выполняющие часть базовых функций ядра по управлению процессами, обработке прерываний, управлению виртуальной памятью, пересылке сообщений и управлению УВВ, связанные с загрузкой или чтением регистров устройств. Набор базовых функций микроядра обычно соответствует функциям слоя базовых механизмов (3) обычного ядра. Такие функции ОС трудно или невозможно выполнить в пространстве пользователя. А все остальные более высокоуровневые функции ядра оформляются в виде приложений, работающих в пользовательском режиме. Однако однозначного решения о способе подобного разделения ядра не существует. В общем случае многие менеджеры ресурсов (такие как ФС, подсистемы управления виртуальной памятью и процессами, менеджер безопасности и т. п. ) становятся «периферийными» модулями, работающими в пользовательском режиме. Но работающие в пользовательском режиме менеджеры ресурсов принципиально отличаются от традиционных утилит и обрабатывающих программ, хотя и также оформлены в виде приложений. Утилиты и обрабатывающие программы обычно вызываются только пользователями. Ситуации же, когда одному приложению требуется выполнение функции (или процедуры) другого приложения, возникают крайне редко. Именно поэтому в ОС с классической архитектурой отсутствует механизм вызова одним приложением функций другого. Совсем иная ситуация возникает в том случае, когда в виде приложения оформляется часть ОС. По определению, основным назначением такого приложения является обслуживание запросов других приложений. 25

Это касается, например, порождения процесса, выделения ему памяти, проверки его прав доступа к ресурсу и т. п. Именно поэтому менеджеры ресурсов, вынесенные в пользовательский режим, и стали называться серверами ОС – модулями, обслуживающими запросы приложений и других модулей ОС. Значит, для реализации архитектуры на основе микроядра необходимо обеспечить удобный и эффективный способ вызова процедур одного процесса из другого, причем поддержка такого механизма как раз и является одной из главных задач микроядра. В ОС на основе микроядра механизм обращения к функциям ОС, оформленным в виде серверов, основан на модели взаимодействия «клиент-сервер» (рис. 3. 6). Приложения пользователей 1 4 2 Сетевой сервер Сервер ввода -вывода Сервер процессов Файловый сервер Пользовательский режим Привилегированный режим Серверы Сервер безопасности 3 5 86 7 Микроядро Рис. 3. 6. Механизм обращения к функциям ОС в архитектуре на основе микроядра Клиент (например, приложение или компонент ОС) запрашивает выполнение некоторой функции сервера, посылая сообщение (обозначим его цифрой 1) микроядру. Напомню, что непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы. 26

Но микроядро, выполняющееся в привилегированном режиме, имеет доступ к адресным пространствам приложений и поэтому может стать посредником, передающим сообщения: нужному серверу – имя и параметры вызываемой процедуры (2), обратно клиенту – результаты (3, 4). В свою очередь, серверы через микроядро подобным образом могут включать в работу друга, как показано на рис. 3. 6 соответственно по шагам цифрами 5 -8. Запомните, что в рассмотренных примерах смена режимов происходит 4 раза (1→ 2→ 3→ 4 или 5→ 6→ 7→ 8). Преимущества и недостатки архитектуры на основе микроядра: 1) переносимость. Весь машинно-зависимый слой изолирован в микроядре, поэтому для переноса ОС на новый процессор требуется меньше изменений, причем все они сгруппированы вместе; 2) расширяемость. Достигается легче, чем в классической архитектуре, где перегруппировать слои трудно из-за множественности и размытости интерфейсов между слоями. А ограниченный набор четко определенных интерфейсов микроядра открывает путь к упорядоченному росту и эволюции ОС на его основе. Например, добавление новой подсистемы потребует всего лишь разработки нового приложения для пользовательского режима, не затрагивая целостность микроядра. При наличии микроядра изменение конфигурации ОС не вызывает никаких проблем, поскольку для этого достаточно изменить файл с настройками начальной конфигурации системы или же просто остановить не используемые в ходе работы серверы обычными для приложений средствами; 27

3) надежность. Выше, чем при классической архитектуре, поскольку каждый сервер выполняется в виде отдельного процесса в своем изолированном от других серверов адресном пространстве. Модули классического ядра могут влиять друг на друга. При крахе же отдельного сервера он может быть перезапущен без останова или повреждения остальных. Работая в пользовательском режиме, серверы не имеют доступа к аппаратуре, не могут модифицировать ОП, в которой хранится и работает микроядро; 4) удобство поддержки распределенных вычислений. Модель «клиент-сервер» позволяет организовать серверы на различных компьютерах. При этом запрос может быть передан как микроядру для (своего) локального сервера, так и по сети микроядру другого компьютера (то есть локальный транспорт легко заменяется на сетевой); 5) производительность. К сожалению, ОС с архитектурой на основе микроядра всегда будет менее производительной, чем с классической. Это связано с тем, что выполнение системного вызова в классической ОС требует переключения режимов 2 раза, а в ОС на основе микроядра – 4 раза. Отмеченный недостаток ограничивает применение этой, в целом интересной архитектуры и ставит разработчиков перед дилеммой: 1) минимизировать микроядро, теряя производительность; 2) бороться за производительность, расширяя микроядро. Примеры ОС на основе микроядра: GNU/Hurd с микроядром Mach, Symbian OS, Mac OS X, QNX, AIX, Minix 3, Chorus. OS, Amiga. OS, Morph. OS, а также частично и весьма условно Windows NT 3. х (где архитектура на основе микроядра с сервисным процессом использовалась для подсистемы графики и пользовательского интерфейса; драйвер графической аппаратуры загружался в контекст сервисного процесса, а не ядра). 28

Лекция 9. 3. 6. Новые варианты ядра и архитектуры ОС Мы уже рассмотрели два основных варианта архитектуры ОС, основанные на монолитном ядре и микроядре. Но развитие ОС в условиях наличия манящей разработчиков границы между привилегированным и пользовательским режимами, а также открывшейся возможности уточнения состава ядра и его минимизации, в последние годы вызвало к жизни целый ряд новых архитектурных решений. Они основаны на новых взглядах на состав и роль ядра в современной ОС. Дерево вариантов ядра, отражающее преемственность такого развития, приведено на рис. 3. 7. 1. Монолитное ядро 2. Микроядро 3. Гибридное ядро 5. Наноядро 4. Модульное ядро 6. Экзоядро 7. Пикоядро Рис. 3. 7. Дерево вариантов ядра 1. Монолитное ядро является наиболее архитектурно зрелым и пригодным к эксплуатации, оно представляет собой набор процедур, работающих в 29 привилегированном режиме.

Каждая процедура может вызвать любую другую. Монолитное ядро предоставляет богатый набор абстракций оборудования, все его компоненты работают в одном адресном пространстве, являются составными частями одной программы, используют общие структуры данных и взаимодействуют друг с другом путем непосредственного вызова процедур. Достоинства монолитного ядра: скорость работы, упрощенная разработка модулей, богатство предоставляемых возможностей и функций, поддержка большого количества разнообразного оборудования. Недостатки: 1) поскольку все компоненты ядра работают в одном адресном пространстве, сбой в одном из них может нарушить работоспособность всей системы; 2) монолитность ядра усложняет отладку и понимание его кода, а также добавление новых функций и возможностей, удаление устаревшего кода; 3) избыточность кода монолитного ядра повышает затраты ОП для его функционирования. 2. Микроядро представляет лишь необходимую часть монолитного ядра. Классическое микроядро предоставляет очень небольшой набор низкоуровневых примитивов или системных вызовов, реализующих базовые сервисы ОС: управление адресным пространством ОП и виртуальной памяти, процессами и потоками, а также средства межпроцессного взаимодействия. Такая конструкция позволяет улучшить общее быстродействие системы, так как небольшое микроядро может уместиться в кэше процессора, но вызывает 4 избыточные смены режимов работы процессора. Поскольку рассмотренные подходы к построению ОС имеют свои достоинства и недостатки, в большинстве случаев развития современные и перспективные ОС используют различные модификации или комбинации этих 2 основных подходов. 30

3. Гибридное (смешанное) ядро представляет собой модифицированное микроядро, разрешающее для ускорения работы запускать «несущественные» части в пространстве ядра. Например, ОС Linux имеет монолитное ядро с элементами микроядра. При компиляции ядра можно разрешить динамическую загрузку и выгрузку очень многих компонентов ядра (модулей). В момент загрузки модуля его код загружается на уровне системы и связывается с остальной частью ядра. Внутри модуля могут использоваться экспортируемые ядром функции. Примеры. 1. Существуют варианты ОС GNU, где вместо монолитного ядра применяется микроядро Mach, а поверх него функционируют в пользовательском режиме те же процессы, которые при использовании Linux были бы частью ядра. 2. Другим примером такого смешанного подхода является возможность запуска ОС с монолитным ядром под управлением микроядра. Например, так устроены ОС 4. 4 BSD и MKLinux, основанные на микроядре Mach. Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов. В то время как все остальные функции, в том числе взаимодействие с прикладными программами, реализуются монолитным ядром. Данный подход сформировался в результате попыток использовать преимущества архитектуры на основе микроядра, сохраняя по возможности хорошо отлаженный код монолитного ядра. 31

3. Но все же наиболее тесно элементы монолитного ядра и микроядра переплетены в ОС MS Windows NT и последующих. Ее микроядро NT kernel занимает более 1 Мбайт и слишком велико для идеального микроядра. Компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как и положено в ОС на основе микроядра. В то же время все компоненты ядра работают в одном адресном пространстве и активно используют общие структуры данных, что свойственно именно ОС с монолитным ядром. Поэтому Windows NT можно с полным правом назвать гибридной ОС. 4. Другие примеры гибридных ядер: ядро ОС Be. OS, микроядро Dragon. Fly BSD, ядро сетевой ОС Net. Ware. 4. Модульное ядро представляет собой современную, усовершенствованную модификацию монолитного ядра. Модульное ядро, как правило, уже не требует полной его перекомпиляции при изменении состава аппаратного обеспечения компьютера. Оно поддерживает механизм загрузки поддерживающих аппаратуру модулей ядра (например, драйверов). При этом загрузка модулей может быть: 1) динамическая без перезагрузки ОС или 2) статическая, выполняемая при перезагрузке ОС после реконфигурирования системы. Модульное ядро удобнее разрабатывать, чем традиционные монолитные ядра, не поддерживающие динамическую загрузку модулей, так как от разработчика не требуется многократная полная перекомпиляция ядра при работе над какой-либо его подсистемой или драйвером. Выявление, локализация, отладка и устранение ошибок при тестировании также облегчаются. 32

Модульное ядро предоставляет особый API для связывания модулей с ядром, для обеспечения динамической загрузки и выгрузки модулей. Модули ядра вместо функций стандартной библиотеки C/C++ должны использовать специальные функции API ядра, а также обязаны экспортировать определенные функции, нужные ядру для правильного подключения и распознавания модуля, для его корректной инициализации при загрузке и корректного завершения при выгрузке, для регистрации модуля в таблице модулей ядра и для обращения из ядра к сервисам, предоставляемым модулем. Но, к сожалению, не все части ядра могут быть сделаны модулями. Некоторые части ядра обязаны всегда присутствовать в ОП и должны быть жёстко «вшиты» в ядро. Также не все модули допускают динамическую загрузку. Поэтому степень модульности ядра (оцениваемая как количество и разнообразие кода, которое может быть вынесено в отдельные модули ядра и допускает динамическую загрузку) различна в различных реализациях модульного ядра. Например, ОС Linux в настоящее время имеет модульную архитектуру, но модульность «нестабильна» , поскольку API меняется от релиза к релизу, в отличие от стабильных интерфейсов модульных ядер *BSD (Free. BSD, Net. BSD, Open. BSD). Общей тенденцией развития является: 1) повышение степени модульности ядра; 2) улучшение механизмов динамической загрузки и выгрузки модулей; 3) уменьшение или устранение необходимости в ручной загрузке модулей или в реконфигурации ядра при изменениях аппаратуры путём введения тех или иных механизмов автоматического определения оборудования и автоматической загрузки нужных модулей; 4) универсализация кода ядра и 5) введение в ядро абстрактных механизмов, 33 предназначенных для совместного использования многими модулями.

Примером может служить виртуальная файловая система VFS, совместно используемая многими модулями файловых систем в ОС Linux. 5. Наноядро представляет собой крайне упрощённое и минималистичное ядро, выполняющее лишь одну задачу – обработку аппаратных прерываний, генерируемых устройствами компьютера. После обработки аппаратных прерываний такое наноядро посылает информацию о результатах обработки (например, полученные с клавиатуры символы) вышележащему ПО при помощи того же механизма прерываний. При этом предоставляются удобные механизмы абстракции от конкретных устройств и способов обработки их прерываний. В современных компьютерах наноядро часто используется для виртуализации аппаратного обеспечения реальных компьютеров или с целью позволить нескольким или многим различным ОС работать одновременно и параллельно на одном компьютере. Например, среда VMware ESX Server реализует собственное наноядро, независимое от ОС и устанавливаемое вообще без ОС. Под его управлением работают пользовательские и административные утилиты VMware, а также необходимые ОС, виртуализируемые в среде ESX Server. (сегодня рассмотрим и это!) Наноядро также может использоваться для обеспечения переносимости (портируемости) ОС на разные аппаратные платформы или для обеспечения возможности запуска некоторой «старой» ОС на новой, несовместимой аппаратной платформе без ее полного переписывания и портирования. Примеры наноядра. 34

1. Компания Apple использовала наноядро в версии ОС Mac OS Classic на платформе Power. PC для того, чтобы транслировать аппаратные прерывания, генерировавшиеся компьютерами на базе процессоров Power. PC в форму, которая могла бы «пониматься» и распознаваться Mac OS для «старых» процессоров Motorola 680 x 0. Таким образом, наноядро эмулировало для Mac OS «старую» 680 x 0 аппаратуру. А альтернативой было бы полное переписывание и портирование кода Mac OS на Power. PC при переходе с 680 x 0 на них. Позднее, в эпоху Mac OS 8. 6, наноядро виртуализировало предоставляемые Power. PC мультипроцессорные возможности и обеспечивало поддержку симметричного мультипроцессирования (Symmetrical Multiprocessing, SMP) в Mac OS. 2. Наноядро Adeos, работающее как модуль ядра Linux и позволяюшее выполнять одновременно с Linux какую-либо ОС реального времени (РВ). Замечание. Термин «наноядро» иногда неформально используется для описания очень маленьких, упрощённых и лёгких микроядер. 6. Пикоядро. Наноядро может быть настолько маленьким и примитивным, что даже важнейшие устройства, находящиеся непосредственно на материнской плате или на плате контроллера встраиваемого устройства (как таймер или программируемый контроллер прерываний) обслуживаются уже не им, а специальными драйверами устройств. Такого рода сверхминималистичное наноядро называется пикоядром. 7. Экзоядро (экзо – приставка, обозначающая нечто внешнее, находящееся снаружи) предоставляет лишь функции для взаимодействия процессов и безопасного выделения и освобождения ресурсов. 35

В отличие от монолитного ядра, предоставляющего не только минимальный набор сервисов выполнения программ, но и большое число высокоуровневых абстракций для использования разнородных ресурсов компьютера (ОП, жестких дисков, сетевых подключений), экзоядро предоставляет лишь набор сервисов для взаимодействия процессов, а также минимальные функции защиты: выделение и высвобождение ресурсов, контроль прав доступа, и т. д. А предоставление абстракций для физических ресурсов выносится в библиотеку пользовательского уровня lib. OS может обеспечивать произвольный набор абстракций, совместимый с той или иной уже существующей ОС, например, Linux или Windows. Архитектура экзоядра является дальнейшим развитием и усовершенствованием архитектуры на основе микроядра и одновременно ужесточает требования к минималистичности и простоте кода ядра. 3. 7. Совместимость ОС и множественные прикладные программные среды 3. 7. 1. Виды совместимости ОС Совместимость различных ОС – это возможность данной ОС выполнять приложения, написанные для других систем, на основе формирования множественных прикладных программных сред (ППС) этих ОС. Различают два вида совместимости: 36

§ двоичная – достигается, если исполняемую программу можно запустить в среде другой ОС. Она важна для пользователей, так как позволит тем использовать один и тот же продукт в среде разных ОС и на разных компьютерах, например, DOS-приложение – в среде ОС MS Windows NT и последующих; § на уровне исходных текстов – требует наличия соответствующего компилятора, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый исполняемый модуль. Такая совместимость важна для разработчиков приложений, обладающих исходными текстами. Совместимость новой ОС с существующими системами зависит от многих факторов, главный из которых – архитектура процессора. Если процессор имеет тот же набор команд (с добавлениями) и тот же диапазон адресов, то двоичная совместимость может быть достигнута достаточно просто при соблюдении следующих двух условий: 1) вызовы функций API из приложения должны поддерживаться новой ОС; 2) внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов новой ОС. А при разной архитектуре процессоров различаются и их инструкции. При этом достичь двоичной совместимости гораздо сложнее, поскольку дополнительно требуется организовать эмуляцию двоичного кода. 37

Эмулятор должен последовательно выбирать каждую двоичную инструкцию первого процессора (например, компании Intel), программно дешифровать ее, определяя задаваемые действия, а затем выполнять эквивалентную подпрограмму, написанную в кодах второго процессора (например, компании Motorola). А при отсутствии одинаковых регистров, флагов и внутреннего сопроцессора, как в Intel, их надо будет имитировать на своих регистрах или в памяти. Таким образом, эмуляция значительно замедляет развитие процессов, поскольку одна команда первого процессора выполняется гораздо быстрее, чем эмулирующая последовательность команд второго процессора. 3. 7. 2. Различия в API и трансляция библиотек разных ОС Практически любая ОС имеет свой API, с помощью которого программисты могут создавать приложения для данной ОС. Главный API любой ОС включает множество системных вызовов. API представляет набор методов (функций), который программист может использовать для доступа к функциональности программного компонента (программы, модуля, библиотеки). API является важной абстракцией, описывающей функциональность «в чистом виде» , безотносительно того, как именно она реализована. В индустрии ПО предпочтительны общие стандартные API для стандартной функциональности, так как они гарантируют, что все программы, использующие некоторый общий API, будут работать одинаково хорошо или, по крайне мере, типичным привычным образом. Например, в случае API графических интерфейсов это означает, что программы будут иметь похожий ГИП, что облегчает процесс освоения 38 новых программных продуктов.

С другой стороны, различия в API различных ОС существенно затрудняют перенос приложений между платформами. Но существуют и различные методы обхода этой сложности: 1) написание «промежуточных» API (например, API графических интерфейсов Qt, Gtk); 2) написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (Например, среды исполнения Wine, cygwin и др. ); 3) введение стандартов кодирования в языках программирования (например, стандартная библиотека языка С); 4) написание интерпретируемых языков для разных платформ (например, sh, Perl, PHP, TCL, Java и др. ) Улучшить ситуацию может использование нескольких ППС, основу которых составляет набор функций API. Для ускорения выполнения чужих программ ППС имитируют обращения к чужим библиотечным функциям. Эффективность такого подхода связана с тем, что большинство приложений работает под управлением ГИП типа Windows или Motif с большими затратами времени (60 -80%) на хорошо предсказуемые действия – непрерывные вызовы библиотек ГИП для манипулирования окнами, пиктограммами и т. д. Эта особенность приложений позволяет ППС компенсировать большие затраты времени на покомандное эмулирование программы. При этом качественная ППС включает библиотеки, имитирующие внутренние библиотеки ГИП, но написанные на «родном» языке, что существенно ускоряет выполнение программ с API другой ОС. Такой подход называют трансляцией, чтобы 39 отличить от медленного покомандного эмулирования.

Но чтобы выполнить программу одной ОС в среде другой, совместимости API оказывается недостаточно, поскольку каждая ОС обычно имеет собственные механизмы ввода-вывода, защиты ресурсов, алгоритмы обработки ошибок и исключительных ситуаций, особую структуру процесса и схему управления памятью, свою семантику доступа к файлам и ГИП. Таким образом, для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера. 3. 7. 3. Варианты реализации множественных ППС Таким образом, становится ясно, что создание полноценной ППС, полностью совместимой со средой другой ОС, является достаточно сложной задачей, тесно связанной со структурой ОС. В то же время известны различные подходы и варианты построения множественных ППС, различающиеся архитектурными особенностями, функциональными возможностями, различной степенью переносимости приложений. Например, в UNIX транслятор ППС реализуется в виде обычного приложения. В ОС с микроядром (Windows NT и последующих) ППС выполняются в виде серверов пользовательского режима. В OS/2 (с ее более простой архитектурой) средства организации ППС встроены глубоко в ОС. Далее рассмотрим схемы следующих трех показательных вариантов реализации множественных ППС. 1. Наиболее очевидный вариант, основанный на стандартной многоуровневой структуре ОС (рис. 3. 8). Здесь условная ОС-1 поддерживает кроме своих приложений, «чужие» приложения для ОС-2 и ОС-3. 40

Прикладная среда OС-2 Прикладная среда OС-3 Приложение OС-1 Приложение OС-2 Приложение OС-3 (API OС-2) Пользовательский режим Транслятор системных вызовов (API OС-3) Транслятор системных вызовов Привилегированный режим (5) API OС-1 (4) Менеджеры ресурсов (3) Базовые механизмы ядра (2) Машинно-зависимые компоненты Рис. 3. 8. Первый вариант реализации множественных ППС на основе стандартной многоуровневой структуры ОС Для этого в составе ОС-1 разработаны и используются специальные приложения – ППС, которые транслируют интерфейсы «чужих» ОС API ОС-2 и API ОС-3 в «родной» интерфейс API ОС-1. Но, в то же время известно, что, к сожалению, поведение почти всех одноцелевых функций API в разных ОС, как правило, весьма оригинально. Поэтому при построении ППС такие подобные функции «чужих» ОС-2 и ОС-3 необходимо дорабатывать с учетом особенностей «родной» ОС-1. 41

2. Вариант, когда основная ОС имеет несколько равноправных API, размещенных непосредственно в пространстве ее ядра (рис. 3. 9). Здесь функции уровня API обращаются к функциям нижележащего (4) уровня ОС, которые должны поддерживать все объединяемые ППС. Но в то же время известно, что в разных ОС поразному осуществляется управление системным временем, используется разный формат времени дня, по-своему разделяется процессорное время и т. д. Поэтому функции каждого API в этом варианте реализуются ядром с учетом специфики (и по правилам) его ОС. Например, таковы функции создания и завершения процессов. Прикладная среда OС-2 Прикладная среда OС-3 Приложение OС-1 Приложение OС-2 Приложение OС-3 Пользовательский режим Привилегированный режим API OС-1 API OС-2 API OС-3 (4) Менеджеры ресурсов (3) Базовые механизмы ядра (2) Машинно-зависимые компоненты Рис. 3. 9. Второй вариант реализации множественных ППС с несколькими 42 равноправными API у основной ОС

3. Вариант, основанный на концепции микроядра (рис. 3. 10). Приложения пользователей Серверы ОС Приложение … ППС OС-1 OС-3 Сетевой сервер ППС OС-2 Сервер безопасности Приложение OС-1 Приложение OС-2 ППС OС-3 Пользовательский режим Привилегированный режим Микроядро Рис. 3. 10. Третий вариант реализации множественных ППС на основе концепции микроядра При этом очень важно отделить базовые механизмы ОС, общие для всех ППС, от специфических для каждой ППС высокоуровневых функций, решающих стратегические задачи. Здесь все функции ОС реализуются микроядром и серверами пользовательского режима. Важно, что каждая ППС оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов ОС. 43

1 час А приложения, используя API, обращаются через микроядро с системными вызовами к соответствующей ППС обрабатывает запрос, выполняет его и отсылает результат ожидающему его приложению. Заметим, что в ходе выполнения запроса ППС приходится, в свою очередь, обращаться за помощью к базовым механизмам ОС, реализуемым микроядром, и другим серверам ОС. Этому подходу присущи все достоинства и недостатки архитектуры на основе микроядра: § (+) очень просто можно добавлять и исключать ППС, что является следствием хорошей расширяемости ОС на основе микроядра; § (+) надежность и стабильность – при отказе одной ППС все остальные сохраняют работоспособность; § (-) низкая производительность ОС на основе микроядра сказывается на скорости работы ППС, а значит и на скорости выполнения приложений. Выводы. 1. Создание в рамках одной ОС нескольких ППС для выполнения приложений разных ОС позволяет иметь единственную версию программы и переносить ее между разными ОС. 2. Множественные ППС обеспечивают совместимость на двоичном уровне данной ОС с приложениями, написанными для других ОС. 3. В результате пользователи получают большую свободу выбора ОС и более легкий доступ к качественному ПО. 44

3. 7. 4. Гипервизоры и технологии виртуализации Виртуализация – предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию вычислительных процессов, выполняемых на одном физическом ресурсе. Пример использования виртуализации: возможность запуска нескольких ОС на одном компьютере, при том каждый из экземпляров таких гостевых ОС работает со своим набором логических ресурсов (процессорных, ОП, устройств хранения), предоставлением которых из общего пула, доступного на уровне оборудования, управляет хостовая ОС или гипервизор. Сейчас для этого применяются 2 основных принципиально различных подхода, когда основой являются: 1) виртуальные машины (ВМ) – для каждой ВМ используется собственный экземпляр ОС; 2) виртуальные контейнеры (ВК) – все контейнеры работают с ядром одной ОС, но в собственном окружении среды. Вполне очевидно, что вариант ВМ совместим с неоднородными системами, а ВК – только с однородными средами, то есть механизм ВМ более универсален. Но зато ВК эффективен с точки зрения быстродействия и затрат ресурсов на поддержку собственно механизма виртуализации. В настоящее время преобладает подход ВМ, который используют практически все поставщики серверной виртуализации (VMware, Microsoft, Citrix и др. ). Технологию контейнеров сегодня реализуют фактически только компании Parallels (для Linux и Windows) и Oracle для ОС Solaris. Для обозначения средств исполнения ВМ используется термин гипервизор. 45

Гипервизор – перспективная компьютерная программа или аппаратная схема, обеспечивающая совместное (одновременное, параллельное) выполнение двух и более немодифицированных ОС на одном компьютере. Гипервизор обеспечивает изоляцию работающих ОС друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами. Гипервизор уже сегодня претендует на роль базового технологического уровня ПО компьютера, который действует как основа для гостевых ОС. Гипервизор также может предоставлять работающим под его управлением ОС средства связи и взаимодействия (например, обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах. Гипервизор, по сути, является минимальной ОС с микроядром или наноядром. Он предоставляет управляемым ОС сервис ВМ, при необходимости эмулируя реальную аппаратуру, управляет организованными ВМ, распределяет ресурсы для них. При этом гипервизор обеспечивает независимое «включение» и «выключение» , а также перезагрузку любой ВМ с необходимой пользователю ОС. Новый термин «гипервизор» введен специально, чтобы подчеркнуть его отличие от термина «супервизор» , которым традиционно называли ядро ОС, а точнее, менеджер ресурсов ядра в эпоху мейнфреймов. Гипервизор является расширением и обобщением понятия «супервизор» . Как супервизор в ядре ОС обеспечивал изоляцию приложений друг от друга, выделение и освобождение ресурсов для пользовательских процессов, так и гипервизор обеспечивает изоляцию и управление ресурсами, только уже для целых ОС со всеми их особенностями и различиями. 46

Технологии виртуализации. В настоящее время используются следующие 4 технологии виртуализации, которые проявляются на одном из 3 уровней: программном (прикладном), аппаратном, а также на уровне ОС. 1. Технология полной виртуализации компании VMware (1998 г. ) основана частично на бинарной трансляции и на выполнении инструкций на процессоре. Перед выполнением в «гостевом» коде выявляются проблемные инструкции, вместо которых вставляются команды перехода на гипервизор, генератор кода которого заменяет «плохие» инструкции набором «правильных» инструкций. Появление возможности запускать немодифицированную ОС позволило виртуализировать не только ОС Linux/UNIX, но и Windows. Но от того, что исполняемый код «гостевой» ОС необходимо непрерывно анализировать и налету исправлять, полная виртуализация не отличается высокой производительностью. Замедляет процесс и эмуляция ввода-вывода для отсутствующих аппаратных устройств. Обычно эмулируются действия с более простыми старыми устройствами, требующими меньше ресурсов, и имеющими драйверы для всех ОС. 2. Технология паравиртуализации требует изменения гостевой ОС для исключения «плохих» инструкций. Вместо них выполняются так называемые гипервызовы на обработку гипервизором. Модификации подвергается только ядро гостевой ОС, но не библиотеки и приложения уровня пользователя. Гостевая ОС общается с гипервизором на более высоком уровне. Гипервизор предоставляет гостевой ОС специальный API, с которым она и взаимодействует вместо того, чтобы обращаться напрямую к таким ресурсам, как таблица страниц памяти. 47

Кроме паравиртуализации процессора может выполняться паравиртуализация УВВ. Такие инструменты как VMWare Tools, MS Virtual PC Additions и другие представляют собой высокопроизводительные паравиртуализованные драйверы устройств, работающие в системах полной виртуализации. В случае паравиртуализации УВВ гостевая ОС и гипервизор используют общий набор драйверов, что выгодно отличает эту технологию от эмуляции устройств, когда гостевая ОС и гипервизор используют различные драйверы. Паравиртуализированные драйверы предоставляют гостевой ОС оборудование в виде блочных IO-устройств, сетевых и USB-устройств, которые не зависят от физического оборудования. Технология паравиртуализации драйверов более эффективна, чем эмуляция в связи с тем, что уменьшается число переключений между гипервизором и гостевой ОС. Итак, паравиртуализация повысила производительность, однако модифицировать удается только ОС с открытым исходным кодом, например, различные дистрибутивы Linux, но не ОС семейства MS Windows c закрытым кодом. 3. Технологии аппаратной виртуализации: Intel VT (компании Intel) и AMD SVM (компании AMD), основанные на идеях корпорации IBM и разработанные для своих новых процессоров, не совместимые, но схожие функционально. Аппаратная виртуализация представляет собой набор расширенных инструкций, облегчающий выполнение на аппаратном уровне ряда программных операций. В частности, аппаратно обеспечено выполнение привилегированных инструкций гостевой ОС в кольце 0. Для этого введен специальный «гостевой» режим процессора. 48

Но аппаратная виртуализация требует наличия программного гипервизора, поскольку без него на компьютере по-прежнему можно запустить только одну ОС. Технологии Intel и AMD могут обеспечивать прямой доступ виртуальных ОС к физическим устройствам через канал прямого доступа к памяти (Direct Memory Access, DMA). Когда гостевая ОС владеет требуемым физическим устройством напрямую, используя «родные» драйверы устройств, производительность и надежность системы в целом повышается. Однако у такого метода есть и свои минусы, например число физических устройств, которые можно назначить одной ВМ, ограничено, кроме того, при этом ухудшается ее переносимость. Появление аппаратной поддержки вдохновило программистов Linux разработать технологию ВМ, основанной на ядре (Kernel based Virtual Machine, KVM). ВМ уровня ядра встроена в ядро Linux 2. 6. 20 с февраля 2007 г. С помощью KVM можно запускать под управлением Linux немодифицированные версии Linux и Windows на компьютерах, поддерживающих технологии аппаратной виртуализации Intel VT или AMD SVM. Идея KVM рациональна – использовать ядро Linux в качестве гипервизора. Здесь любая ВМ является обычным процессом Linux. Вывод. Технологии аппаратной виртуализации реализованы в большинстве соответствующих программных продуктов частично, их код не оптимизирован так, как код программной виртуализации. Например, технология Intel-VT используется лишь в тех случаях, когда это действительно влияет на производительность. Но при аппаратной виртуализации код становится гораздо компактнее, соответственно он теоретически должен получиться более надежным. 49

4 Технологии виртуализации уровня ОС. Кроме технологий ВМ существует технология виртуализации ресурсов на уровне ядра ОС. Например, разделение одного физического сервера на несколько виртуальных, каждый из которых представляется для владельца как отдельный сервер. Виртуализация на уровне ОС позволяет запускать изолированные и безопасные ВМ на одном физическом узле, но не позволяет запускать ОС с ядрами, отличными от типа ядра его базовой ОС. При виртуализации на уровне ОС не существует отдельного слоя гипервизора. Вместо этого сама хостовая ОС отвечает за разделение аппаратных ресурсов между несколькими ВМ и поддержку их независимости друг от друга. Вывод. Несмотря на то, что сегодня конкурируют технологии полной виртуализации, паравиртуализации и аппаратной виртуализации, аналитики предсказали, что после 2010 г. главными станут именно технологии виртуализации уровня ОС. Примеры реализации: SWsoft Virtuozzo, Solaris Containers/Zones), Free BSD Jail, Linux-VServer, LXC (Linux Containers), Free VPS, Open. VZ и др. Замечание. Принципиальной исторической проблемой архитектуры x 86 была невозможность параллельного исполнения некоторых команд процессора в привилегированном режиме работы (что требуется для использования нескольких ОС). Для ее решения применялись полная виртуализация и паравиртуализация. Однако в 2004 -2005 гг. компании Intel и AMD внесли коррективы в архитектуру своих процессоров, реализовав в них соответственно технологии Intel VT и AMD SVM, которые сделали возможной параллельную работу ОС на аппаратном уровне. 50

Это существенно упростило создание средств виртуализации, что способствовало росту числа разработок в данной области. Правда, многие появившиеся в последнее время гипервизоры (например, Microsoft Hyper-V) изначально ориентированы на работу только с современными процессорами, оснащенными средствами Intel VT или AMD SVM. Типы гипервизоров. В настоящее время используются 3 типа: 1) гипервизор первого типа (Type 1, автономный, тонкий, исполняемый на «голом железе» , native, bare-metal) – программа, исполняемая непосредственно на аппаратном уровне компьютера и выполняющая функции эмуляции физического аппаратного обеспечения и управления аппаратными средствами и гостевыми ОС. Это гипервизор в узком понимании; 2) гипервизор второго типа (Type 2, хостовый, монитор виртуальных машин) – специальный дополнительный программный слой, расположенный поверх основной (базовой, хостовой) ОС, который в основном решает задачи управления гостевыми ОС, а эмуляцию и управление аппаратурой выполняет основная ОС; 3) гибридный гипервизор (Hybrid, Type 1+) – объединение первых двух типов, когда функции управления аппаратными средствами выполняются тонким гипервизором и специальной депривилегированной сервисной ОС, работающей под его управлением. Обычно гипервизор управляет напрямую процессором и памятью компьютера, а через сервисную ОС гостевые ОС уже работают с остальными аппаратными компонентами. Пример: гипервизор MS Virtual Server. 51

Виртуализация настольных ОС. Проблема виртуализации ПК с использованием нескольких ОС отличается от таковой для серверов меньшей степенью важности и тем, что основная сложность в случае с ПК заключается в необходимости поддержки очень широкого спектра аппаратных компонентов. И в результате получилось так, что сегодня для ПК используется только метод ВМ, причем исключительно в варианте гипервизора типа 2 с применением программной эмуляции аппаратуры через хостовую ОС. Безусловный лидер в этой сфере – продукт WMware Workstation, пионер x 86 виртуализации. В последние годы заметно растет популярность и Microsoft Virtual PC, которая распространяется бесплатно. В начале 2009 г. компании Citrix (совместно с Intel) и VMware объявили о планах выпуска гипервизоров для ПК. В результате реализации первого проекта стало возможным запускать на одном ПК несколько независимых ВМ. Первая ВМ поддерживает образ персональной системы, где пользователь может делать все, что хочет (работать с аппаратными компонентами, в частности, можно полностью задействовать графический ускоритель компьютера для просмотра видео, современных игр и т. д. ). Каждая из остальных ВМ представляет корпоративный вариант системы, доставляемый на данное рабочее место из центра обработки данных. В остальных ВМ используется режим эмуляции, т. е. корпоративная система применяется в изолированном окружении, с обеспечением безопасности корпоративных приложений и защитой от угроз. 52

Реализации гипервизоров. Сегодня используются два варианта гипервизора: VMware (тип 1) и Xen (гибридный, тип 1+), а также производные решения, предлагаемые компаниями Xen. Source, Oracle, Red Hat и Novell. Гипервизор Xen распространяется свободно, а VMware дополняет инфраструктуру Virtualization Infrastructure на базе технологии ESX этой компании, включающую в себя функции управления, такие как VMotion для восстановления после сбоев. А ранее, в 2008 г. Корпорация Microsoft выпустила свой гипервизор Hyper-V Server (тип 1+), а также технологию Hyper-V, которую включила в среду ОС Windows Server 2008. Компании Red Hat и Novell тоже предложили гипервизоры в качестве компонент своих ОС. Компания SWSoft (позднее Parallels) разработала собственную модель гипервизора как часть ПО виртуализации серверов Parallels Server. Корпорация Sun Microsystems разработала ПО x. VM Server и добавила свою (128 -разрядную) ФС ZFS и Fault Management Architecture в гипервизор, чтобы можно было использовать любую гостевую ОС. В ответ на шаги своих конкурентов компания VMware выпустила бесплатное серверное программное обеспечение VMware Server 2. 0, а также представила новый ESX Server 3 i – упрощенный гипервизор, который интегрирован в серверное аппаратное обеспечение и не требует поддержки ОС. Вывод. Таким образом, у пользователей появляется выбор: предпочесть гипервизор, встроенный в ОС, или гипервизор, устанавливаемый непосредственно (без ОС) на аппаратный сервер. При этом гипервизор рано или поздно станет продуктом, который производители компьютеров будут устанавливать на свои серверы, вообще не применяя какую-то отдельную ОС (!!). 53

А пользователи, со своей стороны, смогут подключать аппаратное обеспечение и сразу же начинать загрузку необходимых им гостевых ОС для создания требуемых ВМ. Показательные примеры работы без ОС (достоинства, недостатки, проблемы). 1. Компания BEA создала гипервизор Web. Logic Server Virtual Edition (WLS-VE), который вобрал в себя все то, в чем нуждается приложение, и что оно обычно получает от универсальной ОС. Он заменяет традиционную ОС своей ВМ Java (Java Virtual Machine, JVM) под названием Liquid. VM, базирующейся на ОС на основе микроядра. В свою очередь, JVM работает непосредственно на гипервизоре VMware, без какой-либо универсальной ОС (например, MS Windows или Linux) (!!). Кстати, Java-приложения являются идеальными кандидатами для запуска без универсальной ОС, поскольку они изначально исполнялись при помощи JVM. В данном случае JVM воспроизводит некоторые функции ОС, в том числе распределение памяти и ресурсов ЦП, а также сетевые функции. Кроме того, компания BEA добавила в Liquid. VM еще ряд функций, например, управление вводом-выводом, чем обычно занимается универсальная ОС. При этом гипервизор исполняет и другие функции, в частности, загрузку драйверов устройств, что тоже обычно входит в функцию ОС. Таким образом, компании BEA удалось полностью исключить из оборота ОС, поскольку ее функциональность взяли на себя JVM и гипервизор (!!). Эксперименты компании BEA показали, что гипервизор WLS-VE потребляет на 25 – 50% меньше ресурсов (памяти и циклов ЦП), чем традиционная ОС, но при этом 54 обеспечивает большую суммарную производительность.

В числе других достоинств – сокращение общего объема работы по администрированию, поскольку администратору не приходится сопровождать работу каждой отдельной ОС. 2. Но исполнение приложений без ОС имеет и недостатки. Например, компания First American не смогла установить на выбранную ею платформу программы-клиенты сторонних разработчиков, столкнувшись с альтернативой: найти подходящий Javaдрайвер или работать с традиционной ОС. При работе без ОС приходится отказываться от ряда традиционно полезных вещей. В частности, отсутствуют удобный ГИП и поддержка локальных устройств, в том числе принтеров, а вместо локального жесткого диска система WLS-VE должна использовать сетевую память (Network-Attached Storage, NAS). 3. Определенная проблема связана также с администрированием такой новой виртуализированной среды, поскольку многие продукты системного администрирования и администрирования приложений основаны именно на взаимодействии с ОС. В связи с этим может потребоваться дополнительное ПО для администрирования. Поэтому компания BEA разработала специальную многоагентную систему Liquid Operations Center, которая производит размещение и администрирование, как виртуализированных, так и невиртуализированных Javaприложений. 4. Следующая разработка компании VMware – упоминавшийся продукт ESX Server 3 i. Это гипервизор, интегрируемый с аппаратными серверами компаний Dell, Hewlett-Packard, IBM, Fujitsu и др. Эти серверы уже изначально будут загружаться в 55 режиме гипервизора.

5. В свою очередь, компания Xen. Source (в составе Citrix) реализовала продукт Xen. Express OEM Edition, позволяющий поставщикам серверов предустанавливать на свои системы гипервизор Xen. Замечание. В этом проявилось главное отступление от старого порядка, когда ОС представляла собой ядро программной инфраструктуры. С появлением продуктов ESX server 3 i и Xen. Express OEM гипервизор вообще подрывает позиции ОС и захватывает в серверной среде место действующего по умолчанию слоя ПО. И чем больше посреднических функций набирает этот виртуальный слой, тем сильнее он «врастает» в стандартную аппаратную и программную инфраструктуру корпоративных приложений. Выводы. 1. Гипервизор становится местом контакта между другими важнейшими функциональными уровнями корпоративных систем, включая уровень администрирования и уровень хранения данных. 2. По мере консолидации компаниями своей серверной инфраструктуры для сокращения затрат и формирования сервис-ориентированных пулов ресурсов, воздействие концепции виртуализации будет только расти. 3. От того, каким именно образом ВМ будут потреблять ресурсы, напрямую будут зависеть бесперебойность работы и коэффициент готовности системы, что окончательно сделает гипервизор ключевым элементом с точки зрения администрирования. 56

Лекция 10 4. Управление процессами и потоками 57

4. 1. Планирование процессов и потоков 4. 1. 1. Создание процессов и потоков Порождение процесса начинается с создания дескриптора (описателя) процесса – одной или нескольких информационных структур, содержащих все сведения о процессе, необходимые ОС для управления им: 1) идентификатор процесса, 2) данные о расположении в ОП его исполняемого модуля, 3) степень привилегированности процесса (приоритет и права доступа) и т. п. Примеры дескрипторов процесса: § § блок управления задачей (Task Control Block, TCB) в OS/360; блок управления процессом (Process Control Block, PCB) в OS/2; дескриптор процесса в UNIX; объект-процесс (object-process) в Windows NT. Создание дескриптора процесса знаменует собой появление в системе еще одного претендента на вычислительные ресурсы. Начиная с этого момента, ОС при распределении ресурсов должна принимать во внимание потребности нового процесса. Порождение процесса включает загрузку кодов и данных исполняемой программы данного процесса с диска в ОП. Для этого ОС должна обнаружить местоположение такой программы на диске, перераспределить ОП и выделить ее исполняемой программе нового процесса. Затем необходимо считать программу в выделенные для нее участки ОП, возможно изменяя параметры программы в зависимости от 58 размещения ее в памяти.

В системах с виртуальной памятью в начальный момент может загружаться только часть кодов и данных процесса, чтобы подкачивать остальные по мере необходимости. Существуют и такие ОС, где на этапе порождения процесса вообще не требуется загружать коды и данные в ОП. Вместо этого исполняемый модуль копируется в область подкачки на диске, специально отведенную для хранения кодов и данных процессов. При выполнении всех этих действий подсистема управления процессами тесно взаимодействует с подсистемой управления памятью и ФС. В многопоточной системе при порождении процесса ОС создает для каждого процесса один или несколько потоков выполнения. При создании потока ОС генерирует специальную информационную структуру – описатель потока, содержащий идентификатор потока, данные о его правах доступа, приоритете, состоянии потока и другое. Сначала поток находится в состоянии готовности. Выборка потока на выполнение осуществляется в соответствии с принятым в данной ОС правилом с учетом всех существующих в данный момент потоков и процессов. При нахождении в области подкачки необходимым условием активизации потока (процесса) является также наличие места в ОП для загрузки туда его исполняемого модуля. Но поток может обратиться к ОС с запросом на создание потоков-потомков. А отношения «потомки-родители» строятся в разных ОС по разному: 1) выполнение родительского потока синхронизируется с его потомками, а после завершения родительского потока ОС может снимать с выполнения и всех его потомков. 2) Потокипотомки могут выполняться и асинхронно по отношению к родительскому потоку. 3) Обычно потомки наследуют многие свойства родителей. 4) Во многих ОС 59 порождение потомков является основным механизмом создания процессов и потоков.

4. 1. 2. Планирование и диспетчеризация потоков На интервале существования процесса (ИСП) выполнение его потоков может быть многократно прервано и продолжено. Переход от выполнения одного потока к выполнению другого осуществляется в результате планирования и диспетчеризации. Планирование (Scheduling) – это работа по определению того, в какой момент необходимо прервать выполнение текущего активного потока и какому другому потоку предоставить возможность выполняться. Планирование потоков осуществляется на основе информации, хранящейся в описателях процессов и потоков. При планировании могут приниматься во внимание приоритет потоков, время их ожидания в очереди, накопленное время выполнения, интенсивность ввода-вывода и другие факторы. ОС планирует выполнение потоков независимо от того, принадлежат они одному или разным процессам. Планирование потоков заключается в решении двух задач: § § определение момента времени смены текущего активного потока; выбор для выполнения очередного потока из очереди готовых потоков. Используется множество различных алгоритмов планирования потоков, преследующих разные цели и обеспечивающих разное качество мультипрограммирования. Например, жесткое вытеснение потоков процессов по истечению кванта времени выполнения, максимально быстрое выполнение потоков «коротких» задач или потоков интерактивных приложений. Именно особенности планирования потоков и определяют специфику режимов мультипрограммирования. 60

В большинстве универсальных ОС планирование осуществляется динамически (on-line), когда решения принимаются во время работы ОС на основе оперативного анализа текущей ситуации. Процессы и потоки появляются в случайные моменты времени и также непредсказуемо завершаются. Динамические планировщики могут гибко приспосабливаться к изменяющейся ситуации и не прогнозируют состав мультипрограммной смеси. Учет этого потребовал бы значительных организационных затрат. Другой тип планирования – статический – используется в системах с заранее известным составом мультипрограммной смеси, например, в ОС РВ. Статический (предварительный) планировщик принимает решения заранее (off-line). Статический планировщик похож на диспетчера железной дороги, пропускающего поезда строго по известному расписанию, в то время как динамический планировщик – на регулировщика на перекрестке автодорог без светофоров. Результатом работы статического планировщика является таблица (расписание), где указывается, какому потоку/процессу, когда и на какое время должен быть предоставлен процессор. Для построения расписания планировщику нужны полные данные о характеристиках задач смеси (максимальном времени выполнения каждой задачи, ограничениях взаимодействующих процессов и т. д. ). Накладные расходы ОС на исполнение расписания оказываются значительно меньшими, чем при динамическом планировании, и сводятся лишь к диспетчеризации потоков/процессов. Диспетчеризация (Dispatching) заключается в реализации найденного планировщиком решения, то есть в переключении процессора с одного потока на 61 другой.

До прерывания выполнения потока ОС запоминает его контекст. Контекст отражает: § состояние аппаратуры компьютера во время прерывания потока (значение счетчика команд, содержимое регистров общего назначения, режим работы процессора, флаги, маски прерываний и другие параметры); § параметры операционной среды (ссылки на открытые файлы, данные о незавершенных операциях ввода-вывода, коды ошибок системных вызовов данного потока и т. д. ). Порядок диспетчеризации: 1) сохранение контекста текущего потока, подлежащего смене; 2) загрузка контекста нового потока, выбранного в результате планирования; 3) запуск нового потока на выполнение. А поскольку операция переключения контекстов существенно влияет на производительность ВС, программные модули ОС выполняют диспетчеризацию потоков совместно с более производительными аппаратными средствами процессора. В контексте потока можно выделить 2 части: § часть, общую для всех потоков данного процесса, – ссылки на открытые файлы; § часть, относящуюся только к данному потоку, – содержимое регистров процессора и счетчика команд, признак режима работы процессора. 62

Например, в сетевой ОС Net. Ware 4. x различают контексты: 1) глобальный (процесса), 2) группы потоков, 3) отдельного потока, что напоминает в плане доступа соотношение глобальных и локальных переменных в языках программирования. Переменные глобального контекста доступны всем потокам процесса, а переменные локального контекста – только кодам своего потока. Такая иерархическая организация контекстов ускоряет переключение потоков в группах, когда требуются лишь переключения локальных контекстов, а также потоков разных групп процесса, не требующие переключения глобального контекста. Переключение же глобальных контекстов необходимо лишь при переходе с потока одного процесса на поток другого процесса. ОС выполняет планирование потоков, учитывая их допустимые состояния. Очереди ожидающих и готовых потоков достаточно просто организуются путем объединения в списки их описателей. Значит, каждый описатель потока должен содержать и хотя бы один указатель на другой описатель, соседствующий с ним в очереди. Такая организация очередей позволяет легко их переупорядочивать, включать и исключать потоки, переводить потоки из одного состояния в другое и как следствие – между очередями ожидающих и готовых к выполнению потоков. На рис. 4. 1 показана очередь готовых потоков, где запланированный порядок выполнения – A, B, E, D, C. 63

Описатель потока A Описатель потока B Описатель потока C Описатель потока D Описатель потока E Ссылка Ссылка Рис. 4. 1. Очередь готовых потоков A-B-E-D-C 4. 1. 3. Вытесняющие и невытесняющие алгоритмы планирования Все множество алгоритмов планирования можно разделить на два класса: 1) вытесняющие, когда решение о прекращении выполнения потока (процесса) принимает ОС. В них ОС все диспетчерские функции выполняет централизованно; 2) невытесняющие, когда это решение принимается самим потоком, а не ОС, и даже не пользователем. Диспетчерские функции в них разделяются между ОС и приложением, а управление средой теряется на произвольный период времени, определяемый самим приложением. 64

Верхом «недружественности» приложения является его зависание в этот период. Поэтому разработчики приложений для ОС с невытесняющей многозадачностью вынуждены создавать приложения так, чтобы те выполняли свои задачи небольшими частями, чаще возвращая управление ОС, что затрудняет их реализацию. В системах с вытесняющей многозадачностью ситуации зависания, как правило, исключены, так как центральный планирующий механизм всегда может снять зависшую задачу с выполнения. Однако поручение части функций планирования приложению может быть и преимуществом, так как дает разработчику приложений (программисту) возможность самому проектировать алгоритм планирования, наиболее подходящий для данного фиксированного набора задач. Разработчик может сам определять момент возвращения управления, исключая нерациональные прерывания программ в «неудобные» для них моменты времени. Кроме того, снимаются проблемы разделения и защиты данных, так как программа использует их монопольно. Невытесняющее планирование обеспечивает и более высокую скорость переключения потоков. Выводы. 1. Почти во всех современных ОС, ориентированных на высокопроизводительное выполнение приложений, реализованы именно вытесняющие алгоритмы планирования потоков/процессов (UNIX, OS/2, Windows 9*/NT/2000/…/W 10). 2. Эффективный пример невытесняющего планирования – сетевая ОС Net. Ware версий 3. */4. * и последующих. 65

4. 1. 4. Алгоритмы планирования, основанные на квантовании В основе многих вытесняющих алгоритмов планирования лежит концепция квантования, когда каждому потоку поочередно для выполнения предоставляется ограниченный непрерывный интервал процессорного времени – квант. Смена активного потока происходит, если: 1) поток завершился и покинул систему; 2) произошла ошибка; 3) поток перешел в состояние ожидания; 4) исчерпан квант, отведенный данному потоку. Поток, исчерпавший свой квант, переводится в состояние готовности, активным делается новый поток из очереди готовых к выполнению. Типичное значение кванта в системах РДВ – десятки миллисекунд. При этом потокам могут выделяться одинаковые или разные кванты, величина кванта данного потока может быть постоянной (фиксированной) или переменой по мере его развития. Переменная величина кванта может возрастать или убывать. Учет отмеченных факторов увеличивает число возможных вариантов алгоритмов планирования. При переменной величине кванта ее убывание выгодно коротким задачам, а возрастание позволяет уменьшить накладные расходы на переключение задач, если сразу несколько задач выполняют длительные вычисления. 66

При интенсивном вводе-выводе поток не использует квант полностью. Такую дискриминацию можно компенсировать организацией дополнительной более приоритетной очереди готовых потоков, куда помещаются только потоки, прерванные из-за необходимости ввода-вывода. Многозадачные ОС теряют процессорное время для выполнения вспомогательных работ во время переключения контекстов задач. При этом запоминаются и восстанавливаются регистры процессора, флаги и указатели стека, а также проверяется статус задач для передачи управления. Затраты на эти вспомогательные действия не зависят от величины кванта времени, поэтому чем больше квант, тем меньше суммарные накладные расходы на переключение потоков. В алгоритмах планирования на основе квантования не используется никакой предварительной информации об особенностях решаемых задач (длительность, потребность в обмене, важность), она может накапливаться уже в ходе решения. 4. 1. 5. Алгоритмы планирования, основанные на приоритетах Другой важной концепцией, лежащей в основе многих вытесняющих алгоритмов планирования, является приоритетное обслуживание. Оно предполагает наличие у потоков некоторой изначально известной характеристики – приоритета, на основании которой определяется порядок их выполнения. Приоритет – это число, характеризующее степень важности (привилегированности) потока при использовании ресурсов компьютера, в частности – процессорного времени: чем выше приоритет, тем меньше времени поток будет проводить в очередях. Значение приоритета бывает: целое/дробное; положительное/отрицательное. 67

В некоторых ОС принято, что приоритет потока тем выше, чем больше его арифметическое значение, в других – наоборот, чем оно меньше. В большинстве многопоточных ОС приоритет потока непосредственно связан с приоритетом процесса, в рамках которого создан данный поток. Приоритет процесса назначает ОС при его порождении. Значение приоритета включается в описатель процесса и используется при назначении приоритета всем его потокам. При назначении приоритета процессу ОС учитывает, является ли процесс системным или прикладным, каков статус пользователя, запустившего процесс, было ли явное указание пользователя о присвоении процессу определенного уровня приоритета. А при создании потока системным вызовом от другого потока ОС (при назначении ему приоритета) должна учесть значение приоритета самого системного вызова. Во многих ОС предусмотрена возможность изменения приоритетов в течение жизни потока. Оно может происходить по инициативе самого потока, когда тот обращается в соответствующим вызовом к ОС или по инициативе пользователя при выполнении им соответствующей команды. Кроме того, ОС сама может изменять приоритеты потоков в зависимости от текущей ситуации в ВС. Изменяемые приоритеты – динамические, не изменяемые – статические. От приоритетов потоков существенно зависит эффективность работы всей ВС. В современных ОС во избежание разбалансировки системы от неправильного назначения приоритетов возможности пользователей по изменению приоритетов потоков и процессов стараются ограничивать. 68

Обычные пользователи, как правило, не имеют права повышать приоритеты своим потокам. Это могут делать (да и то) в определенных пределах только администраторы. Традиционно ОС присваивает приоритеты потокам по умолчанию. Рассмотрим схему назначения приоритетов в ОС Windows NT (рис. 4. 2). В системе определено 32 уровня приоритетов (с диапазоном значений 0 -31) и два класса потоков – потоки с переменными приоритетами (с диапазоном значений 1 -15) и потоки РВ (с диапазоном значений 16 -31). Приоритет 0 зарезервирован для системных целей. Потоки с переменными приоритетами Потоки РВ Динамический приоритет потоков процесса (2) (1) 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 Рис. 4. 2. Схема назначения приоритетов в ОС Windows NT 69

При порождении процесса он в зависимости от класса получает по умолчанию базовый приоритет K в верхней или нижней части диапазона (0 -31). На рис. 4. 2 он обозначен (1). Базовый приоритет процесса позднее может быть повышен или понижен ОС. А все потоки данного процесса первоначально получают базовый приоритет (2) из того же диапазона в интервале [K-2, K+2]. Значит, изменяя базовый приоритет процесса, можно влиять на базовые приоритеты его потоков. В ОС Windows NT с течением времени приоритет потока с переменными приоритетами может отклоняться от своего базового значения (2), причем эти изменения могут быть уже не связаны с изменениями базового приоритета процесса. ОС может повышать приоритет потока (называемый в этом случае динамическим), если поток не полностью использовал свой квант, или понижать его в противном случае. ОС наращивает приоритет дифференцированно в зависимости от типа события, не давшего потоку использовать свой квант. В частности, ОС повышает приоритет в большей степени потокам, ожидающим ввода с клавиатуры (интерактивным приложениям) и в меньшей – потокам, выполняющим дисковые операции. Именно на основе динамических приоритетов осуществляется планирование потоков. Начальной точкой отсчета для динамического приоритета является значение базового приоритета потока (2). Значение динамического приоритета потока ограничено снизу минимумом его базового приоритета (2), а сверху максимумом приоритета своего класса (рис. 4. 2). В ОС используются две разновидности приоритетного планирования: обслуживание с относительными и абсолютными приоритетами. В обоих случаях на выполнение из очереди готовых выбирается поток с наивысшим приоритетом. 1 час 70

Однако проблема определения момента смены активного потока решается поразному. При появлении в системе более приоритетного готового к выполнению потока при обслуживании с абсолютными приоритетами выполнение текущего потока прерывается. Он переводится в состояние готовности, а активным (на время кванта для вытесняющих алгоритмов или насколько потребуется потоку для невытесняющих алгоритмов) делается более приоритетный поток. При обслуживании с относительными приоритетами такого прерывания не происходит. В системах с абсолютными приоритетами время простоя потока в очередях можно свести к минимуму, назначив ему самый высокий допустимый приоритет (для вытеснения остальных потоков). 4. 1. 6. Смешанные алгоритмы планирования Во многих ОС алгоритмы планирования могут учитывать обе рассмотренные выше концепции. Например, в основе планирования лежит квантование, но величина кванта и/или порядок выбора потока из очереди готовых определяется приоритетами потоков. 1. Именно так организовано планирование в ОС Windows NT, где квантование сочетается с динамическими абсолютными приоритетами. На выполнение выбирается поток с наивысшим приоритетом и получает квант. Появившийся более приоритетный поток вытесняет выполняемый. Вытесненный поток возвращается в очередь готовых, причем там становится впереди всех остальных, имеющих равный приоритет. (!!!) 71

2. Еще более интересен алгоритм планирования в ОС UNIX System V Release 4. 2, где вообще отсутствуют потоки и поддерживается вытесняющая многозадачность, основанная на приоритетах и квантовании. Здесь процесс может относиться к одному из 2 классов: РВ (диапазон значений приоритетов 100 -159) или РДВ (0 -99), причем процессы РДВ делятся на пользовательские (0 -59) и системные (60 -99). Назначение и обработка приоритетов выполняются для процессов разных классов поразному. Процессы системные РДВ, зарезервированные для ядра ОС, используют стратегию фиксированных приоритетов. Их значения задаются ядром и никогда не изменяются. Процессы РВ также имеют фиксированные приоритеты, но пользователь может изменять их значения. Процессы РВ могут надолго захватывать процессор. Их характеризуют две величины: уровень глобального приоритета и квант. Для каждого уровня приоритета по умолчанию имеется своя величина кванта, что задается специальной внутренней таблицей ОС. По умолчанию новый процесс становится пользовательским РДВ. Состав процессов этого класса является наиболее неопределенным и часто меняющимся. Поэтому для справедливого распределения процессора между процессами этого класса используется стратегия динамических приоритетов. Величина приоритета пользовательского процесса РДВ вычисляется пропорционально значениям двух частей: пользовательской и системной. Причем, результат суммирования принудительно ограничивается значением 59, чтобы процесс не стал системным РДВ (!!!). Пользовательская часть может быть изменена администратором или владельцем процесса (в последнем случае только снижена). 72

Системная часть приоритета позволяет планировщику управлять процессами, имеющими долгие кванты. Приоритет таких процессов снижается, а процессов, часто не использующих свои кванты из-за ожидания окончания обмена, – повышается. Ущемленным (реже активизируемым) процессам с низкими приоритетами в компенсацию даются большие кванты, чем процессам с высокими приоритетами. 3. Планирование в OS/2 также основано на использовании квантования и абсолютных динамических приоритетов. Все потоки разделены на 4 класса (по убыванию приоритета): 1) критический (time critical). Например, системные потоки, решающие важнейшие задачи управления сетью; 2) серверный (server) – потоки, обслуживающие серверные приложения; 3) стандартный (regular) – потоки обычных приложений; 4) остаточный (idle) – наименее важные. Например, это поток, выводящий на экран заставку, когда в системе не выполняется никакой работы. В каждом классе имеется 32 уровня (значения) приоритета, что дает в сумме 128 уровней. Поток из менее приоритетного класса не может быть активизирован, пока в очереди более приоритетного класса имеется хотя бы один поток. Внутри каждого класса потоки выбираются также по приоритетам. Потоки с равными приоритетами обслуживаются в циклическом порядке (по карусельной схеме). Приоритеты потоков могут изменяться планировщиком OS/2 в следующих случаях: 73

1) если поток находится в состоянии готовности дольше, чем это задано системной переменной MAXWAIT, то OS/2 увеличит уровень его приоритета. При этом результирующее значение приоритета не должно переводить данный поток в критический класс; 2) если поток начинает операцию ввода-вывода, то после ее завершения он получит наивысшее значение приоритета своего класса; 3) при активизации потока его приоритет автоматически повышается. OS/2 динамически устанавливает и величину кванта потока в зависимости от степени загрузки системы и интенсивности подкачки. Средства настройки параметров OS/2 позволяют пользователю самостоятельно явно задать границы изменения величины кванта командой TIMESLICE = a, b (где a-b – задаваемый диапазон в пределах 32 -65536 мс, по умолчанию 32 -246 мс). Если поток был прерван до истечения кванта, то следующий квант его выполнения будет увеличен на 32 мс (один период таймера) и так много раз до тех пор, пока не будет достигнуто установленное значение b. Это позволяет уменьшить накладные расходы на переключение потоков, если в ВС несколько потоков одновременно ведут длительные вычисления. Благодаря такому алгоритму планирования в OS/2 ни один поток не будет «забыт» системой и получит достаточно процессорного времени. Кстати, командой THREADS = c можно явно задать (ограничить) число потоков в диапазоне 16 -255, по умолчанию c=64, из них 24 зарезервировано за самой OS/2, то есть являются системными. 74 Планирование в системах РВ рассмотрено в [2] по библиографии Уч. Пос ОС-2.

4. 1. 7. Моменты перепланировки Для реализации своего алгоритма планирования ОС должна получать управление всякий раз, когда в системе происходит событие, требующее перераспределения процессорного времени, например, это следующие 5 событий: 1) прерывание от таймера – конец кванта. Планировщик ОС переводит задачу (поток) в состояние готовности и выполняет перепланировку; 2) активная задача выполнила системный вызов – запрос на ввод-вывод или на доступ к ресурсу (например, файлу), который в настоящий момент времени занят. Планировщик переводит задачу в состояние ожидания и выполняет перепланировку; 3) активная задача 1 выполнила системный вызов, связанный с освобождением ресурса. Планировщик проверяет, не ожидает ли этот ресурс задача 2. Если да, то она получает ресурс и переводится в состояние готовности (если она не ожидает еще и другие ресурсы). При этом, возможно, что задача 2 имела приоритет выше, чем задача 1. После перепланировки более приоритетная задача 2 активизируется, вытесняя текущую задачу 1; 4) внешнее аппаратное прерывание, сигнализирующее о завершении УВВ операции ввода-вывода. Планировщик переводит соответствующую задачу в очередь готовых и выполняет перепланировку; 5) внутреннее прерывание, сигнализирующее об ошибке в результате выполнения активной задачи. Планировщик снимает задачу и выполняет перепланировку. 75

При возникновении каждого из этих событий планировщик ОС просматривает очереди задач и решает, какая задача будет выполняться следующей. Но существует и ряд других событий, часто связанных с системными вызовами, требующих перепланировки. Например, это запросы приложений и пользователей на создание новой задачи или повышение приоритета уже существующей, которые создают новую ситуацию, требующую пересмотра очередей и переключения процессора. В системах РВ для отработки статического расписания планировщик активизируется по прерываниям от таймера, возникающим через короткие постоянные интервалы времени (около 32 мс). После каждого прерывания планировщик просматривает расписание и проверяет, не пора ли переключить задачи. Кроме прерывания от таймера в системах РВ перепланировка задач может происходить по прерываниям от внешних устройств – различного вида датчиков и исполнительных механизмов. 4. 2. Диспетчеризация и учет приоритетов прерываний в ОС ОС должна играть активную роль в организации обработки прерываний. Но обеспечивая реакцию на асинхронные по отношению к вычислительному процессу события, прерывания в то же время создают дополнительные организационные трудности для ОС. В частности (4 примера трудностей): 1) они связаны с непредвиденными передачами управления от одной процедуры к другой, возникающими в результате прерываний от контроллеров УВВ; 2) возможны также непредвиденные внутренние прерывания (исключения), связанные с 76 ошибками во время выполнения инструкций;

3) усложняют планирование и запросы на выполнение системных функций – системные вызовы от пользовательских приложений, выполняемые с помощью программных прерываний; 4) наконец, сами модули ОС также часто вызывают друга с помощью программных прерываний, еще больше запутывая картину вычислительного процесса. ОС не может терять контроль над ходом выполнения системных процедур, вызываемых по прерываниям. Она должна упорядочивать их во времени так же, как планировщик упорядочивает многочисленные пользовательские потоки. Кроме того, сам планировщик потоков является системной процедурой, вызываемой по прерываниям (аппаратным – от таймера или контроллера УВВ, или программным – от приложения или модуля ОС). Поэтому правильное планирование процедур, вызываемых по прерываниям, является необходимым условием правильного планирования пользовательских потоков. Иначе могут возникать критические ситуации: 1) ОС будет долго «возиться» с медленным стримером (НМЛ), в то время как требующий мгновенного управления высокоскоростной дисковод будет ожидать указаний ОС и тормозить работу многих приложений; 2) обработчик прерываний принтера может надолго блокировать обработку прерываний от таймера, в результате чего остановится системное время, и важный для пользователя поток не получит управления вовремя. Для упорядочения работы обработчиков прерываний в ОС применяется тот же механизм, что и для пользовательских процессов – механизм приоритетных очередей. 77

Все источники прерываний обычно делятся на несколько классов, причем каждому классу присваивается приоритет. В ОС выделяется программный модуль, который занимается диспетчеризацией обработчиков прерываний – диспетчер прерываний, обеспечивающий обслуживание с абсолютными приоритетами. При возникновении прерывания диспетчер прерываний вызывается первым, запрещает ненадолго все прерывания, выясняет причину (и источник) прерывания. Затем диспетчер прерываний сравнивает назначенный данному источнику прерывания приоритет с текущим приоритетом потока команд, выполняемого процессором, и если новый приоритет выше текущего, запускает соответствующий обработчик. В этот момент времени процессор уже может выполнять инструкции другого обработчика прерываний, также имеющего некоторый приоритет. И если приоритет нового запроса выше текущего, то выполнение текущего обработчика приостанавливается, и он помещается в соответствующую очередь обработчиков прерываний. Иначе в очередь помещается обработчик нового запроса. (!!!) Приоритет обработчиков прерываний в общем случае всегда выше приоритета потоков, выполняемых в обычной последовательности, определяемой планировщиком потоков. Поэтому любой запрос на прерывание всегда может прервать выполнение обычного потока. Так как процедуры, вызываемые по запросам прерываний, обычно выполняют работу, не связанную с текущим процессом, то для них вводятся ограничения: они не имеют права использовать ресурсы процесса или от его имени запрашивать выделение дополнительных ресурсов. Ресурсы обработчиков прерываний принадлежат ОС, а 78 не конкретному процессу.

Поэтому обычно говорят, что процедуры обработки прерываний работают вне контекста процесса, хотя бывают и исключения (Windows NT). Выводы. Диспетчеризация прерываний является важной функцией, реализованной практически во всех мультипрограммных ОС. В общем случае в ОС реализуется двухуровневый механизм планирования работ. Верхний уровень планирования выполняет диспетчер прерываний, который распределяет процессор между потоком поступающих запросов на прерывания различных типов – внешние, внутренние и программные. Оставшееся процессорное время распределяет другой диспетчер – диспетчер потоков, на основании дисциплин квантования и других. 4. 3. Диспетчеризация системных вызовов Системный вызов позволяет приложению обратиться к ОС с просьбой выполнить то или иное действие, оформленное как процедура (или набор процедур) кодового сегмента ОС. Для прикладного программиста ОС выглядит как некая библиотека, представляющая некоторый набор полезных функций, с помощью которых можно упростить прикладную программу или выполнить действия, запрещенные в пользовательском режиме, например, обмен данными с УВВ. Уже говорилось, что реализация системных вызовов должна выполнить 5 требований: 1) обеспечивать переключение в привилегированный режим (часто только с помощью механизма программных прерываний); 2) обладать высокой скоростью вызова процедур ОС; 3) обеспечивать по возможности единообразное обращение к системным вызовам; 4) допускать легкое расширение набора системных вызовов; 79

5) обеспечивать контроль со стороны ОС за корректным использованием системных вызовов. Для выполнения всех этих требований обслуживание системных вызовов предпочтительно реализовать с использованием векторной системы программных прерываний, то есть закрепить за каждым системным вызовом определенное значение вектора. Тогда в приложении можно непосредственно указывать в аргументе запроса прерывания значение вектора (например, 22 h), после чего управление немедленно будет передано искомой процедуре ОС (рис. 4. 3). Виртуальное адресное пространство системы Таблица прерываний системы … Системный вызов Адрес процедуры 21 h Адрес процедуры 22 h Вектор =22 h Процедура обработки системного вызова 21 h Процедура обработки системного вызова 22 h Адрес процедуры 23 h … Рис. 4. 3. Обслуживание системных вызовов с использованием векторной системы программных прерываний (децентрализованная схема) Процедура обработки системного вызова 23 h 80

Однако этот децентрализованный способ передачи управления привязан к особенностям аппаратной платформы и не позволяет ОС легко модифицировать набор системных вызовов (требование 4) и контролировать их использование. К тому же добавление нового системного вызова в таблицу обработчиков прерываний вообще может стать неразрешимой проблемой ввиду отсутствия свободного элемента среди множества уже занятых аппаратными и внутренними прерываниями (а всего может быть не более 256 различных прерываний). Поэтому в большинстве ОС системные вызовы обслуживаются по централизованной схеме с диспетчером системных вызовов (рис. 4. 4). 81

Таблица sysent Таблица прерываний системы … Адрес процедуры 21 h Системный вызов Вектор=80 h, RQ=22 h Адрес диспетчера системных вызовов Адрес процедуры 22 h Адрес процедуры 23 h … Диспетчер системных вызовов Процедура обработки системного вызова 21 h Процедура обработки системного вызова 22 h Процедура обработки системного вызова 23 h Рис. 4. 4. Централизованная схема обслуживания с диспетчером системных вызовов Здесь при любом системном вызове приложение выполняет программное прерывание (INT) с определенным и единственным номером вектора. Например, ОС Linux использует для системных вызовов команду INT 80 h, а Windows NT на платформе Pentium – INT 2 Eh. 82

Перед выполнением программного прерывания приложение некоторым образом передает ОС номер системного вызова (например, 22 h), который является индексом в специально организованной дополнительной таблице sysent адресов процедур ОС, реализующих системные вызовы. Кроме номера передаются аргументы системного вызова. Диспетчер системных вызовов обычно представляет собой простую программу, которая: 1) сохраняет содержимое регистров процессора в системном стеке (в связи со сменой режима процессора); 2) проверяет, попадает ли запрошенный номер вызова в поддерживаемый ОС диапазон (в таблицу sysent адресов системных вызовов) и 3) передает управление адресованной процедуре ОС. Искомая процедура обработки системного вызова извлекает из системного стека аргументы и выполняет заданное действие. После завершения обработки системного вызова управление возвращается диспетчеру системных вызовов вместе с кодом завершения этого вызова. Диспетчер системных вызовов 1) восстанавливает регистры процессора, 2) помещает в определенный регистр код возврата и 3) выполняет инструкцию возврата из прерывания, которая восстанавливает непривилегированный режим работы процессора. Для прикладного программиста системные вызовы и библиотечные функции выглядят единообразно, поскольку он имеет дело с набором функций API, включающим библиотечные функции. А некоторые библиотечные функции пользуются для завершения работы системными вызовами. 83

Описанный табличный способ организации системных вызовов принят практически во всех ОС. Он позволяет легко модифицировать состав системных вызовов, просто добавив в таблицу sysent новый адрес и расширив диапазон допустимых номеров системных вызовов. ОС может выполнять системные вызовы в синхронном или асинхронном режиме. Поток (процесс), сделавший синхронный (блокирующий) системный вызов, переводится планировщиком ОС в состояние ожидания, а после завершения обработки вызова – в состояние готовности. Тогда при следующей активизации этот поток уже сможет воспользоваться результатами своего системного вызова. В свою очередь, асинхронный системный вызов не приводит к переходу потока в состояние ожидания результатов вызова. Вместо этого поток переводится в состояние готовности, пока активизируются короткие начальные системные действия (например, запуск операции ввода-вывода), но при этом неясно, когда поток сможет воспользоваться результатами данного системного вызова (? ) (это становится заботой самого потока). Выводы. Большинство системных вызовов в ОС являются синхронными, так как это избавляет приложение от работы по выяснению момента появления результатов вызова. Вместе с тем, в новых версиях ОС число асинхронных системных вызовов постепенно растет, что дает больше свободы разработчикам сложных приложений. Особенно нужны асинхронные системные вызовы в ОС на основе микроядра, так как при этом в пользовательском режиме работает часть модулей ОС, которым необходимо иметь полную свободу в организации своей работы, а такую свободу дает только асинхронный режим обслуживания вызовов микроядром. 84

Лекция 11 4. 4. Синхронизация процессов и потоков 4. 4. 1. Цели и средства синхронизации 1. В мультипрограммной среде любой поток всегда выполняется асинхронно и независимо от других. Поэтому нельзя точно предсказать ни момент достижения любой стадии решения задачи, ни момент получения готовых для дальнейшего использования данных. 2. Но в мультипрограммной ОС процессы (потоки) могут еще и взаимодействовать друг с другом, преследуя такие две важные цели: 1) обмен данными и 2) взаимная синхронизация исполнения. Организация этого взаимодействия осложняется тем, что оно происходит в условиях разделения (совместного использования) взаимодействующими процессами и потоками аппаратных и информационных ресурсов ВС. Синхронизация необходима для исключения дефектов (гонок и тупиков) при обмене данными между потоками, при разделении данных, при доступе к процессору и к УВВ. Во многих ОС подобные средства получили название - средства межпроцессного взаимодействия. 3. Любое взаимодействие процессов или потоков связано с их синхронизацией, которая заключается в согласовании их скоростей путем приостановки отдельного потока до наступления некоторого ожидаемого события с последующей активизацией данного потока при наступлении этого события. Причем, синхронизация требуется независимо от того, с чем именно связано взаимодействие (с разделением ресурсов или с обменом данными), так как процессы или потоки связаны отношением 85 «производитель-потребитель» .

4. Синхронизация необходима и при совместном использовании аппаратных ресурсов. Часто нужна и синхронизация с внешними по отношению к ВС событиями, например, с нажатием комбинации клавиш + . 5. Каждую секунду в системе происходят сотни событий, связанных с распределением и освобождением ресурсов, и ОС должна иметь надежные и производительные средства синхронизации потоков с этими событиями. Средства синхронизации используются в ОС и для ее внутренних нужд. 6. Для синхронизации потоков приложений программист может использовать как собственные средства и приемы (например, глобальные логические переменные), так и средства ОС, предоставляемые в форме системных вызовов. 7. Разработчики ОС предоставляют в распоряжение программистов набор разных по своим возможностям средств синхронизации. Эти средства могут образовывать иерархию, когда на основе более простых средств создаются сложные, или иметь функциональную специализацию (для синхронизации потоков одного процесса, потоков разных процессов при обмене данными и др. ). 8. Часто функциональные возможности разных системных вызовов синхронизации перекрываются так, что для решения одной задачи программист может воспользоваться несколькими системными вызовами в зависимости от личных предпочтений. 4. 4. 2. Гонки, блокирующие переменные, семафоры Рассмотрим основные понятия, связанные с синхронизацией потоков. 86

Гонки – ситуации, когда два или более потоков обрабатывают разделяемые данные, и конечный результат зависит от соотношения скоростей потоков. Критическая секция – это часть программы, результат выполнения которой может непредсказуемо меняться, если переменные, относящиеся к ней, изменяются другими потоками в то время, когда ее выполнение еще не завершено. Критическая секция всегда определяется по отношению к определенным критическим данным, при несогласованном изменении которых могут возникнуть нежелательные эффекты. Для исключения эффекта гонок по отношению к критическим данным необходимо обеспечить взаимное исключение, чтобы в каждый момент времени в критической секции находился только один поток. При этом обычно ОС использует разные способы реализации взаимного исключения, пригодные для потоков одного и/или разных процессов. Рассмотрим их. 1. Блокирующие переменные. Для синхронизации потоков одного процесса прикладной программист может использовать глобальные блокирующие переменные, доступные всем его потокам. Каждому набору критических данных D ставится в соответствие двоичная переменная F, которой поток присваивает значение F(D)=0 при вхождении в критическую секцию или F(D)=1 – при выходе из нее. Пока F(D)=0, другой поток, циклически проверяя это, не может войти в критическую секцию. Блокирующие переменные могут использоваться при доступе к разделяемым ресурсам любого вида. При этом механизм прерываний ОС работает и в критических секциях, но с одним ограничением. Нельзя прерывать поток между выполнением операций проверки и установки значения блокирующей переменной (это обеспечивается аппаратными или системными средствами). 87

2. Семафоры. Семафор – объект, ограничивающий число потоков, которые могут войти в заданный участок кода. Обобщением (двоичных) блокирующих переменных являются семафоры Эдсгера Дейкстры – переменные, принимающие целые неотрицательные значения. Для работы с семафорами (S) вводятся два примитива, традиционно обозначаемые P и V, и операции § V(S): S: =S+1 (здесь ‘: =‘ – знак «присвоить» ); § P(S): если S>0, то S: =S– 1, иначе поток, вызывающий операцию P(S), ожидает момента, когда станет S>0. Никакие прерывания и доступ к S во время выполнения примитивов V(S) и P(S) недопустимы. Частным случаем рассмотренного является двоичный семафор (блокирующая переменная). Операция P(S) способствует переходу вызывающего ее потока в состояние ожидания, операция V(S) – активизации приостановленного операцией P(S) потока. Далее рассмотрим использование семафоров на классическом примере взаимодействия двух потоков, один из которых записывает данные в группу буферов (буферный пул), а другой считывает их из пула (рис. 4. 5). 88

1 Заполненный 1 2 Заполненный 2 3 Заполненный 3 . Заполненный f → чтение . Пустой e ← запись . Пустой 3 . Пустой 2 N Пустой 1 Рис. 4. 5. Работа с буферным пулом (чтение и запись) Пусть пул включает N буферов, каждый буфер может содержать одну запись. В общем случае поток-писатель и поток-читатель могут обращаться к пулу с переменной интенсивностью. При этом скорость заполнения пула может превышать скорость освобождения и наоборот. Тогда для правильной совместной работы поток-писатель должен приостанавливаться при заполнении пула (в состоянии, когда некуда писать), а поток-читатель – при освобождении пула (в состоянии, когда нечего читать). 89

Введем 2 семафора: e – число пустых (empty) буферов, f – число заполненных (filled) буферов. N=e + f. В исходном состоянии e = N, f = 0 (все буферы пустые!). Поток-писатель выполняет операцию P(e): если e>0, то записывает данные в пустой буфер, делает уменьшение e: =e– 1 и выполняет операцию V(f): f: =f+1; иначе ожидание. Поток-читатель выполняет операцию P(f): если f>0, то читает данные из непустого буфера, делает уменьшение f: =f– 1 и выполняет операцию V(e): e: =e+1; иначе ожидание. Вывод. Буферный пул здесь является критическим ресурсом. А использование блокирующей переменной вместо семафора не позволяет организовать доступ к критическому ресурсу более чем одному потоку. А это актуально, если требуется сделать запись и чтение данных критическими секциями и обеспечить взаимное исключение. Семафор же решает эту задачу более гибко, допуская к разделяемому пулу ресурсов заданное число потоков. Здесь могут работать до N потоков, часть из которых – «писатели» , остальные – «читатели» . Существует и другая проблема синхронизации – взаимные блокировки или так называемые дедлоки (deadlocks), клинчи (clinches) или тупики, когда два и более потоков из-за занятости, запретов или ограничений доступа к ресурсам (памяти, УВВ) могут взаимно и неразрешимо мешать развитию друга. Необходимым условием возникновения тупика является потребность потока сразу в нескольких ресурсах. Но тупики следует отличать от очередей – нормального временного (и самостоятельно проходящего!) явления, демонстрирующего высокий коэффициент использования ресурсов при случайном поступлении запросов на них. 90

А тупиковые ситуации сами не могут разрешиться без воздействия извне, поэтому в составе ОС должны иметься средства заблаговременного предотвращения тупиков. На случаи, когда тупики все же возникают, администратору нужны средства их своевременного выявления, снятия и восстановления нормальной работы ВС(Их 5) 1. Тупики должны предотвращаться еще при написании приложений. 2. ОС при каждом запуске задач анализирует состав мультипрограммной смеси (требования задач к ресурсам). И запуск задачи, которая может вызывать тупик, временно откладывается. 3. ОС может также использовать особые правила выделения ресурсов процессам, например, строго последовательно и каждому процессу полностью. 4. Тупиковую ситуацию важно быстро и точно распознать. Если тупик образован множеством потоков, занимающих массу ресурсов, распознавание его становится нетривиальной задачей. Существуют формальные, программно реализованные методы распознавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаруживать взаимные блокировки алгоритмически. 5. Если же тупиковая ситуация все же возникла, совсем не обязательно снимать с решения все задачи или заблокированные потоки. Достаточно начать снимать некоторые из них, освобождая ожидаемые ресурсы. Можно вернуть некоторые потоки в область подкачки. Можно совершить откат некоторых потоков до так называемой контрольной точки, специально созданной программистом, где запоминается вся информация для восстановления выполнения программы с данного места и т. п. 91

4. 4. 3. Синхронизирующие объекты ОС Использование для синхронизации потоков глобальных переменных процесса не подходит для синхронизации потоков разных процессов (чужих) ! В таких случаях ОС должна предоставлять потокам свои собственные, так называемые системные объекты синхронизации, которые были бы доступны всем потокам, даже если они принадлежат разным процессам и работают в разных адресных пространствах. Примерами таких синхронизирующих объектов ОС являются системные семафоры, мьютексы, события, таймеры и др. Их набор зависит от конкретной ОС, которая создает эти объекты по запросам от процессов. Для разделения синхронизирующих объектов в разных ОС используются различные методы. Рассмотрим 4 метода, указывая метод в ( ). Некоторые ОС возвращают указатель на объект (Метод 1). Этот указатель далее может быть доступен всем родственным процессам, наследующим характеристики общего родительского процесса. В других ОС процессы в запросах на создание объектов синхронизации указывают имена, которые должны быть тем присвоены (Метод 2). Далее эти имена используются разными процессами для манипуляций объектами синхронизации, и работа с ними подобна удобной работе с файлами. Их можно создавать, открывать, уничтожать. Кроме того, для синхронизации могут быть использованы обычные объекты ОС: файлы, процессы, потоки (Метод 3). Все они могут находиться в двух состояниях: сигнальном (оповещающем) и несигнальном (свободном). А конкретный смысл 92 сигнального состояния зависит от типа объекта.

Например, поток переходит в сигнальное состояние, когда он завершается, процесс – когда завершаются все его потоки, файл – когда завершается операция его ввода-вывода (остальные объекты ОС – в результате выполнения специальных системных вызовов). Тогда приостановка и активизация потоков осуществляется в зависимости от состояния этих синхронизирующих объектов ОС. Как? Потоки с помощью специального системного вызова сообщают ОС о том, что они хотят синхронизировать свое выполнение с состоянием некоторого объекта. Будем далее называть этот системный вызов Wait(X), где X – указатель на объект синхронизации. А системный вызов, с помощью которого поток может перевести объект синхронизации в сигнальное состояние, назовем Set(X). Поток, выполнивший системный вызов Wait(X), ОС переводит в состояние ожидания до тех пор, пока объект X не перейдет в сигнальное состояние. Примеры системных вызовов типа Wait( ) и Set( ): sleep( ) и wakeup( ) в UNIX, Wait. For. Single. Object( ) и Set. Event( ) в Windows NT. Но в системе бывают и более сложные ситуации, требующие учета. Их иллюстрируют следующие примеры. 1. Поток может ожидать установки сигнального состояния не одного объекта, а сразу нескольких. При этом поток может попросить ОС активизировать его при установке либо одного из указанных объектов, либо всех этих объектов. 2. Поток может в качестве аргумента системного вызова Wait( ) указать также максимальное время, которое он будет ожидать перехода объекта в сигнальное состояние, после чего ОС должна его активизировать в любом случае. 93

3. Бывает и так, что установки некоторого объекта в сигнальное состояние ожидают сразу несколько потоков. Тогда в зависимости от объекта синхронизации в состояние готовности могут переводиться либо все ожидающие это событие потоки, либо один из них. Важно ! Но синхронизация тесно связана и с планированием потоков, например, § любое обращение потока с системным вызовом Wait( ) влечет за собой определенные действия в подсистеме планирования. Этот поток снимается с выполнения и помещается в очередь ожидающих потоков, а из очереди готовых потоков выбирается и активизируется новый поток; § при переходе объекта в сигнальное состояние (в результате выполнения некоторого потока – системного или прикладного) ожидающий этот объект поток (потоки) переводится в очередь готовых к выполнению потоков. В обоих случаях осуществляется перепланировка потоков. Кроме того, если в ОС предусмотрены изменяемые приоритеты и/или кванты времени, то они пересчитываются по своим правилам, принятым в этой ОС. Рассмотрим еще два примера, где синхронизирующими объектами выступают процессы и файлы. 1. Пусть выполнение некоторого приложения требует последовательных работ (этапов). Для каждого этапа организован свой отдельный процесс. Сигналом для начала работы каждого следующего процесса является завершение предыдущего. 94

Для реализации такой логики работы необходимо в каждом процессе, кроме первого, предусмотреть выполнение системного вызова Wait(X), в котором синхронизирующим объектом является предшествующий процесс. 2. Объект-файл, переход которого в сигнальное состояние соответствует завершению операции ввода-вывода с этим файлом, используется в тех случаях, когда инициировавший эту операцию поток решает дождаться ее завершения, прежде чем продолжить свои вычисления. Однако круг событий, с которыми потоку может потребоваться синхронизировать свое выполнение, не исчерпывается только лишь завершением процесса, потока или операции ввода-вывода. Поэтому в ОС, как правило, имеются и другие, более универсальные синхронизирующие объекты, такие как событие (event), мьютекс (mutex), системный семафор и др. (Метод 4). Мьютекс (от английского mutually exclusive access – взаимно исключающий доступ или взаимоисключение, когда одновременный доступ к общему ресурсу исключается), как и семафор, обычно используется для управления доступом к данным. Мьютекс устанавливается в особое сигнальное состояние, когда он не занят какимлибо потоком. Только один поток может владеть мьютексом. В отличие от обычных объектов (потоков, процессов, файлов), которые при переходе в сигнальное состояние переводят в состояние готовности все потоки, ожидающие этого события, объектмьютекс «освобождает» из очереди ожидающих только один поток. Работу мьютекса легко пояснить в терминах «владения переходящим пропуском» . Пусть поток, который, пытаясь получить доступ к критическим данным, выполнил системный вызов Wait(X), 95 где X – указатель на мьютекс.

Предположим, что мьютекс находится в сигнальном состоянии (свободен), в этом случае поток сразу же становится его владельцем, устанавливая его в несигнальное состояние, и входит в критическую секцию. После того, как поток выполнил работу с критическими данными, он «отдает» мьютекс, устанавливая его в сигнальное состояние. В этот момент мьютекс свободен и не принадлежит ни одному потоку. Если какой-либо поток ожидает его освобождения, то он становится следующим владельцем мьютекса, одновременно переводя его в несигнальное состояние. Объект-событие обычно используется для того, чтобы оповестить другие потоки о том, что некоторые действия завершены. Пусть, например, в некотором приложении работа организована так, что первый поток читает данные из файла в буфер памяти, а другие потоки обрабатывают эти данные, затем первый поток считывает новую порцию данных для обработки другими потоками и так далее. В начале работы первый поток устанавливает объект-событие в несигнальное состояние. Все остальные потоки выполнили вызов Wait(X), где X – указатель на это событие, и находятся в приостановленном состоянии, ожидая его наступления. Как только буфер заполняется, первый поток сообщает об этом ОС, выполняя вызов Set(X). ОС просматривает очередь ожидающих потоков и активизирует все потоки, ожидающие наступления этого события. 96

4. 4. 4. Сигналы Сигнал дает возможность задаче реагировать на событие, источником которого может быть ОС или другая задача. Сигналы вызывают прерывание задачи и выполнение определенных заранее предусмотренных действий. Сигналы могут вырабатываться синхронно (в результате работы самого процесса) или асинхронно (направляться процессу от другого процесса). Синхронные сигналы чаще всего приходят от системы прерываний процессора и свидетельствуют о действиях процесса, блокируемых аппаратурой, например, деление на 0, ошибка адресации, нарушение защиты памяти. Пример асинхронного сигнала – сигнал с терминала. Во многих ОС предусматривается оперативное снятие процесса с выполнения. Для этого пользователь может использовать некоторую комбинацию клавиш (+, +), в результате чего ОС вырабатывает сигнал и направляет его активному процессу. Сигнал может поступить в любой момент времени выполнения процесса, требуя немедленного его завершения. В данном случае реакцией на сигнал является безусловное завершение процесса. 97

В системе может быть определен целый набор сигналов. Программный код процесса, которому поступил сигнал, может в самом общем случае: 1) игнорировать его; 2) прореагировать на него принятым в системе стандартным действием (например, завершиться); 3) выполнить специфические действия, определенные прикладным программистом. В последнем случае в коде необходимо предусмотреть специальные системные вызовы, с помощью которых ОС информируется о том, какую именно процедуру надо выполнить в ответ на поступление того или иного сигнала. Выводы. Сигналы обеспечивают логическую связь между процессами, а также между процессами и пользователями (терминалами). А поскольку посылка сигнала предусматривает знание идентификатора процесса, то взаимодействие посредством сигналов возможно только между родственными процессами, которые могут получить данные об идентификаторах друга. В распределенных системах, состоящих из нескольких процессоров, каждый из которых имеет собственную ОП, ранее рассмотренные средства (блокирующие переменные, семафоры, сигналы) и другие аналогичные средства, основанные на разделяемой памяти, к сожалению, оказываются непригодными. В таких системах синхронизация может быть реализована только посредством явного обмена сообщениями. 98

1 час 5. Управление памятью 99

5. 1. Виды адресов, виртуальное адресное пространство и его структурирование Особая роль ОП объясняется тем, что процессор может выполнять инструкции программы только в том случае, если они находятся в ОП. ОП распределяется между всеми программными модулями (самой ОС и приложений). Функции мультипрограммной ОС по управлению памятью были рассмотрены в разделе 1. Управление памятью тесно связано с преобразованием адресов команд и данных, среди которых выделяют адреса: § виртуальные (математические, логические) – условные, вырабатываемые транслятором, переводящим программу и все ее авторские символьные имена на машинный язык. Во время трансляции в общем случае не известно, в какое место ОП будет загружена программа. Поэтому транслятор может присвоить переменным и командам только виртуальные (условные) адреса, по умолчанию начиная программу с нулевого адреса; § физические, соответствующие реальным номерам ячеек ОП, где могут быть расположены переменные и команды. Совокупность виртуальных адресов процесса называется его виртуальным адресным пространством (ВАП). ВАП имеет конкретный размер, ограниченный только возможностями адресации. Диапазон возможных адресов ВАП у всех процессов данной ОС является одним и тем же. Например, при 32 -разрядных виртуальных адресах он составляет 000016 – FFFF 16. Таким образом, каждый процесс имеет собственное ВАП с независимыми виртуальными адресами переменных и кодов, как показано на рис. 5. 1. 100

Виртуальные адреса ВАП Процесса A FFFF 16 00 A 8071516 Инструкция MOV R 1, P 12 Подпрограмма f 1 000016 ВАП Процесса B FFFF 16 00 A 8071516 Подпрограмма f 1 Инструкция MOV R 1, P 12 000016 ВАП Процесса C FFFF 16 00 A 8071516 Переменная a 2 000016 Рис. 5. 1 Оперативная память В разных ОС используются различные способы структурирования ВАП: 1) плоская (flat) структура – в виде непрерывной линейной последовательности виртуальных адресов. Здесь адрес определяется как число m, задающее смещение относительно начала ВАП, как показано на рис. 5. 2, а; 2) ВАП делится на части одного вида – сегменты (области и т. п. ). Виртуальный адрес в этом случае представляет собой пару чисел вида (номер сегмента, смещение внутри сегмента), как показано на рис. 5. 2, б; 3) ВАП делится на части нескольких видов, что усложняет адрес до нескольких 101 чисел.

Сегмент K (n, m) m m Сегмент n Сегмент 1 а) б) Рис. 5. 2. Способы структурирования ВАП: а) плоская структура; б) разделение на сегменты Задачей ОС является отображение индивидуальных ВАП всех одновременно выполняющихся процессов на общую физическую ОП. (см. рис. 5. 1) Существует два принципиально различных способа преобразования виртуальных адресов в физические: 102

1) специальная системная программа (перемещающий загрузчик) всего один раз для каждого процесса на основании данных о начальном адресе физической памяти, в которую предстоит загружать эту программу, а также информации транслятора об адресно-зависимых элементах программы, выполняет загрузку программы в ОП, совмещая ее с заменой виртуальных адресов физическими. При этом перемещающий загрузчик жестко привязывает программу к первоначально выделенному ей участку ОП; 2) программа загружается в ОП, начиная с физического адреса S, но в неизменном виде, с виртуальными адресами операндов инструкций и переходов, которые выработал транслятор (рис. 5. 3). При этом ОС фиксирует смещение (S) действительного расположения программного кода относительно начального адреса физической памяти. А преобразование виртуального адреса в физический выполняется уже во время выполнения программы при каждом обращении к ОП: виртуальный адрес VA заменяется физическим (VA+S). Такое динамическое преобразование виртуальных адресов позволяет перемещать программный код процесса в течение всего периода его выполнения. 103

MOV VA, R 0 VA 00… 00 VA Смещение S 00… 00 Физический адрес: VA + S Рис. 5. 3. Загрузка программы в ОП, начиная с физического адреса S, в неизменном виде В некоторых специализированных ОС, когда заранее известно точное место выполнения программы в ОП, транслятор может выдавать исполняемый код сразу в физических адресах. 104

Следует различать два понятия: § максимально возможное ВАП процесса. Максимальный размер ВАП определяется архитектурой компьютера и разрядностью схем его адресации. Например, работая на 32 -разрядных процессорах Intel Pentium, ОС может предоставить процессу ВАП до 232 байт = 4 Гбайт. Этот потенциально доступный максимальный размер ВАП редко на практике бывает необходим процессу; § назначенное (выделенное) процессу ВАП – набор виртуальных адресов, действительно необходимых процессу для работы. Эти адреса первоначально назначает программе транслятор на основании ее текста, когда создает кодовый сегмент и сегменты данных, с которыми программа работает. Затем, при порождении процесса ОС фиксирует назначенное ВАП в своих системных таблицах. В ходе своего выполнения процесс может увеличить размер первоначального назначенного ему ВАП, запросив у ОС создания дополнительных сегментов или увеличения размера существующих сегментов. ОС следит за корректностью использования процессом его виртуальных адресов (в пределах назначенных сегментов ВАП). Сегодня типична ситуация, когда доступный объем ВАП превышает доступный объем ОП. Поэтому ОС для хранения данных ВАП процесса, не помещающихся в ОП, использует внешнюю память (жесткий диск). Именно на этом принципе и основана виртуальная память – наиболее совершенный механизм управления памятью в ОС. Содержимое назначенного процессу ВАП (коды команд, исходные и промежуточные данные, результаты вычислений) представляет собой образ процесса. 105

Единое ВАП. Во время работы процесса постоянно выполняются переходы от прикладных кодов к кодам ОС (например, в случае явного вызова системных функций, вызова как реакции на внешние события или исключительные ситуации в работе приложения и др. ). Для упрощения передачи управления от прикладного кода к коду ОС, а также для легкого доступа модулей ОС к прикладным данным в большинстве ОС для каждого процесса сегменты ОС и его прикладные сегменты образуют единое ВАП. При этом обычно ВАП процесса делится на две непрерывные части: системную и пользовательскую. Их размер может быть разным, например, в Windows NT он составляет по 2 Гбайта для ОС и для приложений. Системная часть ВАП каждого процесса, отводимая под сегменты ОС, является идентичной для всех процессов. Поэтому при смене активного процесса заменяется только вторая пользовательская часть ВАП, содержащая его индивидуальные сегменты (коды и данные приложения) (рис. 5. 4). Архитектура современных процессоров отражает эту особенность структуры ВАП. Например, в процессорах Intel Pentium существуют две системные таблицы: первая – для описания сегментов, общих для всех процессов, вторая – для описания индивидуальных сегментов данного процесса. Тогда при смене процесса первая таблица сохраняется, а вторая заменяется новой. 106

1 2 N Индивидуальные части ВАП процессов - заменяются Общая часть ВАП процессов - сохраняется Рис. 5. 4. Две части ВАП процессов Механизм вытеснения (например, страничной памяти) в большинстве универсальных ОС применяется ко всем сегментам пользовательской части ВАП процесса. Системная часть виртуальной памяти в ОС любого типа, в свою очередь, включает область, подвергаемую вытеснению, и область, на которую вытеснение не распространяется. В невытесняемой области размещаются модули ОС, требующие быстрой реакции или постоянного присутствия в ОП. 107

5. 2. Алгоритмы распределения памяти 5. 2. 1. Классификация алгоритмов распределения памяти Все алгоритмы распределения ОП делятся на два класса, работающие § без использования внешней памяти: Ø распределение фиксированными разделами. ОП на сеанс работы разбивается на несколько разделов фиксированной величины каждый. К разделам организуется одна или несколько очередей процессов, Ø распределение динамическими разделами, по мере порождения процессов. Алгоритм связан с различными вариантами поиска свободной области ОП для раздела, отличается большей гибкостью, но подвержен эффекту фрагментации, Ø распределение перемещаемыми разделами. Используется как метод борьбы с фрагментацией на основе ликвидации «дыр» в ОП; § с использованием внешней памяти: Ø страничное распределение, когда частями ОП и ВАП являются страницы фиксированного и сравнительно небольшого размера, Ø сегментное распределение, когда частями ОП и ВАП являются сегменты произвольного размера (какой получится у программиста), организованные с учетом смыслового значения данных, Ø сегментно-страничное распределение – комбинация двух предыдущих алгоритмов, когда ВАП делится на сегменты, которые затем делятся на страницы. 108

5. 2. 2. Свопинг и виртуальная память Виртуализация памяти осуществляется совокупностью программных модулей ОС и аппаратных схем процессора и включает решение следующих задач: 1) 2) 3) 4) размещение данных в ОП и на диске; выбор образов процессов или их частей для перемещения из ОП на диск и обратно; перемещение по мере необходимости данных между ОП и диском; преобразование виртуальных адресов в физические (ключевая задача !). Виртуализация памяти может быть осуществлена на основе двух различных подходов: свопинг (swapping – подкачка) – образы процессов выгружаются на диск и возвращаются в ОП целиком. Подкачке свойственна избыточность, так как часто достаточно было бы загрузить/выгрузить лишь часть образа процесса. Кроме того, перемещение избыточной информации замедляет работу системы, приводит к неэффективному использованию ОП. Нельзя загрузить для выполнения процесс, ВАП которого превышает размер свободной ОП; виртуальная память – между ОП и диском перемещаются части образов процессов (страницы, сегменты). Для временного хранения сегментов и страниц на диске отводится либо специальная область, либо специальный файл, который по традиции продолжают называть областью или файлом свопинга (swap-файлом), хотя перемещение между ОП и диском давно осуществляется уже не процессами целиком, а их частями. 109

Используется и другое название – страничный файл (page file, paging file). Текущий размер страничного файла является важным параметром: чем он больше, тем больше приложений может одновременно выполнять ОС при фиксированном размере ОП. Но при этом их работа замедляется, так как значительная часть времени тратится на перекачку кодов и данных из ОП на диск и обратно. Из-за своих недостатков свопинг как основной механизм управления памятью почти не используется в современных ОС. Например, в версиях UNIX, основанных на System V Release 4, свопинг служит дополнением виртуальной памяти и включается лишь при серьезных перегрузках системы (для разбора «завалов» ). Ввиду многократного изменения местоположения образов процессов и их частей в ОП, ключевой проблемой виртуальной памяти является преобразование виртуальных адресов в физические. Решение этой проблемы зависит от способа структурирования ВАП, принятого в конкретной системе управления памятью. Известны три основных варианта реализации виртуальной памяти, оперирующих разными единицами перемещения данных между ОП и диском: 1) страничная виртуальная память, обеспечивающая перемещение страниц фиксированного небольшого размера; 2) сегментная виртуальная память, выполняющая перемещение данных сегментами произвольного размера; 3) сегментно-страничная виртуальная память, поддерживающая сегменты, поделенные на страницы, и перемещение страниц. 110

5. 3. Страничное распределение памяти Размер ВАП процесса в общем случае не кратен размеру страницы. Размер страницы специально выбирается равным 2 k байт, например, 29 = 512 байт, 210 = 1024 байт, 212 = 4096 байт = 4 Кбайта, что упрощает механизм преобразования адресов. При порождении процесса ОС загружает в ОП несколько его виртуальных страниц (начальные страницы кодового сегмента и сегмента данных). Страницы могут быть расположены в ОП не подряд. Копия всего ВАП находится на диске. Таблица страниц. Для каждого порождаемого процесса ОС создает в ОП таблицу страниц, содержащую записи о каждой виртуальной странице процесса – дескрипторы страниц (рис. 5. 5). 111

Виртуальные страницы ВАП Процесса 1 Таблица страниц Процесса 1 Стр. 0, Проц. 1 7 Стр. 1, Проц. 1 3 Физические страницы ОП 0 Стр. 4, Проц. 1 Стр. 2, Проц. 1 1 2 Стр. 3, Проц. 1 Стр. 1, Проц. 1 Стр. 4, Проц. 1 1 Виртуальные страницы ВАП Процесса 2 Стр. 0, Проц. 2 4 Таблица страниц Процесса 2 5 3 Стр. 0, Проц. 2 5 6 Стр. 0, Проц. 1 Стр. 1, Проц. 2 7 8 Стр. 2, Проц. 2 14 Стр. 5, Проц. 2 9 Стр. 3, Проц. 2 110 Стр. 4, Проц. 2 111 Стр. 5, Проц. 2 9 Стр. 6, Проц. 2 12 113 Стр. 2, Проц. 2 114 Рис. 5. 5. Таблицы страниц Процессов 1 и 2 Дескриптор страницы включает: 1) номер физической страницы, куда загружена данная виртуальная страница; 2) признак присутствия, равный 1, если данная виртуальная страница загружена в ОП; 112

3) признак модификации, равный 1, если данная виртуальная страница была изменена и при выгрузке ее (как обновленную) надо будет скопировать на диск; 4) признак обращения, равный 1 при каждом обращении к данной виртуальной странице. С каждой страницей связан счетчик числа обращений. ОС периодически просматривает признаки обращения и обнуляет ненулевые значения, одновременно наращивая значение соответствующего счетчика. Чтобы учесть интенсивность обращений за последний период, ОС с соответствующей периодичностью обнуляет все счетчики. Таблица страниц нужна для решения вопроса о перемещении страниц, а также преобразования виртуального адреса в физический. Адрес самой таблицы страниц включается в контекст процесса, а при активизации процесса загружается в специальный регистр процессора (далее будем считать, что он известен!). При каждом обращении к памяти (по какому-то адресу) выполняется поиск номера виртуальной страницы, содержащей требуемый адрес, затем по этому номеру определяется нужный дескриптор страницы, и из него извлекается описывающая страницу информация. Если признак присутствия равен 1 (страница находится в ОП), то выполняется преобразование виртуального адреса в физический. В противном случае (страницы нет в ОП !) происходит страничное прерывание. Далее активный процесс переводится в состояние ожидания, активизируется один из других готовых процессов. Параллельно программа обработки страничного прерывания находит на диске требуемую виртуальную страницу в страничном файле и пытается загрузить ее в ОП. 113

Лекция Если в ОП имеется свободная физическая страница, то загрузка 12 выполняется немедленно. В противном случае на основе принятой в данной ОС специальной стратегии замещения страниц в ОП выбирается некоторая «ненужная» страница - «жертва» . Обнуляется ее признак присутствия и анализируется признак модификации. Если признак модификации равен 1 (страница изменялась), то вытесняемую (обновленную) страницу необходимо скопировать на ее же место в образе процесса на диске, иначе искомая физическая страница просто объявляется свободной (в некоторых ОС для повышения надежности она может еще и обнуляться). Преобразование виртуального адреса в физический. Виртуальный адрес при страничном распределении представляется парой чисел (p, s), где p – порядковый номер виртуальной страницы данного процесса, начиная с 0, s – смещение в пределах страницы. Физический адрес имеет вид (n, s), где n – порядковый номер физической страницы в ОП. Смещение не зависит от типа страницы. Размер страницы 2 k дает возможность легко разделять составляющие адреса в двоичном представлении: смещение s занимает младшие k разрядов. Например, при k=10 адрес 50718 в двоичном представлении: p/n s 10 1 000 111 001 5 0 7 1 Аппаратно выполняются следующие действия (рис. 5. 6). Из специального регистра процессора извлекается (начальный) адрес таблицы страниц активного процесса (AT). 114

Виртуальный адрес: Номер виртуальной страницы – p Таблица страниц активного процесса Регистр процессора AT (начальный адрес таблицы страниц) Смещение в виртуальной странице – s a = AT+p×L n Физический адрес: Номер физической страницы – n Смещение в физической странице – s Рис. 5. 6. Преобразование виртуального адреса в физический при страничной организации памяти Длина дескриптора страницы (L) известна, номер виртуальной страницы (p) можно выделить из виртуального адреса. Тогда адрес дескриптора нужной страницы 115 (a) можно определить как a = AT + p × L.

Из дескриптора страницы извлекается значение номера физической страницы (n), к которому присоединяется справа значение смещения в виртуальной странице (s) – эта операция присоединения (конкатенации) выполняется быстрее обычного сложения. На производительность системы влияет частота страничных прерываний, которая зависит от размера страницы и стратегии замещения страниц. Известны следующие стратегии замещения: Least Recently Used (LRU) – последний из недавно используемых (дольше всех не используемый, «удаление стариков» ); Least Frequently Used (LFU) – используемый реже всех остальных (по минимальному значению счетчика числа обращений); «первым пришел – первым обслуживается» (First In – First Out, FIFO); случайная; упреждающей загрузки «лишних» прилегающих страниц и др. Выбор оптимального размера страницы является сложной оптимизационной задачей, требующей учета многих факторов. Известное рациональное решение – 4 Кбайта. Но размер страницы определяет: максимальное число страниц и число дескрипторов страниц, а также «накладные расходы» ОП на хранение дескрипторов. Пример. При размере ВАП процесса 4 Гбайта, страницы – 4 Кбайта, длине дескриптора страницы – 4 байта только для хранения таблицы страниц может потребоваться 4 Гбайта / 4 Кбайта × 4 байта = 4 Мбайта ОП. Выход из положения состоит в том, чтобы распространить идеи замещения и на саму таблицу страниц, оставляя в ОП лишь ее необходимые части. Используется и более сложное двухуровневое структурирование ВАП процесса, когда ВАП вначале делится на равные разделы, которые затем делятся на равные страницы размера 2 k. Число страниц в разделе – 2 n для удобства преобразования. 116

Тогда состав виртуального адреса получает следующий вид: m разрядов n разрядов k разрядов Номер раздела Номер страницы Смещение Для каждого раздела строится собственная таблица страниц. Число дескрипторов в таблице и их длина подбираются так, чтобы объем самой таблицы стал равным объему страницы. Например, при объеме таблицы (страницы) 4 Кбайта и длине дескриптора 4 байта число дескрипторов определяется как 4 Кбайта / 4 байта = 1024 = 210 (n = 10). Каждый раздел описывается дескриптором, идентичным дескриптору обычной страницы. Дескрипторы разделов сведены в таблицу разделов (каталог страниц). Физический адрес таблицы разделов активного процесса также содержится в специальном регистре процессора и поэтому всегда тоже известен ОС. Но с таблицей страниц связана одна важнейшая особенность: страница, содержащая таблицу разделов, никогда не выгружается из ОП, иначе работа виртуальной памяти была бы невозможна. Выгрузка страниц с таблицами страниц позволяет экономить ОП, но приводит к дополнительным временным затратам при получении физического адреса, когда искомой страницы нет в ОП. Схема преобразования адресов при такой двухуровневой структуризации ВАП показана на рис. 5. 7. 117

(m разрядов) (n разрядов) (k разрядов) Виртуальный Номер раздела адрес: Таблица разделов Номер виртуальной страницы в разделе Смещение Таблица страниц раздела Дескриптор виртуальной страницы Дескриптор таблицы страниц раздела Физический адрес: Номер физической страницы Смещение Рис. 5. 7. Схема преобразования адресов при двухуровневой структуризации ВАП Преобразование производится в следующем порядке. 1. Отбрасыванием младших (k+n) разрядов в виртуальном адресе определяется номер раздела, к которому принадлежит данный виртуальный адрес. 118

2. По этому номеру раздела из таблицы разделов извлекается дескриптор таблицы страниц этого раздела. Если данная таблица страниц отсутствует в ОП, происходит страничное прерывание, и ОС загружает страницу с этой таблицей с диска. 3. Из найденной таблицы страниц извлекается дескриптор виртуальной страницы, номер которой указан в средних n разрядах исходного виртуального адреса. Если этой виртуальной страницы нет в ОП, происходит страничное прерывание и ее загрузка. 4. Из дескриптора виртуальной страницы определяется номер (базовый адрес) физической страницы, в которую должна быть загружена данная виртуальная страница. К номеру физической страницы пристыковывается (справа операцией конкатенации) смещение, взятое из младших k разрядов исходного виртуального адреса, в результате чего и получается искомый физический адрес. Замечание. Страничное распределение ОП может быть реализовано и упрощенно, вообще без выгрузки страниц, когда все виртуальные страницы всех процессов постоянно находятся в ОП. Это позволяет только бороться с фрагментацией ОП. 5. 4. Сегментное распределение памяти При страничной организации памяти ВАП процесса делится на равные части механически, без учета смыслового значения данных. Это не позволяет эффективно дифференцировать доступ для записи к сегментам кода или сегментам данных процесса. А разбиение ВАП на «осмысленные» части сделало бы принципиально возможным совместное использование фрагментов программ разными процессами. Например, когда двум процессам может потребоваться одна и та же реентерабельная (повторно 119 используемая) подпрограмма.

Тогда ее можно в качестве сегмента включить в ВАП обоих процессов, а при отображении в физическую память – сегменты ВАП с этой подпрограммой проецировать на одну и ту же область физической памяти, как, например, Сегмента 3 Процесса А и Сегмента 1 Процесса B на рис. 5. 8. Так оба процесса получат доступ к единственной копии подпрограммы в ОП. ВАП Процесса A Сегмент 0 Сегмент 1 Сегмент 2 Сегмент 3 Таблица сегментов Процесса A Адрес в ОП Сегменты ОП Адрес в ОП Сегм. 0, Проц. A (Выгружен) Адрес в ОП Сегм. 1, Проц. A (Выгружен) ВАП Процесса B Сегмент 0 Сегмент 1 Таблица сегментов Процесса B Сегм. 0, Проц. B Адрес в ОП Сегмент 4 Сегм. 3, Проц. A и Сегм. 1, Проц. B Адрес в ОП Сегм. 2, Проц. B (Выгружен) Сегмент 2 Сегмент 3 (Выгружен) Адрес в ОП Сегмент 4 Сегм. 5, Проц. B Сегм. 6, Проц. B Сегмент 5 Сегмент 6 Рис. 5. 8. Таблицы сегментов Процессов А и B 120

При сегментной организации памяти ВАП процесса делится на части – сегменты, размер которых определяется с учетом смыслового значения содержащейся в них информации (подпрограмма, массив данных и т. п. ). Деление ВАП на сегменты производится компилятором на основе указаний программиста или по умолчанию, в соответствии с принятыми в системе соглашениями. Размер сегмента ограничивается лишь разрядностью виртуального адреса, например, при 32 -разрядной адресации сегмент может занимать до 4 Гбайт. В каждом сегменте виртуальные адреса находятся в диапазоне от 000016 до FFFF 16. А ВАП процесса представляет собой набор N виртуальных сегментов, не упорядоченных друг относительно друга, как показано на рис. 5. 9, где базовые (начальные) физические адреса сегментов обозначены S 1, S 2, S 3. 121

ВАП процесса FF…FF ВАП Сегмента 1 Сегмент 2 00… 00 FF…FF ВАП Сегмента 2 Сегмент 3 S 2 00… 00 Сегмент 1 FF…FF S 3 ВАП Сегмента 3 S 1 00… 00 Оперативная память Рис. 5. 9. ВАП процесса как набор виртуальных сегментов ОС переводит активный процесс в состояние ожидания, активизирует очередной процесс, а параллельно организует загрузку нужного сегмента с диска. А при отсутствии в ОП свободного места для загрузки данного сегмента, ОС выбирает «ненужный» сегмент (жертву) для выгрузки по критериям, аналогичным критериям выгрузки страниц. 122

При порождении процесса во время загрузки его образа в ОП ОС создает таблицу сегментов процесса, подобную таблице страниц и содержащую в дескрипторе каждого сегмента: базовый физический адрес сегмента в ОП; размер сегмента; правила доступа к сегменту; признаки: модификации, присутствия и обращения к сегменту, а также некоторую дополнительную информацию. Если ВАП нескольких процессов включают один и тот же сегмент, то в таблицах сегментов этих процессов делаются ссылки на один и тот же участок ОП, в который данный сегмент загружается в единственном экземпляре. Например, так была реализована динамическая компоновка в OS/2. Преобразование виртуального адреса в физический. Виртуальный адрес при сегментной организации памяти может быть представлен парой (g, s), где g – номер сегмента, s – смещение в сегменте. Физический адрес получается путем сложения базового физического адреса в ОП сегмента g (определяется из таблицы сегментов по его номеру g) и смещения s, как показано на рис. 5. 10. 123

Виртуальный адрес: Номер сегмента – g Смещение в сегменте – s Таблица сегментов Базовый адрес сегмента + Физический адрес: Рис. 5. 10. Преобразование виртуального адреса в физический при сегментной организации памяти Конечно, использование операции сложения замедляет процедуру преобразования виртуального адреса в физический по сравнению со страничной организацией (с ее операцией конкатенации). Другим недостатком сегментного распределения является избыточность. 124

Единицей перемещения между ОП и диском является сегмент, имеющий в общем случае размер, превышающий (и часто намного) размер страницы. Однако во многих случаях для продолжения работы программы было бы достаточно загрузки/выгрузки не всего сегмента, 1 -2 или нескольких страниц. Но главный недостаток сегментного распределения – фрагментация из-за непредсказуемости размеров сегментов. Система с сегментной организацией функционирует аналогично системе со страничной организацией. Одним из существенных отличий и преимуществ сегментной организации памяти по сравнению со страничной является возможность задания дифференцированных прав доступа процесса к его сегментам. Например, к сегменту исходных данных – только чтение, к сегменту данных-результатов – чтение и запись. 5. 5. Сегментно-страничное распределение памяти Это комбинация страничного и сегментного механизмов управления памятью с реализацией достоинств обоих подходов: 1) ВАП процесса разделено на сегменты, что обеспечивает поддержку разных прав доступа; 2) перемещение данных между ОП и диском осуществляется страницами. Для этого каждый виртуальный сегмент и вся физическая память делятся на страницы равного (фиксированного) размера, что позволяет более эффективно использовать ОП, до минимума сокращая фрагментацию. 125

Но в отличие от ВАП в виде набора отдельных виртуальных диапазонов адресов (000016 – FFFF 16) каждого сегмента при сегментной организации (рис. 5. 9), при сегментно-страничной организации все виртуальные сегменты образуют одно общее непрерывное линейное ВАП процесса в том же диапазоне (000016 – FFFF 16), показанное на рис. 5. 11. ВАП процесса FF…FF ВАП Сегмента 3 Сегмент 1 ВАП Сегмента 2 Сегмент 3 f 3 ВАП Сегмента 1 f 2 00… 00 f 1 Сегмент 2 Оперативная память Рис. 5. 11. Непрерывное линейное ВАП процесса при сегментно-страничной 126 организации памяти

Координаты байта в ВАП теоретически можно задать двумя способами: 1) линейным виртуальным адресом, который равен сдвигу данного байта относительно границы общего линейного ВАП; 2) парой чисел вида (номер сегмента, смещение от начала сегмента), а также указать начальный виртуальный адрес сегмента с данным номером, например, f 1, f 2, f 3 на рис. 5. 11. Системы виртуальной памяти ОС с сегментно-страничной организацией используют именно второй способ, как позволяющий непосредственно определить принадлежность адреса некоторому сегменту и проверить права доступа процесса к нему. Для каждого процесса ОС создает отдельную таблицу сегментов, содержащую описатели (дескрипторы) всех его сегментов. Описание сегмента включает те же элементы, что при сегментной организации, но имеет одно принципиальное отличие в поле базового адреса. Там указывается не начальный физический адрес сегмента при загрузке в ОП, а начальный линейный (то есть базовый) виртуальный адрес сегмента в ВАП процесса (на рис. 5. 11 базовые виртуальные адреса сегментов обозначены f 1, f 2, f 3). Это позволяет однозначно преобразовать адрес вида (номер сегмента, смещение в сегменте) в линейный виртуальный адрес байта, который затем преобразуется в физический адрес уже страничным механизмом. Деление общего линейного ВАП процесса и ОП на страницы осуществляется так же, как и при страничной организации памяти (размером по 2 k). 127

При порождении процесса в ОП загружается только часть страниц, остальные загружаются по мере необходимости. Время от времени ОС выгружает уже ненужные страницы, освобождая ОП для новых страниц. ОС ведет для каждого процесса таблицу страниц, где указывается соответствие виртуальных страниц физическим. Базовые адреса таблицы сегментов и таблицы страниц процесса являются частью его контекста. При порождении процесса эти адреса загружаются в специальные регистры процессора (известны!) и используются механизмом преобразования адресов. Преобразование виртуального адреса в физический происходит в два этапа, как показано на рис. 5. 12. 128

Исходный виртуальный адрес: Номер сегмента Таблица сегментов процесса Смещение в сегменте Базовый виртуальный адрес Дескриптор сегмента Первый этап + Номер виртуальной страницы Второй этап Линейный виртуальный адрес Смещение в странице Таблица страниц процесса Дескриптор страницы Искомый физический адрес: Номер физической страницы Смещение Рис. 5. 12. Преобразование виртуального адреса в физический при сегментностраничной организации памяти 129

Первый этап. Работает механизм сегментации (подобно рис. 5. 10). Исходный виртуальный адрес вида (номер сегмента, смещение) преобразуется в линейный виртуальный адрес. Для этого по базовому адресу таблицы сегментов и номеру сегмента из таблицы сегментов извлекается дескриптор этого сегмента. Производится анализ полей дескриптора. Если доступ к сегменту разрешен, то вычисляется линейный виртуальный адрес путем сложения базового виртуального адреса сегмента (из дескриптора) и смещения. Второй этап. Работает страничный механизм. Полученный линейный виртуальный адрес преобразуется в искомый физический адрес. Вначале выделяются его составляющие (номер виртуальной страницы, смещение в странице), понятные страничному механизму. Благодаря тому, что размер страницы равен 2 k, эта задача решается простым отделением младших k двоичных разрядов. При этом смещением является содержимое младших k разрядов, а номером виртуальной страницы – содержимое оставшихся старших разрядов. Далее преобразование адреса в физический происходит так же, как при страничной организации (подобно рис. 5. 6). Номер виртуальной страницы дает адрес дескриптора страницы в таблице страниц, по которому из дескриптора выбирается номер физической страницы. Последний операцией конкатенации присоединяется к смещению. Как видно, механизм сегментации и страничный механизм действуют достаточно независимо. Поэтому разработчики процессоров Intel 386, 486 и Pentium усовершенствовали только второй этап из двух рассмотренных на рис. 5. 12 этапов преобразования виртуального адреса в физический. 130

Модифицированный страничный механизм реализует двухуровневую схему, когда ВАП процесса делится сначала на разделы, а затем на страницы. Поэтому на втором этапе сначала вычленяются смещение, номер страницы и (дополнительно) номер раздела. Далее (подобно рис. 5. 7) по номеру раздела из таблицы разделов выбирается адрес таблицы страниц, из нее по номеру виртуальной страницы – номер физической страницы, к которому операцией конкатенации присоединяется смещение. Модифицированная схема второго этапа преобразования виртуального адреса в физический представлена на рис. 5. 13. Известна и такая модификация сегментно-страничного механизма (с соответствующими изменениями в организации памяти), когда в последней схеме (рис. 5. 13) в роли раздела выступает сегмент. Механизм упрощается, так как он, по сути, сводится к модифицированному второму этапу. 131

Линейный виртуальный адрес: Номер раздела - g Номер виртуальной страницы - p Смещение - s Таблица разделов : : g Таблица страниц раздела g p n Физический адрес: Номер физической страницы - n Смещение - s Рис. 5. 13. Модифицированная схема второго этапа сегментно-страничного механизма 132

5. 6. Разделяемые сегменты памяти Подсистема виртуальной памяти может обеспечивать и совместный доступ нескольких процессов к одному и тому же сегменту памяти, который в этом случае называется разделяемой памятью (shared memory). И хотя основной задачей ОС при управлении памятью является как раз защита областей ОП процесса от доступа к ней остальных процессов, в некоторых случаях бывает необходим именно контролируемый совместный доступ нескольких процессов к определенной области ОП. Пример 1. Несколько пользователей одновременно работают с Программой А. Целесообразно загрузить в ОП только одну копию (сегмент) ее реентерабельного кода, которая обслуживала бы всех пользователей. Только не следует забывать о том, что при этом для каждого пользователя Программы А должна быть организована своя копия сегмента данных (разных I/O-данных). Пример 2. Использование разделяемой области ОП как буфера при межпроцессном обмене данными, когда один процесс записывает в эту область, другой – читает из нее. Итак, разделяемый сегмент необходимо поместить в ВАП каждого работающего с ним процесса, после чего настроить параметры отображения этих виртуальных сегментов так, чтобы они соответствовали одной и той же области ОП. Детали такой настройки зависят от используемой в ОС модели виртуальной памяти, поддерживающей сегменты (сегментной или сегментно-страничной). Конечно, страничная организация не позволяет организовать разделяемые сегменты памяти. При сегментной организации надо в дескрипторах виртуального сегмента каждого процесса указать один и тот же базовый физический адрес. 133

При сегментно-страничной организации отображение на одну и ту же область ОП достигается соответствующей настройкой таблицы страниц каждого процесса. Но ВАП, как известно, имеет две части: индивидуальную и общую (рис. 5. 4). Поэтому рассматриваемая задача может иметь два решения: 1) как рассмотрено выше, поместить разделяемый сегмент в (верхнюю) индивидуальную часть ВАП каждого работающего с ним процесса (рис. 5. 14). Он описывается в каждом процессе индивидуальным дескриптором сегмента (или индивидуальными дескрипторами страниц – при сегментно-страничной организации); 1 2 N Индивидуальная часть ВАП каждого процесса Общая часть ВАП всех процессов Рис. 5. 14. Разделяемый сегмент в индивидуальной части ВАП каждого работающего с ним процесса 134

2) поместить единственный разделяемый сегмент в общую (нижнюю) часть ВАП всех процессов, обычно используемую для модулей ОС (рис. 5. 15). В этом случае настройка дескриптора сегмента (или дескрипторов страниц – при сегментно-страничной организации) выполняется только один раз, а все процессы ее используют. 1 2 N Общая часть ВАП всех процессов ВАП ОП Рис. 5. 15. Разделяемый сегмент в общей части ВАП всех процессов 135

Следует помнить и о том, при работе с разделяемыми сегментами памяти ОС должна выполнять еще и свои обычные функции поддержки связанных с ними разделяемых ресурсов (файлов, семафоров и т. п. ): 1) поддержка схемы именования ресурсов; 2) проверка прав доступа определенного процесса к ресурсу; 3) отслеживание числа процессов, пользующихся данным ресурсом, для его удаления при ненадобности. Итак, в общем случае дескриптор сегмента должен содержать специальное поле, имеющее два значения: shared (разделяемый) или private (индивидуальный). ОС может создавать разделяемые сегменты двумя способами: 1) по явному запросу. Прикладной процесс должен выполнить соответствующий системный вызов, по которому ОС создает новый разделяемый сегмент в соответствии с указанными в вызове параметрами (размер сегмента; разрешенные над ним операции чтение/запись), идентификатор). А все процессы, выполнившие подобные вызовы с одним и тем же идентификатором, получают доступ к этому сегменту и используют его по своему усмотрению; 2) по умолчанию. ОС в определенных ситуациях принимает решение о создании разделяемого сегмента сама. Например, это делается при поступлении нескольких запросов на выполнение одного и того же приложения. Если кодовый сегмент приложения помечен в исполняемом файле как реентерабельный и разделяемый, то при поступлении повторного запроса на выполнение данного приложения ОС не создает новую копию его кодового сегмента, а просто отображает соответствующую часть ВАП нового процесса в уже существующий разделяемый сегмент. 136

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

6. Управление устройствами ввода -вывода и файлами 138

6. 1. Задачи ОС по управлению УВВ и файлами Обеспечение обмена данными между работающими программами и УВВ компьютера – одна из главных задач ОС. В современных ОС эти функции выполняет подсистема ввода-вывода, клиентами которой являются не только пользователи и приложения, но и компоненты самой ОС при необходимости получения/вывода ими каких-то системных данных. Например, подсистеме управления процессами при смене активного процесса необходимо записать на диск контекст прерываемого процесса и считать с диска контекст активизируемого процесса. Состав подсистемы ввода-вывода. Основные компоненты подсистемы вводавывода: драйверы, управляющие УВВ, и ФС. Но к подсистеме ввода-вывода можно условно отнести и диспетчер прерываний, обслуживающий не только ее модули, но и другие модули ОС (планировщик/диспетчер потоков). А поскольку планирование работ именно подсистемы ввода-вывода составляет основную долю нагрузки диспетчера прерываний, его логично рассматривать условно как ее составную часть. ФС также рассматривается в составе подсистемы ввода-вывода, поскольку она активно использует остальные части подсистемы ввода-вывода, а сама файловая модель лежит в основе большинства механизмов доступа к устройствам. Задачи подсистемы ввода-вывода. При обмене данными с внешними устройствами компьютера подсистема ввода-вывода должна решать ряд сложных общих задач, наиболее важными из которых являются следующие 8 задач. 139

1. Организация параллельной работы УВВ и процессора. Каждое УВВ ВС снабжено специализированным блоком управления – контроллером, который взаимодействует с драйвером – системным программным модулем, предназначенным для управления данным устройством. Контроллер периодически принимает от драйвера выводимую на УВВ информацию, а также команды управления, определяющие, что с этой информацией надо сделать (например, вывести какие-то данные в определенную область экрана или записать в определенный сектор диска). Под управлением контроллера УВВ может некоторое время выполнять свои операции автономно, без участия центрального процессора и, следовательно, возможно, параллельно с ним. Это время зависит от объема выводимой информации, степени интеллектуальности управляющего устройства контроллера, быстродействия УВВ и других факторов. Причем независимо от своей сложности контролер после получения очередной команды от процессора обычно тратит достаточно много времени на самостоятельную реализацию своей функции, поскольку скорость работы любого УВВ обычно существенно ниже скорости работы процессора. Процессы, происходящие в контроллерах, протекают между выдачами команд драйверов уже независимо от ОС. А подсистема ввода-вывода должна спланировать в РВ запуск и приостановку большого числа разнообразных драйверов, обеспечив приемлемое время реакции каждого драйвера на независимые события контроллера. И необходимо минимизировать загрузку процессора задачами ввода-вывода, оставив максимум процессорного времени на выполнение пользовательских потоков. Данная задача является классической задачей планирования систем РВ и обычно решается на основе многоуровневой приоритетной схемы обслуживания по прерываниям. 140

Для обеспечения приемлемого времени реакции все драйверы (или их части) распределяются по нескольким приоритетным уровням. Для реализации такой приоритетной схемы обычно задействуется общий диспетчер прерываний ОС. 2. Согласование скоростей обмена и кэширование данных. При обмене данными (через ОП или в случае ввода-вывода) всегда возникает задача согласования скоростей работы отдельных блоков системы, поскольку скорости генерации данных и их чтения обычно не совпадают. Согласование скоростей обычно достигается за счет буферизации данных в ОП и синхронизации доступа процессов к буферу. Однако буферизация только на основе ОП в подсистеме ввода-вывода оказывается недостаточной, поскольку разница между скоростью обмена с ОП, куда процессы помещают данные для обработки, и скоростью работы УВВ часто становится слишком значительной. А объема ОП при этом может просто не хватать. Для таких случаев часто в качестве буфера используется дисковый файл (спулинга). Другим решением этой проблемы является использование большой буферной памяти в контроллерах УВВ. Это полезно, когда помещение данных на диск слишком замедляет обмен или когда данные выводятся на сам диск. Например, в контроллерах графических дисплеев применяется буферная память, по объему соизмеримая с ОП, что существенно ускоряет вывод графики на экран. При этом буферизация данных позволяет не только согласовать скорости работы процессора и УВВ, но и уменьшить число реальных операций ввода-вывода за счет кэширования данных. Дисковый кэш входит в состав подсистем ввода-вывода практически всех ОС, значительно сокращая время доступа к хранимым данным. 141 Лекция 13

3. Разделение УВВ и данных между процессами. УВВ могут предоставляться процессам в монопольное или совместное (общее, разделяемое) использование. При этом ОС должна обеспечивать контроль доступа к ним теми же способами, что и при доступе процессов к другим ресурсам ВС: путем проверки прав пользователя или группы, от имени которых действует процесс, на выполнение данной операции над УВВ. Например, определенной группе пользователей разрешено захватывать последовательный порт в монопольное владение, а другим пользователям это запрещено. Причем ОС может контролировать доступ не только к данному УВВ в целом, но и к отдельным порциям данных, хранимых или отображаемых этим устройством, например, к отдельным каталогам и файлам диска, окнам на экране дисплея и т. д. А для каждой порции данных или части устройства могут быть заданы еще и свои права доступа, не связанные прямо с правами доступа к этому устройству в целом. Известно, что одни УВВ могут работать как в монопольном режиме, так и в разделяемом, другие – только в одном из них. Значит ОС должна предоставлять УВВ в обоих режимах, отслеживая процедуры захвата/освобождения монопольно используемых устройств, а в случае совместного использования, оптимизируя последовательность операций ввода-вывода для различных процессов в целях повышения общей производительности, если это возможно. Например, при обмене данными нескольких процессов с диском можно упорядочить последовательность операций так, что непроизводительные затраты времени на перемещение головок существенно уменьшатся (минимизация «холостого хода» ), правда, с возможным 142 замедлением операции ввода-вывода для отдельных процессов.

При разделении УВВ между процессами может возникнуть необходимость в разграничении порций данных двух процессов друг от друга. Так бывает при совместном использовании устройств последовательного доступа, данные в которых не адресуются, в отличие от устройств прямого доступа. Например, это принтер, который не выделяется в монопольное владение процессам, но должен печатать каждый документ в виде последовательного набора страниц. Для подобных устройств организуется очередь заданий на вывод, причем каждое задание представляет собой порцию данных, которую нельзя разрывать (документ). Для хранения очереди заданий используется спул-файл, который одновременно согласует скорости работы принтера и ОП и позволяет организовать разбиение данных на логические порции. Поскольку спул-файл находится на разделяемом устройстве прямого доступа (диске), процессы могут одновременно выполнять вывод на принтер, помещая данные в свой раздел спул-файла. 4. Обеспечение удобного логического интерфейса между УВВ и остальной частью ОС. Разнообразие УВВ делает особенно актуальной функцию ОС по созданию экранирующего логического интерфейса между всеми УВВ и приложениями. Почти все ОС поддерживают в качестве его основы файловую модель, когда любое УВВ выглядит для прикладного программиста как последовательный набор байтов, с которым можно работать с помощью унифицированных системных вызовов (например, read и write), задавая только имя файла-устройства и смещение от начала последовательности байтов. Конечно, для поддержки такого удобного интерфейса подсистема ввода-вывода еще должна проделать немалую работу, учитывая разницу в 143 организации операций обмена данными, например, с HD и с графическим терминалом.

При этом файловая модель обычно используется как простая базовая основа, на которой подсистема ввода-вывода уже сама строит более содержательную модель УВВ какого-то конкретного типа. Подсистема ввода-вывода, как правило, предоставляет специфический интерфейс для вывода графической информации на дисплей или принтер, для программирования операций сетевого обмена и т. п. При этом разработчик специфического интерфейса всегда может опираться на имеющийся базовый интерфейс. 5. Поддержка широкого спектра драйверов и простота включения новых. Достоинством подсистемы ввода-вывода любой универсальной ОС является наличие разнообразного набора драйверов для наиболее популярных УВВ. Администраторы и пользователи не должны искать нужный драйвер, а тем более разрабатывать его. А чтобы ОС не испытывала недостатка в драйверах, необходимо наличие четкого, удобного и открытого интерфейса между драйверами и остальной частью ОС. Тогда, зная его, драйверы смогут писать не только разработчики ОС, но и разработчики УВВ, а также разработчики ПО. Драйвер взаимодействует, § с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, системных вызовов, подсистем управления процессами и памятью); § с другой стороны, с контроллерами УВВ. Поэтому существуют два типа интерфейсов: 1) интерфейс «драйвер-ядро» – он должен быть стандартизован в любом случае; 144

2) интерфейс «драйвер-устройство» – его имеет смысл стандартизовать, если подсистема ввода-вывода не разрешает драйверу непосредственно взаимодействовать с аппаратурой контроллера, а делает это самостоятельно. При этом экранирование драйвера от аппаратуры делает его независимым от аппаратной платформы. А подсистема ввода-вывода может поддерживать несколько различных видов интерфейсов «драйвер-ядро» / «драйвер-устройство» , предоставляя специфический интерфейс для УВВ какого-то определенного класса. Обычно подсистема ввода-вывода поддерживает большое число системных функций, которые драйвер может вызвать для выполнения некоторых типовых действий (например, операции обмена с регистрами контроллера, ведение буферов для промежуточного хранения данных ввода-вывода, синхронизация работы нескольких драйверов, копирование данных из пространства пользователя в пространство ОС). Для поддержки процесса разработки драйверов конкретной ОС обычно выпускается специальный пакет разработки (Driver Development Kit, DDK), представляющий набор инструментальных средств – библиотек, компиляторов и отладчиков. 6. Динамическая загрузка/выгрузка драйверов. Включение драйвера в состав модулей работающей ОС и его выключение «на ходу» является важным свойством ОС, поскольку набор потенциально поддерживаемых данной ОС УВВ всегда делается существенно больше набора реальных устройств, которыми ОС должна управлять при ее установке на конкретном компьютере. При этом актуальна возможность динамически загружать в ОП требуемый драйвер без останова ОС и так же выгружать ненужный драйвер для освобождения ОП. 145

Исторической альтернативой динамической загрузке/выгрузке драйверов является повторная компиляция кода ядра с требуемым набором драйверов, что создает между всеми компонентами ядра статические связи вместо динамических. Так решалась данная проблема в ранних версиях ОС UNIX, упрощая структуру системы, но при этом требовалось наличие исходных кодов модулей ОС. Кроме того, требовался останов ОС и замена ее старой конфигурации на новую. Поэтому поддержка динамической загрузки/выгрузки драйверов является практически обязательным требованием для современных универсальных ОС. 7. Поддержка нескольких ФС. Обычно большая часть системных и пользовательских данных хранится на дисках, делая дисковые накопители важнейшими УВВ. Данные на дисках организуются в различные ФС, а свойства отдельной ФС во многом определяют такие важнейшие свойства самой ОС, как отказоустойчивость, быстродействие, максимальный объем хранимых данных. Более того, популярность некоторой ФС часто приводит к ее миграции из «родной» ОС в другие ОС. Например, в свое время ФС «Таблица расположения файлов» (File Allocation Table, FAT) была создана для MS-DOS, но затем была реализована в OS/2, семействе MS Windows и многих реализациях UNIX. Именно поэтому поддержка нескольких популярных ФС для подсистемы ввода-вывода имеет принципиальное значение. При этом архитектура подсистемы ввода-вывода должна обеспечивать легкое включение в ее состав новых типов ФС без необходимости переписывания кода ОС. Обычно в ОС имеется специальный слой, отвечающий за решение этой задачи (см. далее рис. 6. 1), например, слой «виртуальная файловая система» (Virtual File System, VFS) в разных реализациях UNIX на основе System V Release 4. 146

8. Поддержка синхронных и асинхронных операций ввода-вывода. Операция ввода-вывода по отношению к запросившему ее программному модулю может выполняться, как и в случае ранее рассмотренных системных вызовов, синхронно (с приостановкой работы модуля и ожиданием ее завершения) или асинхронно (с продолжением работы модуля параллельно с операцией ввода-вывода). Причем, операция ввода-вывода может быть инициирована не только пользовательским процессом (когда она выполняется в рамках системного вызова), но и кодом ядра, например, подсистемы виртуальной памяти для считывания отсутствующей в ОП страницы. Значит подсистема ввода-вывода должна предоставлять своим клиентам (пользовательским процессам, кодам ядра) возможность выполнять по требованию как синхронные, так и асинхронные операции ввода-вывода. Системные вызовы ввода-вывода чаще выполняются как синхронные, поскольку такие операции длятся сравнительно долго, и пользовательскому процессу/потоку все равно необходимо ожидать их результаты для продолжения своей работы. Внутренние же вызовы операций ввода-вывода из модулей ядра обычно выполняются как асинхронные, поскольку ядру нужна свобода в выборе дальнейшего поведения после запроса операции ввода-вывода. Асинхронный вариант в принципе дает более гибкое решение, позволяя всегда добавить (если надо) промежуточную синхронную процедуру, блокирующую выполнение асинхронной до завершения ввода-вывода. Иногда и прикладному процессу требуется выполнить асинхронную операцию ввода-вывода, как в случае архитектуры на основе микроядра, когда полная свобода действий после вызова операции ввода-вывода нужна модулю ОС (например, какому-то серверу), 147 работающему в пользовательском режиме.

6. 2. Многослойная модель подсистемы ввода-вывода Общая схема. Идея многослойной организации ОС, рассмотренная в подразделе 3. 3 оказывается полезной и при построении подсистемы ввода-вывода. При большом разнообразии УВВ, обладающих существенно разными характеристиками, ее иерархическая структура позволяет соблюсти баланс между двумя противоречивыми требованиями, когда необходимо 1) учесть все особенности каждого оригинального или даже уникального УВВ; 2) обеспечить единое логическое представление и унифицированный интерфейс для УВВ всех известных типов. При этом нижние слои подсистемы ввода-вывода должны включать индивидуальные драйверы, написанные для каких-то конкретных физических устройств, а верхние слои должны обобщать процедуры управления этими устройствами, представляя общий интерфейс для всех устройств или для отдельных групп устройств, обладающих некоторыми общими характеристиками, например, для лазерных принтеров компании Hewlett Packard. Подобная многослойная структура облегчает решение большинства рассмотренных задач подсистемы ввода-вывода, например, таких как включение новых драйверов (5), динамическая загрузка/выгрузка драйверов (6), поддержка нескольких ФС (7) и других. Обобщенная двумерная структура подсистемы ввода-вывода представлена на рис. 6. 1. Здесь ПО ввода-вывода делится не только на горизонтальные слои, но и на вертикальные. 148

Прикладной программный интерфейс Системные вызовы ввода-вывода Блок-ориентированный интерфейс Байт-ориентированный интерфейс VFS Диспетчер окон Высокоуровневые драйверы (файловых систем) (графические) Менеджер вводавывода UFS NTFS FAT Дисковый кэш Низкоуровневые драйверы (дисководов) (графические) Драйвер HD Драйвер FD Драйвер принтера Драйвер плоттера Диспетчер прерываний, функции доступа к аппаратуре Контроллеры УВВ → Различные УВВ → HD FD Группа дисковых УВВ Принтер Плоттер Группа графических УВВ Рис. 6. 1. Обобщенная структура подсистемы ввода-вывода 149

Необходимость вертикальных слоев обусловлена наличием целого ряда групп разнотипных УВВ со своими способами управления. Отметим, что на рис. 6. 1 представлены не все такие группы, например, не представлена группа сетевых УВВ. Здесь общий принцип многослойности соблюдается, но для образованных групп разнотипных УВВ он реализуется по-разному, со своим числом слоев и их функциями. В группу графических УВВ могут входить также мониторы, диджитайзеры и т. п. , а в группу сетевых – сетевые адаптеры. В каждой вертикальной подсистеме существует несколько слоев модулей. Нижний слой образуют аппаратные драйверы устройств, осуществляющие обмен байтами или блоками байтов. Как правило, они не имеют дела с высокоуровневой логической организацией данных (например, с файлами или какими-то сложными графическими объектами). Функции вышележащих слоев в значительной степени зависят от типа вертикальной подсистемы. Менеджер ввода-вывода. В подсистеме ввода-вывода наряду с модулями, отражающими специфику разных групп УВВ и образующими вертикальные подсистемы, существуют и модули универсального назначения. Они организуют согласованную работу всех остальных компонентов подсистемы, а также взаимодействие с пользовательскими процессами и другими подсистемами ОС. Как и функции управления УВВ, эти организующие функции распределены по всем уровням, образуя оболочку под названием менеджер ввода-вывода. Задачи такого менеджера довольно разнообразны. Рассмотрим их подробнее. (1 час) 150

1. Верхний слой менеджера составляют системные вызовы ввода-вывода, принимающие от пользовательских процессов запросы на ввод-вывод и переадресующие их отвечающим за какую-то определенную группу УВВ модулям и драйверам, а также возвращающие процессам результаты соответствующих операций ввода-вывода. Таким образом, верхний слой поддерживает пользовательский интерфейс ввода-вывода, создавая для прикладных программистов максимум удобств по манипулированию УВВ и расположенными на них данными. 2. Нижний слой менеджера реализует непосредственное взаимодействие драйверов с контроллерами УВВ, экранируя драйверы от особенностей аппаратной платформы компьютера (и, в частности, шины ввода-вывода, системы прерываний и т. п. ). Этот слой принимает от драйверов запросы на обмен данными с регистрами контроллеров в некоторой обобщенной форме (с независимой от шины адресацией и форматом), а затем преобразуют эти запросы уже в зависящий от аппаратной платформы формат. Кстати, диспетчер прерываний, в принципе, может входить в состав менеджера вводавывода или быть отдельным модулем ядра ОС. В последнем случае менеджер вводавывода выполняет для диспетчера прерываний первичную обработку запросов прерываний, передавая ему сведения об источнике запроса прерывания. 3. Важная функция менеджера ввода-вывода – создание некоторой среды для остальных компонентов подсистемы, облегчающей их взаимодействие друг с другом за счет использования стандартного внутреннего межмодульного интерфейса. Его наличие облегчает включение новых драйверов и ФС в состав ОС. Кроме того, разработчики драйверов освобождаются от написания общих процедур, таких как 151 буферизация данных или синхронизация нескольких модулей при обмене данными.

Все эти функции берет на себя менеджер ввода-вывода. 4. Еще одна функция менеджера – организация внешнего взаимодействия с модулями других подсистем ОС, таких как подсистема управления процессами, подсистема управления виртуальной памятью и другие. Наличие стандартного внутреннего межмодульного интерфейса повышает устойчивость и улучшает расширяемость подсистемы ввода-вывода, но может и несколько замедлять ее работу за счет взаимодействия слоев (по сравнению с монолитной организацией с прямыми передачами управления). Многоуровневые драйверы. Изначально термин «драйвер» применялся в достаточно узком смысле для обозначения программного модуля, который 1) входит в состав ядра ОС, работая в привилегированном режиме; 2) непосредственно управляет конкретным УВВ, взаимодействуя с его контроллером с помощью команд ввода-вывода компьютера; 3) обрабатывает прерывания от контроллера УВВ; 4) предоставляет прикладному программисту удобный логический интерфейс для работы с данным УВВ, экранируя от него низкоуровневые детали управления УВВ и организации его данных; 5) взаимодействует с другими модулями ядра ОС с помощью строго оговоренного интерфейса, описывающего формат передаваемых данных, структуру буферов, способы включения драйвера в состав ОС, способы вызова драйвера, набор общих процедур ввода-вывода, которыми драйвер может пользоваться и т. п. 152

Согласно этому определению, уже тогда драйвер + контроллер устройства + прикладная программа воплощали идею многослойной организации ПО. Контроллер обеспечивал нижний слой управления, а драйвер выполнял более сложные операции, преобразуя данные, адресуемые, например, в терминах номеров цилиндров, головок и секторов диска, в линейную последовательность блоков. В результате прикладная программа работала уже с достаточно понятными для человека данными (файлами, таблицами, текстовыми окнами на мониторе), не вдаваясь в детали представления этих данных в УВВ. Те первые драйверы не делились на слои, но часто выполняли задачи разного уровня сложности, в зависимости от сложности конкретного УВВ или алгоритма его функционирования. Постепенно, по мере развития ОС и усложнения структуры подсистемы вводавывода, наряду с традиционными драйверами в ней появились так называемые высокоуровневые драйверы, которые располагаются (на рис. 6. 1) над традиционными драйверами. А традиционные драйверы получили названия: аппаратные драйверы, низкоуровневые или драйверы устройств. Низкоуровневые операции составляют тот фундамент, на котором можно построить целый набор операций в драйверах более высоких уровней. Так повышается гибкость и расширяемость функций управления УВВ, когда вместо жесткого набора функций, сосредоточенного в единственном драйвере, администратор ОС теперь может выбрать требуемый набор функций, установив нужный высокоуровневый драйвер или даже несколько, работающих над одним аппаратным драйвером. 153

Число уровней драйверов в подсистеме ввода-вывода обычно не ограничивается, но на практике чаще всего используют 2 -5 уровней драйверов. При этом несколько драйверов, управляющих одним УВВ на разных уровнях, можно рассматривать как набор или как один многоуровневый драйвер. Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и (низкоуровневые) аппаратные драйверы. Единственным отличием является то, что высокоуровневые драйверы, как правило, не вызываются по прерываниям, поскольку взаимодействуют с управляемым устройством через аппаратные драйверы. Менеджер ввода-вывода управляет всеми драйверами однотипно. Отметим, что в схеме рис. 6. 1 не показаны все возможные вертикальные слои УВВ, а также допустимые исключения, которые могут быть связаны с ориентацией высокоуровневого интерфейса не только на блоки или байты. Например, таймер как устройство вывода не содержит адресуемой информации, не порождает потока байтов, а только выдает сигнал прерывания в некоторые характерные моменты времени. 154

6. 3. Логическая организация файловой системы 1. Состав и назначение ФС. ФС – это часть ОС, включающая: 1) совокупность всех файлов на диске или другом носителе для компьютера; 2) наборы правил, конструкций и структур данных, используемые для хранения файлов и управления ими (каталоги файлов, дескрипторы файлов, таблицы распределения занятого и свободного пространства на диске). Эти наборы определяют конкретный тип ФС; 3) комплекс системных программных средств, реализующих различные операции над файлами (создание, удаление, чтение, запись, именование, поиск и другие). Например, ФС для ОС семейства UNIX представляет совокупность всех файлов в разделе диска (либо на устройстве) или логическую единицу монтирования (командой mount в отдельный каталог дерева каталогов). ФС позволяет программам обходиться набором достаточно простых операций для выполнения действий над некоторым абстрактным объектом, представляющим файл. При этом программистам не нужно иметь дела с деталями действительного расположения данных на диске и другими низкоуровневыми проблемами ввода-вывода (за решение которых отвечает подсистема ввода-вывода). ФС распределяет дисковую память, поддерживает именование файлов, отображает их имена в соответствующие адреса во внешней памяти, обеспечивает доступ к данным, поддерживает разделение (совместное использование), защиту и восстановление файлов. 155

Таким образом, ФС играет роль промежуточного слоя, экранирующего все сложности физической организации долговременного хранилища данных и создающего для программ более простую модель этого хранилища, а также предоставляя им набор удобных команд для манипулирования файлами. 2. Задачи ФС разных классов ОС. Задачи, решаемые ФС, зависят от способа организации вычислительного процесса в ОС. Рассмотрим 4 класса ОС. 1. Функции наиболее простых ФС в однопользовательских однопрограммных ОС (MS-DOS) нацелены на решение следующих задач: § именование файлов; § программный интерфейс для приложений; § отображение логической модели ФС на физическую организацию хранилища данных; § устойчивость ФС к сбоям питания, ошибкам аппаратных и программных средств. 2. В однопользовательских мультипрограммных ОС задачи ФС усложняются, поскольку к упомянутым задачам добавляется задача поддержки совместного доступа к файлу из нескольких процессов. В частности, в ФС должны быть средства блокировки файла или его частей, предотвращения гонок, исключение тупиков, согласование копий и т. п. 3. В ФС многопользовательских ОС появляется еще и задача защиты файлов от несанкционированного доступа. 4. Наиболее сложными становятся функции ФС сетевых ОС. 156

3. Типы файлов. ФС поддерживают 5 функционально различных типов файлов: 1) обычные файлы (просто файлы) – содержат информацию произвольного характера, которую заносит в них пользователь или которая образуется в результате выполнения системных или пользовательских программ. ОС обычно не ограничивает и не контролирует содержимое и структуру обычного файла, поскольку они определяются самим работающим с файлом приложением. Все ОС должны уметь распознавать хотя бы один тип файлов – их собственные исполняемые файлы; 2) файлы-каталоги – содержат системную справочную информацию о наборе файлов, сгруппированных пользователем или ОС по какому-либо признаку. Во многих ОС в каталоги могут входить другие каталоги, за счет чего и образуется древовидная структура каталогов, удобная для поиска. Каталоги устанавливают соответствие между именами файлов и их характеристиками (тип, расположение на диске, права доступа, даты создания и модификации), используемыми ОС для управления ими; 3) специальные файлы – это фиктивные файлы, ассоциированные с УВВ, используемые для унификации механизма доступа к файлам и внешним устройствам. Они позволяют пользователю выполнять операции ввода-вывода с помощью обычных команд работы с файлами. Эти команды обрабатываются сначала программами ФС, а затем на некотором этапе выполнения запроса преобразуются ОС в команды управления соответствующим УВВ; 157

4) именованные конвейеры. Конвейеры как средство межпроцессного обмена впервые появились в ОС UNIX. Конвейер (pipe) – буфер в ОП, поддерживающий очередь байтов по дисциплине FIFO. Для программиста, использующего системный вызов pipe, этот буфер выглядит как безымянный файл для записи-чтения. Но использовать данный конвейер могут только родственные процессы, имеющие общего родителя, создавшего этот конвейер. Появившиеся в результате развития этого механизма именованные конвейеры имеют имя, которое является записью в каталоге ФС. Поэтому они пригодны для обмена данными уже между двумя произвольными процессами или потоками этих процессов; 5) отображаемые в память файлы. Отображение файла в ВАП процесса применяется для упрощения программирования, позволяет работать с данными файла с помощью адресных указателей как с обычными переменными программы, без использования нескольких громоздких файловых функций read/write (и явного описания необходимой области файла). При отображении файлов в память широко используется механизм виртуальной памяти и другие. Лекция 14 4. Иерархическая структура ФС. Пользователи обращаются к файлам по их именам, но с увеличением числа файлов в линейной (одноуровневой) структуре поиск файлов становится затруднительным. Иерархическая организация пространства имен позволяет облегчить эту работу за счет распределения файлов по группам (каталогам). Образуется несколько уровней каталогов, где каталог нижележащего уровня может входить в каталог вышележащего уровня. При этом 158 граф, описывающий иерархию каталогов, может представлять собой:

§ дерево, если файл может входить только в один каталог; § сеть (с петлями/циклами), если файл может одновременно входить в несколько каталогов. При иерархической организации пользователю при поиске файла достаточно помнить только принадлежность его к определенному каталогу или нескольким похожим по смыслу. 5. Имена файлов. Все типы файлов имеют различные по назначению символьные имена: 1) простые (короткие), идентифицирующие файл в пределах каталога; 2) составные (полные) – длинные, идентифицирующие файл в пределах всего дерева каталогов; 3) относительные, идентифицирующие файл в пределах «текущего» каталога. 6. Монтирование. В общем случае ВС может иметь несколько дисковых устройств. Более того, одно физическое дисковое устройство средствами ОС может быть представлено в виде нескольких логических устройств путем разбиения общего дискового пространства на разделы (лог. диски). Все это усложняет организацию хранения файлов в системе, имеющей несколько устройств внешней памяти. Возможны 2 варианта реализации структур и именования файлов. 1. На каждом устройстве файлы размещаются иерархически автономно, с собственным деревом каталогов. Тогда для однозначной идентификации файла пользователь должен перед составным символьным именем указывать идентификатор логического устройства (С: primer1100file 17. doc). 159

2. Пользователю представляется возможность самому объединять разрозненные иерархии файлов на различных устройствах (и описывающие их деревья каталогов) в одну иерархию и единое дерево каталогов операцией монтирования. Среди всех логических дисковых устройств ОС выделяет одно устройство, называемое системным. Система файлов на нем назначается корневой. На ее дереве каталогов выбирается удобное место – каталог монтирования, который назначается корневым каталогом другого подключаемого дерева. Через этот каталог монтируемое дерево становится поддеревом единого дерева каталогов. После монтирования общей ФС для пользователя уже нет логической разницы между корневой и смонтированной ФС, а именование файла производится без указания идентификатора логического устройства. 7. Логическая организация файла. В общем случае данные в файле имеют некую логическую структуру. За поддержку логической структуры файла может отвечать: § приложение, а файл представляется ФС неструктурированной последовательностью байтов, его истинный формат известен только заинтересованному приложению; § ФС, которая видит уже структурированный файл как упорядоченную последовательность логических записей. При этом ФС может использовать 2 способа доступа к логическим записям: 1) последовательный – прохождение и поиск с начала; 2) прямой – доступ сразу по номеру записи. Конечно, ОС не может поддерживать все возможные способы структурирования данных в файле (!). Поэтому в тех ОС, где такая поддержка вообще есть, она существует лишь для небольшого числа широко распространенных схем логической 160 организации файла. Каких схем?

Это записи: 1) фиксированной длины; 2) переменной длины неиндексированные; 3) переменной длины индексированные. К записям фиксированной длины может быть организован последовательный доступ или прямой доступ по номеру записи. Файлы с записям переменной длины, доступ к которым осуществляется последовательно, называются неиндексированными (или последовательными). При необходимости прямого доступа к записям переменной длины создают индексированные файлы, где записи имеют одно или несколько ключевых (индексных) полей и могут адресоваться значениями этих полей. Все сказанное относится преимущественно к обычным файлам. Другие типы файлов (например, файлы-каталоги) обладают определенной структурой, известной соответствующей ФС. 6. 4. Физическая организация файловой системы Представление пользователя о ФС как об иерархически организованном множестве информационных объектов имеет мало общего с реальным порядком хранения файлов на диске. Файл, имеющий образ цельного, непрерывающегося набора байтов, на самом деле очень часто разбросан «кусочками» по всему диску, причем это разбиение никак не связано с его логической структурой. Принципы размещения файлов, каталогов и системной информации на реальном устройстве описываются физической организацией ФС. Очевидно, что разные ФС имеют разную физическую организацию. 161

Диски, разделы, секторы, кластеры. Дисковые накопители являются основным типом устройств хранения файлов в современных ВС. Жесткий диск состоит из одной или нескольких (пакета) стеклянных или металлических пластин, покрытых с одной или двух сторон магнитным материалом. На каждой стороне пластины размечены тонкие концентрические кольца – дорожки (tracks), на которых хранятся данные. Совокупность всех дорожек одного радиуса на всех поверхностях всех пластин пакета называется цилиндром (cylinder). Каждая дорожка разбивается на фрагменты – секторы (sectors) или блоки (blocks). Все дорожки имеют равное число секторов, куда можно записать равное число байтов. Сектор имеет фиксированный для конкретной системы размер, равный 2 k (обычно 512 байтов). Сектор – наименьшая адресуемая единица обмена данными дискового устройства с ОП. Чтобы контроллер смог найти на диске нужный сектор, необходимо задать ему все составляющие адреса (цилиндр, поверхность, сектор). А так как программе в общем случае нужны не секторы, а байты, то происходит считывание лишней информации. Поэтому ОС при работе с диском обычно использует собственную единицу дискового пространства – кластер (cluster). При создании файла место на диске ему выделяется кластерами фиксированного размера. Размер кластера составляет 2 n. Дорожки и секторы создаются в результате выполнения процедуры низкоуровневого (физического) форматирования диска, предшествующей его использованию. Для определения границ блоков на диск записывается идентификационная информация. Низкоуровневый формат диска не зависит от типа ОС, которая этот диск будет использовать. 162

А разметку диска под конкретный тип ФС выполняют процедуры высокоуровневого (логического) форматирования диска. При этом определяется размер кластера, на диск записывается информация, необходимая для работы ФС, в том числе информация о доступном и неиспользованном пространстве, границах областей, отведенных под файлы и каталоги, информация о поврежденных областях. Кроме того, на диск записывается загрузчик ОС – небольшая программа, начинающая процесс инициализации ОС после включения или рестарта компьютера. Но прежде, чем форматировать диск под определенную ФС, он может быть разбит на разделы. Раздел – это непрерывная часть физического диска, которую ОС представляет пользователю как логическое устройство (лог. диск, логический раздел). ОС разного типа используют единое для всех представление о разделах, но создают на его основе логические устройства, специфические для каждого типа ОС. Так же как ФС, с которой работает одна ОС, в общем случае не может интерпретироваться ОС другого типа, логические устройства не могут быть использованы ОС разного типа. На каждом логическом устройстве может быть создана только одна ФС. На разных логических устройствах одного физического диска могут располагаться ФС разного типа. Все разделы одного диска имеют одинаковый размер блока, определенный для данного диска в результате низкоуровневого форматирования. Однако в результате высокоуровневого форматирования в разных разделах одного и того же диска, представленных разными логическими устройствами, могут быть установлены ФС с кластерами своих (различающихся) размеров. 163

ОС может поддерживать разные статусы разделов, особым образом отмечая разделы, которые могут быть использованы для загрузки модулей ОС, и разделы, где можно устанавливать только приложения и хранить файлы данных. Один из разделов диска помечается как загружаемый (активный). Именно из этого раздела считывается загрузчик ОС. Физическая организация и адресация файла. Важным компонентом физической организации ФС является физическая организация файла – способ размещения файла на диске. Основными критериями эффективности физической организации файлов являются: 1) скорость доступа к данным; 2) объем адресной информации файла; 3) степень фрагментированности дискового пространства; 4) максимально возможный размер файла. Непрерывное размещение – простейший вариант физической организации, когда файлу предоставляется последовательность смежных кластеров. Его достоинства: высокая скорость доступа, минимум объема адресной информации, отсутствие ограничения максимального размера файла. Недостатки: сложность поддержки увеличения размера файла, подверженность фрагментации. Поэтому на практике используются еще и 3 метода размещения файла в несмежных областях диска: 1) в виде связанного списка кластеров, когда в начале каждого кластера содержится указатель на следующий кластер. 164

Достоинства: адресная информация минимальна (адрес первого кластера файла); удобство увеличения размера файла; отсутствие фрагментации. Недостатки: 1 – последовательный доступ; 2 – из-за того, что одно слово израсходовано на номер следующего кластера, объем данных кластера уже не равен 2 k, а многие программы читают данные именно кластерами размера 2 k; 2) с использованием связанного списка индексов. Это модификация предыдущего метода, когда номер первого кластера запоминается в записи каталога, где хранятся характеристики этого файла. Остальная адресная информация отделена от кластеров файла. С каждым кластером диска связывается некоторый элемент – индекс. Индексы располагаются в отдельной области диска. Например, FAT, занимающая один кластер. Когда память свободна, все индексы имеют нулевое значение. Если некоторый кластер N назначен некоторому файлу, то индекс этого кластера становится равным либо номеру M следующего кластера данного файла, либо принимает специальное значение – признак последнего кластера файла. А индекс предыдущего кластера файла принимает значение N, указывая на вновь назначенный кластер; 3) простое перечисление номеров кластеров файла. Этот перечень и служит адресом файла. Недостаток: длина адреса зависит от размера файла. Достоинства: высокая скорость доступа к любому кластеру ввиду прямой адресации, отсутствие фрагментации. Чтобы корректно принимать решение о выделении файлу набора кластеров, ФС должна отслеживать информацию о состоянии всех кластеров диска (свободен/занят). Эта информация может храниться как отдельно от адресной информации файлов, так и 165 вместе с ней. ///

ЗАКЛЮЧЕНИЕ 1. Сегодня ситуация в мире ОС может быть охарактеризована, как наступление некоторой общей стабилизации и среди основных групп пользователей, и среди компаний-разработчиков ОС различных классов и групп. Стабилизации потому, что производители компьютеров (в первую очередь, процессоров, памяти и периферийных устройств) своими разработками создали весомый запас компьютерных и информационных ресурсов для полновесной поддержки всех функций ОС и различных режимов работы вычислительных комплексов. 2. Современные проблемы развития ОС (в рамках 32 -/64 -разрядных архитектур) имеют главным образом внешний характер по отношению к архитектуре, организации и внутреннему устройству ОС и связаны с проблемами поддержки новых и перспективных (не входящих в число необходимых базовых) функций, таких как поддержка новых и перспективных информационных технологий (сетевых – ЛС и ГС, сервисов, разнообразных служб; мультимедиа, гипермедиа и т. п. ). Эти вопросы и станут предметом нашего изучения в последующих дисциплинах «Компьютерные сети» , «Мультимедиа технологии» (4 семестр) и других. А упомянутые внутренние проблемы ОС сегодня уже перенесены на 64 -разрядные архитектуры. 3. Конечный пользователь сегодня при наличии современных аппаратных ресурсов практически не испытывает никаких проблем на уровне использования конкретной ОС и особенно ее ГИП. Пожалуй, единственной серьезной проблемой всегда остается проблема эффективной защиты данных, ОС и приложений от вирусов и внешних 166 атак в сетевой среде.

4. Вызывает сожаление лишь то, что зачастую остается практически невостребованным большинством пользователей весь мощный арсенал средств, заложенных разработчиками ОС, для повышения эффективности организации вычислительных процессов в среде конкретной системы. К ним относятся: настройка и оптимизация многозадачных режимов, поддержки потоков, механизмов приоритетов, виртуальной памяти, ее элементов и структур, ППС, виртуальных машин, новых механизмов виртуализации и гипервизоров, не говоря уже о механизмах поддержки различных ФС, драйверов, использовании разнообразных утилит и т. п. 5. Далеко не все пользователи эффективно используют яркие возможности ГИП ОС, такие как поддержка многооконного интерфейса, буферов временного хранения или средств передачи данных между приложениями, пакетные файлы и сценарии, средства резервного копирования и восстановления. 6. С другой стороны, рынок ОС тоже стабилизировался, окончательно выявился лидер – вызывающая раздражение у многих своей экспансией корпорация Microsoft (и ее компаньоны) и их многочисленные оппоненты (получается «Microsoft против почти всех» ). Парадоксально то, что ОС семейства Windows и ПС от Microsoft недолюбливают многие, но в своей повседневной работе почему-то используют практически все пользователи ПК на платформе Intel. ОС семейства Windows практически доступны всем и «захватили мир» , благодаря самым низким требованиям со стороны ОС к уровню пользователя. Основным противником Microsoft по качеству ГИП и удобству поддержки мультимедиа и других перспективных информационных технологий является компания Apple с ее семействами ПК и ОС mac. OS. 167

7. Для программистов тоже есть свой непререкаемый авторитет – семейство UNIX, сегодня интенсивно подпитываемое разработчиками различных вариантов Linux для ПК и Solaris для мощных серверов, рабочих станций и терминалов Sun. Ray от Oracle (ранее Sun Microsystems). 8. Есть еще небольшая группа – экспериментальные ОС: Next, ОС РВ Be. OS, QNX и другие, где каждая ОС живет своей обособленной жизнью, а также Live-OS и перспективные облачные Web-OS. Накопленный опыт изучения и практического освоения различных ОС позволяет сделать некоторые выводы о перспективах их развития и конкуренции. 1. При наличии серьезных аппаратных средств и ресурсов необходимо решать задачу выбора 32/64 -разрядной ОС из числа популярных. Это выбор альтернативы среди таких, например, как: надежность и безопасность (семейство UNIX, Linux, Solaris); простота и удобство установки и работы (семейство MS Windows); качество, компактность и эффективность средств, цельность и завершенность (что было в OS/2), качество ГИП (mac. OS). 2. В областях профессиональной деятельности пользователей ОС конкурируют с переменным успехом. Но есть и стереотипы: мощные САПР и серверы – UNIX, Solaris; обучение – Mac. OS; офис, серверы – MS Windows и т. д. 3. Но остается еще и постоянное поле конкуренции ОС – сети и телекоммуникации. Причем, это уже только конкуренция универсальных ОС, поскольку время их конкуренции со специализированными сетевыми ОС (семейства Novel Net. Ware 168 5. */6. * и другими) прошло.

4. Новый виток конкуренции уже перенесен в область 64 -разрядных компьютеров и 64 -разрядных ОС. Такие компьютеры, например, от компаний Hewlett Packard (HP) (HP 9000), IBM (RS 6000) и соответствующие ОС (HP-UX и AIX) одними из первых появились в самом начале 21 века. После них недавно появились массовые 64 разрядные ПК на платформе Intel и других, а также долгожданная 64 -разрядная ОС MS Windows Vista, после которой появились и W 7/W 8/W 10. 5. Перенос приложений на другие процессоры стал гораздо легче (с ростом производительности все меньше требуется Ассемблер, хватает и языка высокого уровня), а перенос на другие ОС – гораздо сложнее (сильнее привязка, используются обширные наборы функций API конкретных, часто по-разному организованных ОС). 6. Мечтой многих пользователей ПК всегда была единая вычислительная платформа, которая могла бы обеспечить: 1) плавное, долговременное развитие аппаратуры, ПО, развитие и наращивание знаний пользователя без постоянного переучивания; 2) создание полностью переносимых приложений (на псевдокоде); 3) простое использование приложений в режиме клиент-сервер (когда приложение запускается на сервере приложений, а используется на ПК клиента); 4) эмуляцию одних (искомых, требуемых) аппаратно-программных платформ на других (реально используемых). Долгое время на ее роль среди ОС претендовала Windows NT/2000. Но все же эту идею пока реализовать не удалось в связи с незыблемостью позиций названных ранее популярных ОС в отдельных секторах применения. 169

7. Тем не менее, корпорация Microsoft сделала упреждающий шаг на другом поле, создав единую универсальную интегрированную среду разработки приложений. NET, обладающую отмеченными свойствами. Ее развитие осуществляется в рамках инструментальной программной среды поддержки разработок Visual_Studio. NET (поддерживает C#, Vbasic. NET, Perl, расширенный язык разметки (e. Xtended Markup Language, XML), и другие популярные современные и перспективные языки). Имеется и ответ UNIX-сообщества – подобная и не менее эффективная среда GNU. NET. 8. Корпорация Sun Microsystems (сегодня уже в составе поглотившей ее компании Oracle) постоянно вносит в развитие ОС свою лепту, развивая Java-технологии программирования и универсальные интегрированные среды разработки клиентских и серверных приложений, а также приложений для мобильных уcтройств, свою сетевую ОС Solaris 10 и 11, а также открыв код Solaris 10. Но все эти разработки также очень далеки от единой вычислительной платформы. 9. Современные ОС постепенно захватывают все новые классы аппаратуры, например, планшеты и смартфоны. 10. Графический интерфейс пользователя продолжает стремительно развиваться уже на пути совершенствования сенсорных touch-интерфейсов и новых средств представления постоянно развивающегося функционала и растущих ресурсов. 170

Уже говорилось, что сегодня многие пользователи и даже некоторые разработчики ПО, к сожалению, не используют возможности современных ОС в полной мере, игнорируя реализованные для них эффективные средства поддержки многозадачных режимов, РВ, виртуальной памяти, виртуализации на уровне устройств и ОС в целом, многооконного ГИП, ППС и гипервизоров и другие. Поэтому знание принципов организации и функционирования подобных средств и механизмов, а также основ построения и функционирования ОС и их подсистем дает каждому пользователю значительный потенциал для повышения эффективности будущих разработок и использования компьютеров, аппаратнопрограммных комплексов и систем различного назначения (в том числе систем защиты информации, ВС и информационных систем различного назначения, образовательных систем и комплексов). Спасибо за внимание ! Контрольная работа 2 Списки дополнительной литературы по всем аспектам истории и организации, построения и реализации, использования и развития ОС, полезные для более глубокого изучения, реализации заданий СРС под руководством преподавателя или заданий лабораторного практикума, приведены в учебном пособии. Экзамен 171

поток лекция 30. 17 Лекц-8 06. 11. 17 13. 11. 17 Начало конец всего 1 28 28 Лекц-9 29 56 27 20. 11. 17 Лекц-10 57 84 27 27. 11. 17 Лекц-11 85 113 28 04. 12. 17 Лекц-12 114 141 27 11. 12. 17 Лекц-13 142 158 16 18. 12. 17 Лекц-14 158 171 13 25. 12. 17 - Контрольная 2 № занятия 1 2 № модуля 1 3 4 5 6 2 Тема Установка и настройка ОС MS Windows Возможности и средства ОС MS Windows Средства сохранения и восстановления программной среды ОС MS Windows Установка и настройка выбранной (альтернативной) ОС (UNIX, Linux, Mac. OS, Be. OS, QNX или иной) Возможности и средства выбранной (альтернативной) ОС Освоение перспективных типов ОС (on-line ОС, Web-ОС) Кол-во часов 6 часов 8 часов 4 часа 172