Файл: Курс лекций по дисциплине Операционные системы 2 Содержание.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 28.03.2024

Просмотров: 47

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

13
Главными системными вызовами, управляющими процессами, являются вызовы, связанные с созданием и окончанием процессов.
Каждому пользователю, которому разрешено пользоваться системой, системный администратор присваивает UID (User Identification – идентификатор пользователя). У каждого работающего процесса есть идентификатор пользователя, запустившего его.
Дочерний процесс получает тот же самый UID, что и его родитель. Пользователи могут становиться членами групп, каждая из которых имеет идентификатор группы (GID, Group
Identification). Пользователь с особым идентификатором, называемый в UNIX
«суперпользователем», имеет особые полномочия и может игнорировать множество правил защиты.
5.2. Взаимоблокировка
Когда взаимодействуют два или более процессов, они могут попадать в патовые ситуации, из которых невозможно выйти без посторонней помощи. Такая ситуация называется тупиком или взаимоблокировкой.
5.3. Управление памятью
Управление адресным пространством процессов. Что произойдет если адресное пространство процесса окажется больше, чем оперативная память компьютера, и процесс захочет использовать его целиком? В наши дни существует метод, называемый виртуальной памятью, при котором ОС держит часть адресов в оперативной памяти, а часть на диске и меняет их местами при необходисоти.
5.4. Ввод-вывод данных
Каждая ОС имеет свою подсистему ввода-вывода для управления устройствами ввода- вывода. Некоторые из программ ввода-вывода являются независимыми от устройств, то есть их можно применить ко многим или ко всем устройствам ввода-вывода. Другая часть программного обеспечения ввода-вывода, в которую входят драйверы устройств, предназначена для определенных устройств ввода-вывода.
5.5.Файлы
Основной функцией ОС является скрытие особенностей дисков и других устройств ввода- вывода и предоставление пользователю понятной и удобной абстракцией модели независимых устройств файлов. Системные вызовы очевидно необходимы для создания, удаления, чтения и записи файлов. Перед тем как прочитать файл, его нужно разместить на диске и открыть, а после прочтения его нужно закрыть. Все эти функции осуществляют системные вызовы.
Предоставляя место для хранения файлов, Ос используют понятие каталога как способ объединения файлов в группы. Каждый файл в иерархии каталогов можно определить, задав его имя пути, называемое также полным именем файла. Путь начинается из вершины структуры каталогов, называемой корневым каталогом. Такое абсолютное имя пути состоит из списка каталогов, которые нужно пройти от корневого каталога к файлу, с разделением отдельных компонентов косой чертой. /faculty/Prof.Braun/Courses/CS101.
Первая косая черта говорит о том, что этот путь – абсолютный, то есть начинается от корневого каталога. В MS DOS и Windows вместо символа косой черты используется обратная косая черта \.
5.6. Безопасность
В задачу ОС входит управление системой защиты файлов, так чтобы они, например, были доступны только пользователями, имеющими на это права. Кроме защиты файлов, существует еще множество других вопросов безопасности: защита системы от нежелательных гостей, людей, и не только (вирусов).


