Обзор систем реального времени

На рынке сейчас имеются следующие типы ОС РВ:

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

Ядра реального времени. В класс входят системы с монолитным ядром, где и содержится реализация механизмов реального времени. Эти системы модульны, хорошо структурированы, имеют развитый набор специфических механизмов реального времени, компактны и предсказуемы. Самые популярные системы: OS-9, QNX. Особенность продуктов этого класса – высокая степень масштабируемости. На их базе строят как компактные СРВ, так и большие системы серверного класса, а их ядра имеют два типа систем разработки – кроссовую и резидентную.

Клоны UNIX реального времени. Исторически СРВ создавались в эпоху расцвета ОС UNIX, поэтому многие из них содержат те или иные заимствования из этой ОС (пользовательский интерфейс, концепция процессов и т.д.). Часть разработчиков ОС РВ попыталась просто переписать ядро UNIX, сохранив при этом интерфейс пользовательских процессов с системой, насколько это было возможно. Получили и реальное время, и сразу весь набор пользовательских приложений – компиляторы, пакеты, различные инструментальные системы. Однако семейство Unix реального времени не лишено недостатков: СРВ получаются достаточно большими и менее реактивными, чем системы первых двух классов. Наибольшим спросом пользуется ОС РВ Lynx OS.

Расширения реального времени для NT. Появление новых программных технологий, таких, как OPC (OLE-For Рrocess Control), говорит о тенденциях разделения функций СРВ по уровням. Системы первых двух классов с появлением на рынке Windows NT не испытают никакого давления, поскольку область их применения – компактные, встроенные приложения жесткого реального времени на контроллерах различной архитектуры (среди которых и Intel). Представляется маловероятным сколько-нибудь широкая замена этих систем на Windows NT. На это есть несколько причин:

а) небольшое количество архитектур, поддержанных Windows NT;

б) невозможность построения компактной системы (контроллер должен содержать электронный диск во Flash-памяти объемом не менее 10 Мбайт и оперативную память не менее 16 Мбайт);

в) в приложениях жесткого реального времени используют только один комплект расширений – дополнительное ядро реального времени;

г) бедный набор механизмов межзадачной коммуникации.

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

Расширения реального времени Windows NT имеют те же слабые стороны, что и UNIX РВ: невозможность построения компактных систем и множество недостатков при работе в реальном времени.

В настоящее время имеется более 60 ОСРВ. Версии ОС UNIX, являясь широко распространенными в научной и технической сферах, были в конце 70-х – начале 80-х годов адаптированы к задачам РВ. Причем первоначально UNIX системы не требовали лицензии. Но затем ситуация изменилась. Это стало стимулом для таких крупных фирм, как IBM, DEC, HP, отреагировать на данное событие путем создания OSF, которая предназначалась для создания ОСРВ с тем, чтобы не зависеть от одного или единственного поставщика ОСРВ (UNIX). Эта организация разработала ряд программных средств по ОСРВ, основной из которых была система OSF/1. Вместе с тем широкое распространение персональных компьютеров обусловило широкую популярность ОС MS DOS и Windows. MS DOS имела ограниченное использование для задач ОСРВ, а Windows (особенноWindows NT) имеет достаточно развитые механизмы ОСРВ: управление потоками, семафоры и, что особенно важно, механизмы, поддерживающие безопасную и отказоустойчивую работу СРВ. Специально в качестве ОСРВ были созданы:

1. OS9 (написана на С для микропроцессорных наборов фирмы Motorola);

2. WAX/VMS (написана для процессоров WAX фирмы DEC);

3. QNX (разработана канадской фирмой QNX Soft Where System).

Простейшие ОСРВ (OSIK или RTX) предоставляют только базовые средства по диспетчеризации задач и обработке прерываний. Подобные базовые системы не поддерживают стандартных интерфейсов разработки ПО, зафиксированных в POSIX, и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ являются компактность, открытость исходного кода и обеспечение гарантированного времени реакции системы. Недостатками таких ОСРВ являются: низкая масштабируемость; сложность интеграции компонентов системы в единое целое; сложность повторного использования приложений, разработанных для других проектов; ограниченность средств отладки.

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

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

Рис2.1. Архитектуры СРВ на основе Linux

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

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

