- •1.Архитектура операционных систем
- •1.1Общие вопросы архитектуры операционных систем
- •1.2Архитектура Windows
- •1.2.1История возникновения Windows
- •1.2.2Архитектура ос Windows
- •1.2.3История возникновения ос Linux
- •1.2.4Архитектура Linux
- •1.2.5Интерфейсы системы unix
- •1.2.6Файловая система unix
- •1.2.7Аутентификация в unix
- •1.2.8Сценарии командной оболочки unix
- •1.3Операционная система qnx
- •1.3.1 Архитектура qnx
- •1.4Выводы
- •1.5Вопросы для самоконтроля
- •2.Типы и алгоритмы работы с оперативной памятью
- •2.1Общие принципы функционирования подсистемы памяти в ос
- •2.1.1Обобщённые принципы управления памятью
- •2.1.2Однозадачная система без подкачки на диск
- •2.1.3Многозадачность с фиксированными разделами
- •2.1.4Подкачка
- •2.1.5Управление памятью с помощью битовых массивов
- •2.1.6Управление памятью с помощью связанных списков
- •2.1.7Виртуальная память
- •2.1.8Многоуровневые таблицы страниц
- •2.1.9Алгоритмы замещения страниц
- •2.2Виртуальная память ос Windows
- •2.2.1Архитектура памяти в ос Windows
- •2.2.2Работа с виртуальной памятью в ос Windows
- •2.2.3Использование виртуальной памяти в приложениях
- •2.3Пример организации страничной памяти на примере linux
- •2.3.1Страничная организация памяти в Linux
- •2.3.2Права доступа к области памяти
- •2.3.3Работа с областями памяти в Linux
- •3.Процессы и потоки
- •3.1Процессы
- •3.1.1Модель процесса
- •3.1.2Создание процесса
- •3.1.3Завершение процесса
- •3.1.4Состояния процессов
- •3.1.5Реализация процессов
- •3.2Потоки
- •3.2.1Реализация потоков
- •3.2.2Реализация потоков на уровне ядра
- •3.2.3Смешанная реализация
- •3.2.4 Метод управления «Активация планировщика»
- •3.2.5Всплывающие потоки
- •3.3Межпроцессное взаимодействие
- •3.3.1Состояние состязания
- •3.3.2Критические секции (Критические области)
- •3.3.3Взаимное исключение с активным ожиданием
- •3.3.4Примитивы межпроцессного взаимодействия
- •3.4Семафоры
- •3.5Мьютексы
- •3.6Организация многопоточной обработки в среде Windows
- •3.6.1Объекты ядра Windows
- •3.6.2Потоки Windows
- •3.6.3Синхронизация потоков в Windows
- •3.6.4Синхронизация потоков с помощью объектов ядра
- •3.6.5Сравнение объектов, используемых для синхронизации потоков
- •3.7Организация процессов и потоков в Linux
- •3.7.1Среда окружения в Linux
- •3.7.2Создание нового процесса. Системный вызов exec.
- •3.7.3Потоки unix. Функции потоков стандарта posix.
- •3.8Синхронизация потоков в unix
- •3.8.1Мьютексы
- •3.8.2Семафоры
- •0,0,0, //Ожидать обнуления семафора
- •0,1,0 // Затем увеличить значение семафора на 1};
- •0,1, 0 // Увеличитьзначение семафора на 1};
1.3Операционная система qnx
1.3.1 Архитектура qnx
Архитектура — это то, чем операционные системы семейства QNX, несмотря на большое внешнее сходство, отличаются от операционных систем семейства UNIX. Центральным понятием в QNX является микроядро (microkernel). Грубо говоря, микроядро почти ничего само не делает, являясь своего рода коммутирующим элементом, к которому с помощью дополнительных программных модулей добавляется та или иная функциональность. Кстати, раньше название "Neutrino" распространялось только на микроядро, теперь — на всю ОС. Кроме микроядра в ОСРВ QNX есть еще один важный элемент — Администратор процессов (Process Manager). Микроядро QNX Neutrino скомпоновано с Администратором процессов в единый модуль procnto — главный (и единственный необходимый для работы системы) компонент. Если нам надо, чтобы система реально делала какую-то работу, мы должны запустить соответствующий процесс, выполняющий эту работу. Программы, реализующие сервисные функции, называют администраторами ресурсов (Resourсe Manager). Есть администраторы ресурсов, обеспечивающие доступ к дискам, сети и т. д. Все эти программы связаны воедино микроядром и слаженно взаимодействуют с помощью механизма сообщений. Следует заметить, что существуют различные дополнительные варианты модуля procnto (не говоря о версиях для разных процессоров): procnto-smp — вариант модуля procnto с поддержкой симметричной многопроцессорности; procnto-instr — вариант модуля procnto, оборудованный средствами трассировки событий. procnto-smp-instr – модуль, совмещающий два вышеперечисленных. На самом деле функциональность ОС можно расширять не только с помощью процессов, но и с помощью библиотек динамической компоновки DLL (Dynamic Link Library). Правильнее будет сказать, что как функциональность ОС расширяется с помощью процессов, так функциональность процессов расширяется с помощью DLL. Более того, каждый администратор ресурсов может быть реализован или как программа, или как DLL. Таким образом, в общем случае QNX Neutrino представляет собой группу процессов, работающих в изолированных адресных пространствах, взаимодействующих через микроядро и включающих: администратор процессов, скомпонованный с микроядром; администраторы ресурсов; прикладные программы. Достоинства такой архитектуры очевидны: достаточно высокая надежность (т. к. при сбое любого из системных процессов, кроме procnto, остальные процессы продолжают работать), простота реконфигурирования системы и добавления новых сервисов (и наоборот — простота урезания системы, создания встраиваемых конфигураций с требуемой функциональностью), простота отладки системных сервисов (т. к. это обычные программы). С другой стороны очевидны и недостатки, отсутствующие у монолитных систем: частое переключение контекста (и, как следствие, высокие накладные расходы на выполнение ряда операций), необходимость копирования данных между процессами, решающими одну задачу. Чтобы продолжить обсуждение архитектуры QNX Neutrino, следует ввести понятие "потока", или "потока управления" (thread — "нить"). Напомним, что процесс — это выполняющаяся программа. Он включает код и данные программы, а также различную дополнительную информацию — переменные системного окружения и т. п. Поток управления — это фрагмент процесса, содержащий непрерывную последовательность команд, которые могут выполняться параллельно с другими потоками (потоками управления) того же процесса. Процесс является, по сути дела, контейнером потоков и содержит как минимум один поток. Потоки весьма полезны в ряде случаев, поэтому поддержка потоков — обязательное свойство POSIX- совместимых ОС. Обычно потоки используют: для распараллеливания задачи на многопроцессорных ЭВМ; для более эффективного использования процессора (например, пока один поток ожидает пользовательский ввод, другой может выполнять расчеты); для облегчения совместного использования данных (все потоки процесса имеют свободный доступ к данным процесса). Микроядро работает только с потоками и "ничего не знает" о процессах. Процессами управляет Администратор процессов. Таким образом, операционная система QNX является полностью модульной ОС, которая может выполняться практически на любых типах цифровых устройств.