14
5.7. Оболочка
ОС представляет собой программу, выполняющую системные вызовы. Рассмотрим только командный интерпретатор UNIX, называемый оболочкой (shell). Хотя она не входит в ОС, но во всю используется многими функциями ОС и поэтому является хорошим примером того, как могут применяться системные вызовы. Кроме этого оболочка предоставляет основной интерфейс между пользователем, сидящим за своим терминалом, и ОС, если, конечно, пользователь не использует графический интерфейс.
5.8. Системные вызовы
Интерфейс между ОС и программами пользователя определяется набором системных вызовов, предоставляемых ОС.
5.9. Интерфейс прикладного программирования Windows API
Программа Windows управляется, как правило, событиями. Основная программа ждет, пока возникнет какое-либо событие, а затем вызывает процедуру для его обработки.
Типичные события – это нажатие клавиши, перемещение мыши или вставка в привод компакт-диска. Затем для обслуживания события вызываются обработчики.
В UNIX имеется практически однозначная связь между системными вызовами и библиотечными процедурами, используемыми для обращения к системным вызовам.
Корпорацией Microsoft определен набор процедур, названные Win32 API (Application
Program Interface – интерфейс прикладных программ). Предполагается, что программисты должны использовать его для доступа к службам ОС. Отделяя интерфейс от фактических системных вызовов, Microsoft поддерживает возможность со временем изменять существующие системные вызовы, сохраняя работоспособность уже существующих программ.
Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. application programming interface, API [эй-пи-ай]) — набор готовых классов, процедур функций, структур и констант, предоставляемых приложением
(библиотекой, сервисом) для использования во внешних программных продуктах.
Используется программистами для написания всевозможных приложений.
Win16 — первая версия Windows API для 16-разрядных версий Windows.
Изначально назывался просто Windows API, затем стал называться Win16 для отличия от
Win32.
Win32s — подмножество Win32, устанавливаемое на семейство 16-разрядных систем Windows 3.x и реализующее ограниченный набор функций Win32 API для этих систем.
Win32 — 32-разрядный API для современных версий Windows. Самая популярная ныне версия. Базовые функции этого API реализованы в DLL kernel32.dll и advapi32.dll; базовые модули GUI — в user32.dll и gdi32.dll. Win32 появился вместе с Windows NT и затем был перенесѐн (в несколько ограниченном виде) в системы серии Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss.exe (Client/Server Runtime Subsystem), работающий в пользовательском режиме, и win32k.sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро — ntoskrnl.exe
Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64- разрядных версиях Windows XP, Windows Server 2003, Windows Vista, Windows Server
2008, Windows Server 2008 R2 и Windows 7.
Количество имеющихся в Win32 API вызовов велико и исчисляется тысячами. В
Win32 API имеется огромное число вызовов для управления окнами, геометрическими фигурами, текстом, шрифтом, полосами прокрутки, диалоговыми окнами, меню и другими составляющими графического пользовательского интерфейса.


15

16
Лекция 2
1   2   3   4   5   6   7   8   9   10

Тема: Структура ОС
План:
1. Монолитные системы
2. Многоуровневые системы
3. Микроядра
4. Модель клиент-сервер
5. Виртуальные машины
6. Экзоядро
Литература:
1. Таненбаум Э. Современные операционные системы. – 3-е издание. – СПб.:
Питер, 2010. Гл. 1. с. 22-96.
2. Гордеев А.В. Операционные системы– 2-е издание. – СПб.: Питер, 2004. Гл. 1. с. 11-49.
3. Руссинович М., Соломон Д. Внутреннее устройство Microsoft Windows:
Windows Server 2003, Windows XP, windows 200. Мастер-класс./ Пер. с англ. –
4-е изд. – И.: Издательско-торговый дом «Русская Редакция»; СПб.: Питер,
2005. – с. 38-90.
Рассмотрим шесть различных использующихся (или использовавшихся ранее) структур операционных систем. Эти шесть конструкторских решений представлены монолитными системами, многоуровневыми системами, микроядрами, клиент- серверными системами, виртуальными машинами и экзоядрами.
1. Монолитные системы
Вся операционная система работает как единая программа в режиме ядра. ОС написана в виде набора процедур, связанных вместе в одну большую исполняемую программу. При использовании этой технологии каждая процедура может свободно вызвать любую другую процедуру, если та выполняет какое-нибудь полезное действие, в котором нуждается первая процедура.
Для построения исполняемого файла монолитной системы необходимо сначала скомпилировать все отдельные процедуры, а затем связать их все вместе, воспользовавшись системным компоновщиком.
Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым ОС, параметры помещаются в строго определенные места – регистры или стек, после чего выполняется специальная команда прерывания, известная как вызов ядра. Эта команда переключает машину из режима пользователя в режим ядра и передает управление ОС. Затем ОС проверяет параметры вызова, чтобы определить, какой системный вызов должен быть выполнен. После этого
ОС обращается к таблице как к массиву с номером системного вызова в качестве индекса.
В k-м элементе таблицы содержится ссылка на процедуру обработки системного вызова k.
Такая организация ОС предполагает следующую структуру:
1. Основная программа, которая вызывает требуемую служебную процедуру.
2. Набор служебных процедур, выполняющих системные вызовы.
3. Набор утилит, обслуживающих служебные процедуры.
В этой модели для каждого системного вызова имеется одна служебная процедура.
Утилиты выполняют функции, которые нужны нескольким служебным процедурам.