Рис. 2.2. Логическое распределение приоритетов

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

Иногда приходится иметь дело с эффектом инверсии приоритетов в области обработчика прерывания Linux и задач ОСРВ.

Интеграция двух ОС, т.е. заимствованные ОСРВ и системы Linux, требует внесения некоторых изменений в ПО обеих систем. Часть изменений, связанных с интеграцией высокоприоритетного ядра ОСРВ, сделаны в ОС Linux версий 2.4.х и выше. Существуют механизмы встраивания вызовов функций внешнего кода из кода инициализации ядра Linux, из кода обработки прерываний и непосредственно из ядра.

OS-9 относится к классу UNIX подобных, гибко конфигурируемой высокопроизводительной ОСРВ и предлагает к использованию многие элементы среды UNIX. Модульность системы означает, что она может быть масштабирована для удовлетворения нужд как встроенных систем, так и больших сетевых приложений. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули создают системы с разной конфигурацией – от миниатюрных автономных ПЗУ ориентированных ядер до полномасштабных многопользовательских систем разработки. Разработка программ ведется в полнофункциональных конфигурациях. После отладки кода программы реального времени отсоединяются модули разработки и ввода/вывода, и код готов к исполнению под управлением ядра в целевой системе.

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

OS-9 имеет самый широкий набор файловых менеджеров по сравнению с другими ОСРВ. Базовые файловые менеджеры OS-9 предназначены для организации обмена информацией между процессами и обеспечивают приложениям OS-9 доступ к различным последовательным устройствам типа принтеров и терминалов, а также к устройствам внешней памяти. Сетевые файловые менеджеры обеспечивают доступ к самым разным сетевым устройствам по протоколу TCP/IP. Файловые менеджеры также поддерживают различные высокоуровневые сетевые протоколы и протоколы передачи файлов.

Модульная структура OS-9 позволяет разработчику выбирать именно те функциональные блоки, которые требуются данному приложению. Любая из опций легко может быть добавлена в систему для обеспечения соответствия изменившимся требованиям к системе. Для поддержки таких сложных приложений, как телекоммуникации, мультимедиа и системы выдачи видеоданных по запросу, фирма Microware разработала ряд дополнительных файловых менеджеров.

Файловый менеджер управления стеком протоколов поддерживает несколько типов коммуникационных протоколов типа X.25 и LAP-B. Он обеспечивает независимую от сети архитектуру для динамической сборки и разработки (stacking and unstacking) модулей протокола и драйверов устройств. В автономной встроенной системе такие приложения и стеки протокола могут быть как резидентными в устройстве, так и загружаться в устройство через сеть.

Пользовательский интерфейс мультимедиа-приложения MAUI содержит расширенный набор протоколов API для соответствия требованиям высокопроизводительных мультимедиа-протоколов либо протоколов пользователя. С данным интерфейсом общаются такие являющиеся промышленным стандартом пакеты, как Apple QuickDraw и QuickTime, Macromedia Director, Oracle Media Objects и Sybase Gain.

ISDN-менеджер рассчитан на глобальные телекоммуникационные приложения: видеоконференции, высокоскоростная факс-связь и мосты между локальными и глобальными сетями. ISDN-менеджер позволяет системе OS-9 осуществлять доступ к Базовому каналу ISDN-сети (Basic Rate Channel). Файловый менеджер для приложений мультимедиа MPFM, соответствующий спецификациям MPEG, рассчитан на использование в различных приложениях мультимедиа, включающих интерактивное телевидение, образование, обучение и выдачу видеоинформации по запросу.

Основные характеристики OS-9:

· многозадачная (65535 процессов, 65535 уровней приоритета);

· многопользовательская (256 пользователей);

· переносимость приложений (ANSI C/C++, POSIX 1003.1, TCP/IP (NFS, RPC), X Windows X11.R6 (OSF Motif)), JAVA;

· 100% размещение в ПЗУ системы и приложений пользователя;

· объектно-ориентированный модульный дизайн;

· полностью вытесняемое детерминированное ядро с минимальным временем реакции на прерывание;

· многоуровневая, основанная на приоритетах обработка прерываний;

· развитые сетевые средства (Arcnet, Ethernet, OMNInet, X.25, ISDN T1/E1, ATM NFM, TCP/IP, IPX Profibus, CAN, MIL STD 1553…);

