Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Операционные системы - файл 1.doc


Операционные системы
скачать (277.5 kb.)

Доступные файлы (1):

1.doc278kb.20.12.2011 12:09скачать

содержание
Загрузка...

1.doc

Реклама MarketGid:
Загрузка...
Министерство образования Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

«Тихоокеанский государственный университет»

Кафедра «Экономической кибернетики»
Контрольная работа

по предмету:

«Операционные системы»




Выполнил:

студентка 1-го курса з/о

Специальность

ПИЭ (зу)

№ з.к.

060430134

ФИО

Софронова О.С.







Проверил:












Хабаровск 2009

Содержание


Содержание 2

1. Операционная система UNIX (UNIX operating system) 2

1.1. История создания и основание операционной системы UNIX 3

1.2. Некоторые архитектурные особенности 4

2. Прикладная среда (Application environment) 8

3. Ядро операционной системы (Kernel) 13

3.1. Основные функция ядра 14

3.2. Типы архитектур ядер операционных систем 15

4. Диспетчер 23



^

1. Операционная система UNIX (UNIX operating system)


UNIX – группа переносимых, многозадачных и многопользовательских операционных систем.

Некоторые отличительные признаки UNIX-систем включают в себя:

  • использование простых текстовых файлов для настройки и управления системой;

  • широкое применение утилит, запускаемых в командной строке;

  • взаимодействие с пользователем посредством виртуального устройства;

  • представление физических и виртуальных устройств и некоторых средств межпроцессового взаимодействия как файлов;

  • использование конвейеров из нескольких программ, каждая из которых выполняет одну задачу.
^

1.1. История создания и основание операционной системы UNIX


История ОС UNIX неразрывно связаны с американской компанией AT&T Bell Laboratories и прославленными именами сотрудников этой фирмы Кэна Томпсона, Денниса Ричи и Брайана Кернигана.

С 1965 по 1969 г. фирма Bell Labs совместно с компанией General Electric и группой исследователей из Массачусетского технологического института участвовала в проекте ОС Multics. Эта операционная система, хотя и не была полностью доведена до стадии коммерческого продукта, обогатила мировое сообщество системных программистов массой ценных идей, многие из которых сохраняют свою актуальность и используются применительно не только к операционным системам.

Основным недостатком ОС Multics, который, по всей видимости, и помешал довести систему до уровня программного продукта, была ее чрезмерная сложность. Оставив проект Multics, немногочисленная группа сотрудников Bell Labs решила разработать свою собственную простую операционную систему, пригодную для их собственных нужд. С этого и началась ОС UNIX. Название UNIX было придумано Брайаном Керниганом для простейшей операционной системы, работавшей на PDP 7 (1970 г.). Эта система была написана на языке ассемблера и была мало похожа на современный UNIX: сохранились только общие подходы к логической организации файловой системы и управлению процессами, а также некоторые утилиты для работы с файлами. В 1971 г. система была переписана (все еще на языке ассемблера) для более мощной ЭВМ PDP 11/20. В первой версии ОС UNIX для PDP 11 были воплощены уже почти все идеи, признаваемые теперь как основа UNIX. Отсутствовал только механизм взаимодействия процессов через программные каналы (pipe), но и этот механизм появился во второй версии системы. Параллельно с этим велась разработка языка программирования, пригодного для написания операционных систем. На основе существовавшего к этому времени языка BCPL был создан популярнейший теперь язык Си.

И, наконец, в 1973 г. ОС UNIX была переписана на языке Си. Основными разработчиками этого варианта системы были Томпсон и Ритчи. Широкое распространение получила шестая версия UNIX (1975 г.), но подлинную революцию произвела разработка седьмой версии, которая стала первой по- настоящему мобильной версией системы. Это было продемонстрировано прежде всего самими разработчиками, осуществившими успешный перенос системы с 16- разрядной PDP 11 на 32-разрядную ЭВМ Interdata 8/32 (1977 г.).