17
Рис. 1. Простая модель монолитной системы
2. Многоуровневые системы
Обобщение подхода, изображенного на рис. 1, является организация ОС в виде иерархии уровней, каждый из которых является надстройкой над нижележащим уровнем.
Первой такой системой была THE (Technische Hogeschool Eindhoven). Система включала 6 уровней.
0 уровень занимался распределением времени процессора, переключая процессы при возникновение прерывания или при срабатывании таймера. (Над уровнем 0 система состояла из последовательных процессов, каждый из которых мог быть запрограммирован без учета того, что несколько процессов были запущены на одном процессоре. Иными словами, уровень 0 обеспечивал основу многозадачности центрального процессора.)
1 уровень управлял памятью. Он выделял процессам пространство в оперативной памяти и на магнитном барабане объемом 512 К слов для тех частей процессов, которые не помещались в ОП. (На уровнях выше первого процессы не должны были беспокоиться о том, где именно они находятся, в памяти или на барабане; доставкой страниц в память по мере надобности занималось программное обеспечение уровня 1.)
2 уровень управлял связь между консолью оператора и процессами. Т.о., все процессы выше этого уровня имели свою собственную консоль оператора.
3 уровень управлял процессами ввода-вывода и буферизовал потоки информации к ним и от них. Любой процесс выше уровня 3, вместо того чтобы работать с конкретными устройствами, с их разнообразными особенностями, мог обращаться к абстрактным устройствам ввода-вывода, обладающим удобными для пользователя характеристиками.
На 4 уровне работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода-вывода. Процесс системного оператора размещался на уровне 5.
Дальнейшее обобщение многоуровневой концепции было сделано в ОС MULTICS.
В ней уровни представляли собою серию концентрических колец, где внутренние кольца являлись более привилегированными, чем внешние. Когда процедура внешнего кольца

18 хотела вызвать процедуру кольца, лежащего внутри, она должна была выполнить эквивалент системного вызова.
3. Микроядра
При использовании многоуровневого подхода разработчикам необходимо выбрать, где провести границу между режимами ядра и пользователя. Традиционно все уровни входили в ядро, но это не обязательно. Существуют очень весомые аргументы в пользу того, чтобы в режиме ядра выполнялось как можно меньше процессов, т.к. ошибки в ядре могут вызвать немедленный сбой системы. Для сравнения пользовательские процессы могут быть настроены на обладание меньшими полномочиями, чтобы их ошибки не носили фатального характера.
Замысел, заложенный в основу конструкции микроядра, направлен на достижение высокой надежности за счет разбиения ОС на небольшие, вполне определенные модули.
Только один из них – микроядро – запускается в режиме ядра, а все остальные запускаются в виде относительно слабо наделенных полномочиями обычных пользовательских процессов. В частности, если запустить каждый драйвер устройства и файловую систему как отдельные пользовательские процессы, то ошибка в одном из них может вызвать отказ соответствующего компонента, но не сможет вызвать сбой всей системы. Т.о., ошибка в драйвере звукового устройства приведет к искажению ил пропаданию звука, но не вызовет зависание компьютера. В отличие от этого в монолитной системе, где все драйверы находятся в ядре, некорректный драйвер звукового устройства может запросто сослаться на неверный адрес памяти и привести систему к немедленной вынужденной остановке.
Часть общеизвестных микроядер представляют Integrity, K42, L4, PikeOS, QNX,
Symbian, MINIX 3.
Микроядро MINIX 3 занимает всего лишь около 3200 строк кода на языке С и 800 строк кода на ассемблере, который использован для самых низкоуровневых функций, в частности для перехвата прерываний и для переключения процессов. Код на языке С занимается управлением и распределением процессов, управляет межпроцессорным взаимодействием (путем обмена сообщениями между процессами) и предполагает набор примерно из 35 вызовов ядра, позволяя работать остальной части ОС. Эти вызовы выполняют функции подключения обработчиков к прерываниям, перемещения данных между адресными пространствами и установки новых схем распределения памяти для только что созданных процессов. Структура процесса MINIX 3 показана на рис. 2, где обработчики вызовов ядра обозначены как Sys. В ядре также размещен драйвер часов, потому что планировщик работает с ним в тесном взаимодействии. Все остальные драйверы устройств работают как отдельные пользовательские процессы.
Рис. 2. Структура системы MINIX 3