· графические оконные интерфейсы – GUI;

· резидентные и кросс-средства разработки, прогрессивная технология высокооптимизирующего ANSI C/C++ компилятора;

· поддержка host-систем (IBM PC (MS Windows 3.xx, 95, NT), IBM RS6000/AIX, Sun4/SunOS/Solaris, HP9000 S/700, SGI IRIS/IRIX);

· широкая поддержка сторонних разработчиков программного обеспечения;

· широкая поддержка разработчиков аппаратных средств промышленной автоматизации;

· программные продукты для < < вертикальных> > рынков (мобильная беспроводная коммуникация, устройства с минимальным потреблением энергии, мультимедиа);

· специальные программные средства и лицензионная политика для OEM;

· более 800 OEM-партнеров.

VxWorks/Tornado. ОСРВ VxWorks и инструментальная среда Tornado фирмы Wind River Systems предназначены для разработки ПО встроенных компьютеров, работающих в системах жесткого реального времени. ОС VxWorks является системой с кросс-средствами разработки прикладного ПО, то есть разработка ведется на инструментальном компьютере (host) в среде Tornado для последующего исполнения на целевой машине (target) под управлением VxWorks.

VxWorks поддерживает целевые архитектуры (targets): Motorola 680x0 и CPU32, Intel 386/486/Pentium/.., Intel 960, SPARC, MIPS R3000/4000, ARM, Motorola 88110, HP PA-RISC, Hitachi SH7600, PowerPC, DEC Alpha, Siemens C16x. Инструментальные платформы, поддерживаемые для Tornado (hosts): Sun SPARCstation (SunOS и Solaris), HP 9000/400, 700 (HP-UX), IBM RS6000 (AIX), Silicon Graphics (IRIX), DEC Alpha (OSF/1), PC (Windows 95 и NT). Поддерживаемые интерфейсы host-target: Ethernet, RS-232, внутрисхемный эмулятор ICE (In-Circuit Emulator), кросс-шина (backplane), ROM-эмулятор, BDM-интерфейс (Background Debug Mode).

Инструментальная среда Tornado имеет открытую архитектуру, что позволяет другим фирмам-производителям инструментальных средств разработки ПО реального времени интегрировать свои программные продукты с Tornado. Пользователь может подключать к Tornado свои специализированные средства разработки, а также расширять возможности инструментальных средств фирмы Wind River Systems.

В стандартную конфигурацию Tornado входят ядро VxWorks и системные библиотеки, GNU C/C++ Toolkit, дистанционный отладчик уровня исходного языка CrossWind, оболочка WindSh, конфигуратор BSP WindConfig и др.

IA-SPOX. Это многозадачное ядро реального времени, разработанное компанией Spectron Microsystems, было первой успешной попыткой соединения Windows и жесткое реальное время. IA-SPOX спроектировано в виде набора виртуальных драйверов (VxD), которые работают совместно с ядром Windows 95 на нулевом уровне привилегий процессора (Ring 0). Пользовательские программы, работающие на третьем уровне (Ring 3), могут вызывать функции и процессы реального времени, а также обмениваться данными с ними. IA-SPOX показала свою эффективность в программной реализации синтеза звука, высокоскоростной модемной связи и решения других задач, требующих быстрой и детерминированной реакции системы.

Falcon является развитием известной ОС iRMX. Для этого Intel передала права на эту ОСРВ компании RadiSys для последующей интеграции данного продукта с платформой Windows NT. Выбран стандартный путь лицензирования у Microsoft исходных текстов уровня HAL, с изменением под требования жесткого реального времени.

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

Hyperkernel. Подсистема реального времени для Windows NT фирмы Imagination Systems. Hyperkernel позволяет сочетать высокоскоростные задачи управления, требующие детерминированного времени отклика, и менее критичные приложения типа ПО операторского интерфейса. Microsoft и в этом случае предоставила исходные тексты HAL-уровня и разрешила распространение модифицированных версий.