C 1979 г. UNIX Version 7 начала активно распространяться и была перенесена на множество разнообразных ЭВМ. Важным этапом в истории OC UNIX явилась разработка версии системы для ЭВМ VAX 11/780 (UNIX 32V). Эта работа была выполнена сотрудниками Bell Labs Джоном Рейзером и Томом Лондоном и получила дальнейшее развитие в Калифорнийском университете (г. Беркли) в серии BSD UNIX. В дальнейшем история ОС UNIX развивалась весьма бурно, так что проследить все детали затруднительно. В настоящее время с тематикой ОС UNIX связано множество коммерческих фирм и исследовательских организаций. Среди них имеются и организации, разрабатывающие новые варианты системы, и фирмы, занимающиеся исключительно переносом существующих вариантов на новые ЭВМ.
^

1.2. Некоторые архитектурные особенности


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

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

Подсистема управления файлами управляет хранением и выборкой данных в пользовательских файлах. Файлы организованы в виде файловых систем, которые трактуются как логические устройства; физическое устройство, такое как диск, может содержать несколько логических устройств (файловых систем). Каждая файловая система имеет суперблок, в котором описывается структура и содержимое файловой системы, каждый файл в файловой системе описывается индексом, хранящим атрибуты файла. Системные операции работают с файлами, используя индексы.

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

Особенности UNIX, отличающие данное семейство от других ОС:

  • Файловая система древовидная, чувствительная к регистру символов в именах, очень слабые ограничения на длину имён.

  • Нет поддержки структурированных файлов ядром ОС, на уровне системных вызовов файл есть поток байт.

  • Командная строка находится в адресном пространстве запускаемого процесса, а не извлекается системным вызовом из процесса интерпретатора команд (как это происходит, например, в RSX-11).

  • Понятие «переменных окружения».

  • Запуск процессов вызовом fork(), то есть возможность клонирования текущего процесса со всем состоянием.

  • Понятия stdin/stdout/stderr.

  • Ввод/вывод только через дескрипторы файлов.

  • Традиционно крайне слабая поддержка асинхронного ввода/вывода, по сравнению с VMS и Windows NT.

  • Интерпретатор команд есть обыкновенное приложение, общающееся с ядром обыкновенными системными вызовами (в RSX-11 и VMS интерпретатор команд выполнялся как специальное приложение, специальным образом размещенное в памяти, пользующееся специальными системными вызовами, поддерживались также системные вызовы, дающие возможность приложению обращаться к своему родительскому интерпретатору команд).

  • Команда командной строки есть не более чем имя файла программы, не требуется специальная регистрация и специальная разработка программ как команд (что являлось обычной практикой в RSX-11, RT-11).

  • Не принят подход с программой, задающей пользователю вопросы о режимах своей работы, вместо этого используются параметры командной строки (в VMS, RSX-11, RT-11 программы работали также с командной строкой, но при её отсутствии выдавали запрос на ввод команд).

  • Пространство имён устройств на диске в каталоге /dev, поддающееся управлению администратором, в отличие от подхода Windows, где это пространство имен размещается в памяти ядра, и администрирование этого пространства (например, задание прав доступа) крайне затруднено из-за отсутствия его постоянного хранения на дисках (строится каждый раз при загрузке).

  • Широкое использование текстовых файлов для хранения настроек, в отличие от двоичной базы данных настроек, как, например, в Windows.

  • Широкое использование утилит обработки текста для выполнения повседневных задач под управлением скриптов.

  • «Раскрутка» ОС после загрузки ядра путём исполнения скриптов стандартным интерпретатором команд.

  • Широкое использование конвейеров (pipe).

  • Все процессы, кроме init, равны между собой, не бывает «специальных процессов».

  • Адресное пространство делится на глобальное для всех процессов ядро и на локальную для процесса части, нет «групповой» части адресного пространства, как в VMS и Windows NT, как и возможности загрузки туда кода и его исполнения там.

  • Использование двух уровней привилегий процессора вместо четырёх в VMS.

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

  • Отсутствие APC и аналогов, то есть произвольных (а не жестко перечисленных в стандартном множестве) сигналов, не доставляемых до явного пожелания процесса их получить (Windows, VMS).

  • Концепция сигнала уникальна для UNIX, и крайне сложна в переносе на другие ОС, такие, как Windows.

^

2. Прикладная среда (Application environment)


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

Основные способы реализации прикладных программных сред:

  1. трансляция системных вызовов;

  2. равноправные API;

  3. микроядерный подход.

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использованием микроядерной концепции, таких как, например, Windows NT или Workplace OS, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в операционную систему.