CF-MNTR объединяет в себе свойства многозадачной СРВ с развитыми коммуникационными возможностями и системы типа SCADA. Коммуникационные возможности системы не накладывают ограничений на оборудование связи и технологические контроллеры. Все аппаратно зависимые свойства оборудования учитываются в простом сетевом драйвере(драйверах) нижнего уровня, создаваемом разработчиками АСУ ТП. Использование СРВ CF-MNTR при разработке и реализации комплексных АСУ ТП позволяет разработчикам применять в качестве аппаратного обеспечения любые средства (контроллеры, линии связи).

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

Общая характеристика (для одного узла):

- общее число двоичных датчиков в системе – до 5000;

- общее число исполнительных устройств – до 3200;

- число независимых процессов, работающих одновременно – до 70;

- максимальное регламентируемое время реакции системы – не более 0, 5сек (реальное время до 0, 2сек);

 

 

2.2. Операционная система Windows NT

2.2.1. Ужесточение требований к ОС 90-х годов

Осенью 1988 года Microsoft пригласила на работу Дэвида Н. Катлера (David N. Cutler), чтобы возглавить новый проект создания ОС Microsoft 90-х годов. В результате анализа проблемы были сформулированы основные требования, предъявляемые рынком к новой ОС:

Переносимость позволило бы быстро переходить от одной архитектуры к другой.

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

Распределенные вычисления в сети позволили малым компьютерам связываться друг с другом, совместно используя аппаратные или вычислительные ресурсы (в форме файл-серверов, серверов печати и серверов вычислений).

Совместимость с POSIX. Во второй половине 80-х годов стали определять POSIX (переносимый интерфейс ОС, основанный на UNIX” (portable operating system interface basic on UNIX)) в качестве международного стандарта программного обеспечения для интерфейсов ОС UNIX-типа. Стандарт POSIX (стандарт IEEE 1003.1-1988) поощряет фирмы, реализующие UNIX-подобные интерфейсы, делать их совместимыми, чтобы программисты могли легко переносить свои приложения с одной системы на другую.

Для удовлетворения сформулированных требований, предъявляемых рынком к новой ОС, фирма VenturCom разработала подсистему реального времени RTX (Real-Time Extensions) для Windows NT при поддержке Microsoft. Microsoft передала лицензию на исходные тексты такого компонента Windows NT, как Уровень Абстракции Аппаратуры (HAL, Hardware Abstraction Level), который в основном и определяет характеристики ОС по обработке прерываний. RTX добавляет дополнительные вызовы к интерфейсу прикладного программирования (RTAPI, Real-Time API), а также загружает модифицированный HAL, который изолирует аппаратные прерывания от ядра Windows NT. RTX предоставляет для системы таймер реального времени и уменьшает время отклика. RTX обеспечивает для процессов доступ к физическим адресам памяти и портов ввода/вывода, а также специальные методы работы со страничной памятью, исключающие свойственные Windows NT задержки. Соответствующим образом отрабатываются попытки перезагрузки или тяжелые остановы.

 

 

2.2.2. Операционные системы реального времени и Windows NT

Процессы в Windows NT принадлежат двум различным классам приоритетов: динамическому и реального времени. Большинство процессов принадлежат динамическому классу, который допускает изменение своих приоритетов ОС в зависимости от таких факторов, как являются ли они фоновыми задачами или они недавно ожидают. Это хорошо для GPOS (General propose OS), так как позволяет всем потокам быть запущенными и предоставляет пользователям более быструю реакцию от активного приложения. Однако правила, определяющие эти изменения приоритетов, не подходят для RTOS (real-time OS). Поэтому Microsoft включила ряд приоритетов выше динамического класса, назвав их (Real-Time Class) класс приоритетов реального времени. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, а приоритет процессов динамического класса может меняться диспетчером. В Windows NT имеется только 7 различных уровней для нити в данном процессе. А у большинства ОСРВ имеется по крайней мере 256 различных уровней (чем больше имеется уровней, тем более предсказуемо поведение системы). В Windows NT многие нити будут выполняться с одинаковыми приоритетами, то есть предсказуемость поведения системы будет посредственной. В Windows NT процессы выполняются в своем собственном пространстве памяти. Добиться этого позволяют механизмы виртуальной памяти и подкачки. Это для СРВ порождает непредсказуемость, особенно если система отправит страницу из памяти на диск.

Потоки, запущенные с этими приоритетами, выполняются до процессов, запущенных с приоритетами из динамического класса. ОС не изменяет их приоритет и определяет большой контроль за разработчиком. Microsoft не рекомендует, чтобы потоки тратили много времени в этом классе, так как они имеют приоритет выше, чем некоторые системные задачи, такие, как сброс кэша диска и контроль ввода. Блокировка инверсии приоритетов происходит в потоках, ожидающих мьютекса. Большинство RTOS решают эту проблему путем инверсии приоритетов, но Windows NT использует схему, где потоки, которые не запускаются некоторое время, принимают случайный приоритет, повышая возможность быть запущенным. Это приводит к непредсказуемости и поэтому неприемлемо для СРВ.

Базовая идея построения Windows NT основана на принципах модульности и объектно-ориентированного программирования. Эта идея распространена и на ядро ОС и определяет ее функциональную независимость от аппаратуры для чего используют уровень абстрагирования от аппаратуры (hardware abstraction layer, HAL). Структура Windows NT включает две части: одна работает в пользовательском режиме (защищенные подсистемы Windows NT), а другая – в режиме ядра (исполнительная система NT) (рис. 2.3).

Рис. 2.3. Блок схема Windows NT

Серверы Windows NT называются защищенными подсистемами (protected subsystems), так как каждый из них – это отдельный процесс, память которого защищена от других процессов системой виртуальной памяти исполнительной системы NT. Так как совместное использование памяти подсистемами не реализуется автоматически, то коммуникации между ними осуществляются путем передачи сообщений. Термин " сервер" подразумевает, что каждая защищенная подсистема обеспечивает API, который могут использовать программы. Когда приложение (или другой сервер) вызывает некоторую процедуру API, серверу, реализующему данную процедуру, посылается сообщение при помощи средства локального вызова процедур (local procedure call, LPC) – оптимизированного механизма исполнительной системы NT для локальной передачи сообщений. Сервер же посылает ответное сообщение, вызывающее программу.

В Windows NT имеется два типа защищенных подсистем: подсистемы среды (environment subsystems) и неотъемлемые подсистемы (integral subsystems). Подсистема среды – это сервер пользовательского режима, реализующий API некоторой ОС. Когда приложение вызывает функцию API, этот вызов доставляется посредством LPC подсистеме среды. Та исполняет вызов и возвращает результаты прикладному процессу, посылая другой LPC.

Самая важная подсистема среды в Windows NT – это подсистема Win32, которая предоставляет прикладным программам API 32-разрядной Windows и реализует графический интерфейс пользователя Windows NT и управляет всем вводом пользователя и выводом приложений. В Windows NT имеются подсистемы среды POSIX, OS/2, 16-разрядной Windows и MS-DOS. Данные подсистемы предоставляют свои API, но используют для получения пользовательского ввода и отображения результатов подсистему Win32.

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

Некоторые компоненты сетевого обеспечения Windows NT также реализованы как защищенные подсистемы: сервис рабочей станции и сервис сервера. Каждый из этих сервисов (services), как часто называют сетевые подсистемы, является процессом пользовательского режима, реализующим API для доступа и управления, соответственно, сетевым редиректором[4] и сервером LAN Manager. На удаленной машине такие запросы принимаются сервером. И редиректор, и сервер LAN Manager реализованы как драйверы файловых систем, т. е. являются частью системы ввода/вывода NT.

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

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

Основные компоненты исполнительной системы и их области ответственности:

· Диспетчер объектов создает, поддерживает и уничтожает объекты исполнительной системы NT – абстрактные типы данных, представляющие системные ресурсы.

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

· Диспетчер процессов создает и завершает процессы и потоки, а также приостанавливает и возобновляет исполнение потоков, хранит и выдает информацию о процессах и потоках NT.

· Средство локального вызова процедур (LPC)передает сообщения между клиентскими и серверными процессами, расположенными на одном и том же компьютере. LPC – это гибкая, оптимизированная версия удаленного вызова процедур (remote procedure call, RPC), средства коммуникации между клиентскими и серверными процессами по сети, являющегося промышленным стандартом.

· Диспетчер виртуальной памяти реализует виртуальную память (virtual memory, VM) – схему управления памятью в виде подкачки страниц (paging), которая предоставляет каждому процессу большое собственное адресное пространство и защищает это пространство от других процессов. Если память используется интенсивно, то диспетчер виртуальной памяти переносит содержимое выбранного блока памяти на диск и загружает обратно, когда он снова понадобится.

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