Один из наиболее очевидных вариантов реализации множественных прикладных сред основывается на стандартной многоуровневой структуре ОС. На рисунке 2.1 операционная система OS_1 поддерживает кроме своих «родных» приложений приложения операционных систем OS_2 и OS_3. Для этого в ее составе имеются специальные приложения – прикладные программные среды, – которые транслируют интерфейсы «чужих» операционных систем API OS_2 и API OS_3 в интерфейс своей «родной» операционной системы – API OS_1. Так, например, в случае, если бы в качестве OS_2 выступала операционная система UNIX, а в качестве OS_1 – OS/2, для выполнения системного вызова создания процесса forkO в UNIX-приложении программная среда должна обратиться к ядру операционной системы OS/2 с системным вызовом DosExecPgmO.


Рисунок 2.1 – Прикладные программные среды, транслирующие системные вызовы.
К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. Например, чтобы функция создания процесса в OS/2 DosExecPgmO полностью соответствовала функции создания процесса forkO в UNIX-подобных системах, ее нужно было бы изменить, чтобы она поддерживала возможность копирования адресного пространства родительского процесса в пространство процесса-потомка. (При нормальном же поведении этой функции память процесса-потомка инициализируется на основе данных нового исполняемого файла.)

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов. В приведенном на рисунке 2.2 примере операционная система поддерживает приложения, написанные для OS_1, OS_2 и OS_3. Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS_1, API OS_2 и API OS_3.


Рисунок 2.2 – Реализация совместимости на основе нескольких равноправных API
В этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем случае несовместимые прикладные среды. В разных ОС по-разному осуществляется управление системным временем, используется разный формат времени дня, на основании собственных алгоритмов разделяется процессорное время и т.д. Функции каждого API реализуются ядром с учетом специфики соответствующей ОС, даже если они имеют аналогичное назначение. Например, как уже было сказано, функция создания процесса работает по-разному для приложения UNIX и приложения OS/2. Аналогично при завершении процесса ядру также необходимо определять к какой ОС относится данный процесс. Если этот процесс был создан по запросу UNIX-приложения, то в ходе его завершения ядро должно послать родительскому процессу сигнал, как это делается в ОС UNIX. А по завершении процесса OS/2, созданного с параметром EXEC_SYNC, ядро должно отметить, что идентификатор процесса не может быть повторно использован другим процессом OS/2. Для того чтобы ядро могло выбрать нужный вариант реализации системного вызова, каждый процесс должен передавать в ядро набор идентифицирующих характеристик.

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



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

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

  • очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

  • надежность и стабильность выражаются в том, что при отказе одной из прикладных сред все остальные сохраняют работоспособность;

  • низкая производительность микроядерных ОС сказывается на скорости работы прикладных сред, а значит, и на скорости выполнения приложений.

Создание в рамках одной операционной системы нескольких прикладных сред для выполнения приложений различных ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее между операционными системами. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной ОС с приложениями, написанными для других ОС. В результате пользователи получают большую свободу выбора операционных систем и более легкий доступ к качественному программному обеспечению.
^

3. Ядро операционной системы (Kernel)


Ядро операционной системы (Kernel) – часть операционной системы:

  • постоянно находящаяся в оперативной памяти;

  • управляющая всей операционной системой;

  • содержащая: драйверы устройств, подпрограммы управления памятью, планировщик заданий;

  • реализующая системные вызовы и т.п.

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

3.1. Основные функция ядра


Ядро операционной системы, как правило, содержит программы для реализации следующих функций:

  1. обработка прерываний;

  2. создание и уничтожение процессов;

  3. переключение процессов из состояния в состояние;

  4. диспетчирование;

  5. приостановка и активизация процессов;

  6. синхронизация процессов;

  7. организация взаимодействия между процессами;

  8. манипулирование блоками управления процессами;

  9. поддержка операций ввода-вывода;

  10. поддержка распределения и перераспределения памяти;

  11. поддержка работы файловой системы;

  12. поддержка механизма вызова-возврата при обращении к проце­дурам;

  13. поддержка определенных функций по ведению учета работы машины.

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

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

3.2. Типы архитектур ядер операционных систем


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

^ Монолитное ядро – классическая и, на сегодняшний день, наиболее распространенная архитектура ядер ОС. Монолитные ядра предоставляют богатый набор абстракций оборудования. Все части монолитного ядра работают в одном адресном пространстве.