· Система ввода/вывода состоит из группы компонентов, отвечающих за выполнение ввода/вывода на разнообразные устройства. В систему ввода/вывода входят следующие подкомпоненты:

· Диспетчер ввода/вывода реализует средства ввода/вывода, не зависящие от типа устройства, и устанавливает модель для ввода/вывода исполнительной системы NT.

· Файловые системы образуют драйверы NT, принимающие запросы файлового ввода/вывода и транслирующие их в запросы, привязанные к конкретному устройству.

· Сетевой редиректор (network redirector) и сетевой сервер (network server) это драйверы файловой системы, передающие удаленные запросы ввода/вывода на машины в сети и принимающие от них такие запросы.

· Драйверы устройств исполнительной системы NT. Низкоуровневые драйверы, напрямую работающие с оборудованием для записи вывода или считывания ввода с физических устройств или с сети.

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

· Слой абстрагирования от оборудования (HAL) это кодовая прослойка между исполнительной системой NT и аппаратной платформой, на которой работает ОС. Она скрывает аппаратно-зависимые детали, такие как интерфейсы ввода/вывода, контроллеры прерываний и механизмы межпроцессорных связей. Чтобы обращаться к аппаратуре непосредственно, исполнительная система NT сохраняет максимальную переносимость, обращаясь к функциям HAL, когда ей нужна платформенно-зависимая информация.

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

 

 

2.2.3. Процессы и потоки NT

В Windows NT за создание, удаление и взаимодействие процессов отвечает диспетчер процессов (process manager). Базовые процессы NT имеют ряд характеристик, отличающих их от процессов других ОС:

· процессы NT реализованы как объекты, и доступ к ним осуществляется посредством объектных сервисов;

· в адресном пространстве процесса NT может исполняться несколько потоков;

· как объект-процесс, так и объект-поток имеют встроенные возможности синхронизации;

· диспетчер процессов NT не поддерживает между создаваемыми им процессами отношений родитель-потомок или каких-либо иных.

В Windows NT процесс, чтобы он мог работать, должен включать четыре элемента:

· исполняемой программы, которая определяет начальный код и данные;

· закрытого адресного пространства (address space), т. е. набора адресов виртуальной памяти, который процесс может использовать;

· системных ресурсов, таких, как семафоры, коммуникационные порта и файлы, выделяемых ОС процессу во время выполнения программы;

· по крайней мере один поток управления (thread of execution).

Адресное пространство. Каждый процесс не должен иметь неограниченного права управления другими процессами. Одним из способов достижения этого в Windows NT служит система виртуальной памяти (virtual memory). Виртуальная память включается с самого начала и каждый процесс запускается в своем собственном адресном пространстве. Это увеличивает надежность, предотвращая процессы от разрушающего воздействия других процессов, но изолирует задачи от аппаратуры и ухудшают доступ к ним непосредственно.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Популярное:

1. B. Функции языка как театральной коммуникативной системы
2. I. ФИЛОСОФИЯ ПРАВА В СИСТЕМЕ НАУК
3. II этап. Обоснование системы показателей для комплексной оценки, их классификация.
4. II. НЕПОСРЕДСТВЕННОЕ ОБСЛЕДОВАНИЕ ДЫХАТЕЛЬНОЙ СИСТЕМЫ У ДЕТЕЙ
5. III. Нравственный облик, церковно-общественная деятельность, нестроения и злополучия Константинопольской патриархии (от конца XVI в. до настоящего времени).
6. III. Поставьте предложения в Simple Past и Future Simple, используя соответствующие наречия времени. Переведите на русский язык.
7. LANGUAGE IN USE - Повторение грамматики: система времен английских глаголов в активном залоге
8. Linux - это операционная система, в основе которой лежит лежит ядро, разработанное Линусом Торвальдсом (Linus Torvalds).
9. N – интервал времени между датой учёта и датой погашения векселя
10. SWIFT как система передачи данных.
11. VI. ОРАТОРСКАЯ РЕЧЬ В СИСТЕМЕ
12. VI. Приемно-комплексная система