Монолитные ядра имеют долгую историю развития и усовершенствования и, на данный момент, являются наиболее архитектурно зрелыми и пригодными к эксплуатации. Вместе с тем, монолитность ядер усложняет их отладку, понимание кода ядра, добавление новых функций и возможностей, удаление «мертвого», ненужного, унаследованного от предыдущих версий, кода. «Разбухание» кода монолитных ядер также повышает требования к объему оперативной памяти, требуемому для функционирования ядра ОС. Это делает монолитные ядерные архитектуры мало пригодными к эксплуатации в системах, сильно ограниченных по объему ОЗУ, например, встраиваемых системах, производственных микроконтроллерах и т.д.

Альтернативой монолитным ядрам считаются архитектуры, основанные на микроядрах.



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

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

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

Модульные ядра предоставляют особый программный интерфейс (API) для связывания модулей с ядром, для обеспечения динамической подгрузки и выгрузки модулей. В свою очередь, не любая программа может быть сделана модулем ядра: на модули ядра накладываются определенные ограничения в части используемых функций (например, они не могут пользоваться функциями стандартной библиотеки С/С++ и должны использовать специальные аналоги, являющиеся функциями API ядра). Кроме того, модули ядра обязаны экспортировать определенные функции, нужные ядру для правильного подключения и распознавания модуля, для его корректной инициализации при загрузке и корректного завершения при выгрузке, для регистрации модуля в таблице модулей ядра и для обращения из ядра к сервисам, предоставляемым модулем.

Не все части ядра могут быть сделаны модулями. Некоторые части ядра всегда обязаны присутствовать в оперативной памяти и должны быть жестко «вшиты» в ядро. Также не все модули допускают динамическую подгрузку (без перезагрузки ОС). Общей тенденцией развития современных модульных ядер является все большая модуляризация кода, улучшение механизмов динамической подгрузки и выгрузки, уменьшение или устранение необходимости в ручной подгрузке модулей или в переконфигурации ядра при изменениях аппаратуры путем введения тех или иных механизмов автоматического определения оборудования и автоматической подгрузки нужных модулей, универсализация кода ядра и введение в ядро абстрактных механизмов, предназначенных для совместного использования многими модулями. Примером может служить VFS — «виртуальная файловая система», совместно используемая многими модулями файловых систем в ядре Linux.

Микроядро – это минимальная реализация функций ядра операционной системы. Классические микроядра предоставляют лишь очень небольшой набор низкоуровневых примитивов, или системных вызовов, реализующих базовые сервисы операционной системы. Сюда относятся:

  1. управление адресным пространством оперативной памяти;

  2. управление адресным пространством виртуальной памяти;

  3. управление процессами и потоками (нитями);

  4. средства межпроцессной коммуникации.

Все остальные сервисы ОС, в классических монолитных ядрах предоставляемые непосредственно ядром, в микроядерных архитектурах реализуются в адресном пространстве пользователя (Ring3) и называются сервисами. Примерами таких сервисов, выносимых в пространство пользователя в микроядерных архитектурах, являются сетевые сервисы, файловая система, драйверы.

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

В то же время микроядерная архитектура операционной системы вносит дополнительные накладные расходы, связанные с передачей сообщений, что отрицательно влияет на производительность. Для того чтобы микроядерная операционная система по скорости не уступала операционным системам на базе монолитного ядра, требуется очень аккуратно проектировать разбиение системы на компоненты, стараясь минимизировать взаимодействие между ними. Таким образом, основная сложность при создании микроядерных операционных систем – необходимость очень аккуратного проектирования. Классическим примером микроядерной системы является Symbian OS.



Рисунок 3.2.2 – Архитектура микроядра основывается на программах-серверах пользовательского режима

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

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

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

Архитектуры на основе экзоядер являются дальнейшим развитием и усовершенствованием микроядерных архитектур и одновременно ужесточают требования к минималистичности и простоте кода ядра.

libOS может обеспечивать произвольный набор абстракций, совместимый с той или иной уже существующей операционной системой, например Linux или Windows.



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

В некотором смысле концепция наноядра близка к концепции HALHardware Abstraction Layer, предоставляя вышележащему программному обеспечению удобные механизмы абстракции от конкретных устройств и способов обработки их прерываний.

Наиболее часто в современных компьютерах наноядра используются для виртуализации аппаратного обеспечения реальных компьютеров или для реализации механизма гипервизора, с целью позволить нескольким или многим различным операционным системам работать одновременно и параллельно на одном и том же компьютере.

Наноядра также могут использоваться для обеспечения переносимости (портабельности) операционных систем на разное аппаратное обеспечение или для обеспечения возможности запуска «старой» операционной системы на новом, несовместимом аппаратном обеспечении без ее полного переписывания и портирования.

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

Термин «наноядро» иногда неформально используется для описания очень маленьких, упрощенных и легких микроядер, таких, как L4.

^ Гибридное ядро (англ. Hybrid kernel) – модифицированные микроядра (минимальная реализация основных функций ядра операционной системы компьютера), позволяющие для ускорения работы запускать «несущественные» части в пространстве ядра. Имеют «гибридные» достоинства и недостатки.

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

Существуют варианты ОС ^ GNU, в которых вместо монолитного ядра применяется ядро Mach (такое же, как в Hurd), а поверх него в пользовательском пространстве работают те же самые процессы, которые при использовании Linux были бы частью ядра. Другим примером смешанного подхода может служить возможность запуска операционной системы с монолитным ядром под управлением микроядра. Так устроены 4.4BSD и MkLinux, основанные на микроядре Mach. Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов. Все остальные функции, в том числе взаимодействие с прикладными программами, осуществляется монолитным ядром. Данный подход сформировался в результате попыток использовать преимущества микроядерной архитектуры, сохраняя по возможности хорошо отлаженный код монолитного ядра.

Наиболее тесно элементы микроядерной архитектуры и элементы монолитного ядра переплетены в ядре Windows NT. Хотя Windows NT часто называют микроядерной операционной системой, это не совсем так. Микроядро NT слишком велико (более 1 Мбайт, кроме того, в ядре системы находится, например, еще и модуль графического интерфейса), чтобы носить приставку «микро». Компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как и положено в микроядерных операционных системах. В то же время все компоненты ядра работают в одном адресном пространстве и активно используют общие структуры данных, что свойственно операционным системам с монолитным ядром. По мнению специалистов Microsoft, причина проста: чисто микроядерный дизайн коммерчески невыгоден, поскольку неэффективен.

Таким образом, Windows NT можно с полным правом назвать гибридной операционной системой.

Смешанное ядро, в принципе, должно объединять преимущества монолитного ядра и микроядра: казалось бы, микроядро и монолитное ядро – крайности, а смешанное – золотая середина. В них возможно добавлять драйвера устройств двумя способами: и внутрь ядра, и в пользовательское пространство. Но на практике концепция смешанного ядра часто подчеркивает не только достоинства, но и недостатки обоих типов ядер.

Ядро не участвует в конкуренции за ресурсы и системной задачей не является. Все необходимые ему ресурсы выделяются отдельно от других задач, фиксировано (часть оперативной памяти). Процессор предоставляется ядру вне конкуренции по прерываниям.

4. Диспетчер


^ Диспетчер для операционной системысистемное программное обеспечение, промежуточный слой между операционными системами реального времени (ОС РВ) и функциональными задачами, обеспечивающий заданную временную диаграмму.

Функции диспетчера:

  1. создание процессов для функциональных задач;

  2. создание обработчиков событий;

  3. синхронизация процессов и обработчиков для правильного формирования временной диаграммы;

Известны два типа построения диспетчера с запуском задач по расписанию (^ Time Triggered) и с запуском задач по событиям (Event Triggered). Запуск задач по расписанию обычно строится на базе часов реального времени, либо по прерываниям от внешнего источника тактирующих импульсов. Так как часы реального времени, как правило, строятся на базе аппаратного таймера, вызывающего прерывания с заданным периодом повторения, можно считать первый тип разновидностью второго.

Планирование задач может осуществляться либо циклически (Round-Robin) с выделением каждой задаче кванта времени, на который она получает процессор, либо по приоритетам, когда запуск задачи с более высоким приоритетом приостанавливает выполнение задач с более низким.

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

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

Операционные системы могут включать до трёх различных типов планировщиков: долговременный планировщик (или планировщик разрешения выполнения), среднесрочный планировщик и краткосрочный планировщик (также известный как диспетчер). Сами названия уже описывают относительную частоту, с которой планировщик выполняет свои функции.


Скачать файл (277.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru