срв колок / 30 (1)

30. Охарактеризуйте методы разработки программного обеспечения СРВ.

При описании операционной системы часто указываются особенности ее структурной организации и основные концепции, положенные в ее осно­ву.

К базовым концепциям относятся:

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

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

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

наличие единой справочной службы разделяемых ресурсов;

единой службы времени;

использование механизма вызова удаленных процедур (RPC) для про­зрачного распределения программных процедур по машинам;

многонитевой обработки, позволяющей распараллеливать вычисления в рамках одной задачи и выполнять эту задачу сразу на нескольких компью­терах сети;

наличие других распределенных служб.

3. Монолитная архитектура

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

Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым операци­онной системой, параметры помещаются в строго определенные места - ре­гистры или стек, после чего выполняется специальная команда прерыва­ния, известная как вызов ядра или вызов супервизора. Эта команда пере­ключает машину из режима пользователя в режим ядра и передает управле­ние операционной системе. Затем операционная система проверяет пара­метры вызова, чтобы определить, какой системный вызов должен быть вы­полнен. После этого операционная система обращается к таблице как к мас­сиву с номером системного вызова в качестве индекса. В k-м элементе таб­лицы содержится ссылка на процедуру обработки системного вызова. Такая организация операционной системы предполагает следующую структуру:

1. Главная программа, которая вызывает требуемую служебную проце­дуру.

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

3. Набор утилит, обслуживающих служебные процедуры. В этой модели для каждого системного вызова имеется одна служебная процедура. Утилиты выполняют функции, которые нужны нескольким слу­жебным процедурам. Деление процедур на три уровня показано на рис. 1.

Рисунок 1. – Модель монолитной системы

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

Недостатки монолитной архитектуры:

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

2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управ­ления из-за работы низкоприоритетной задачи. Например, низкоприоритет­ная задача запросила выделение памяти, сделала системный вызов, до окон­чания которого сигнал активизации высокоприоритетной задачи не сможет ее активизировать.

3. Сложность переноса на новые архитектуры процессора из-за значи­тельных ассемблерных вставок.

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

4. Модульная архитектура на основе микроядра

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

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

1) управление взаимодействием частей системы (например, менедже­ров процессов и файлов);

2) обеспечение непрерывности выполнения кода системы (отсутствие переключения задач во время исполнения микроядра).

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

5. Объектная архитектура на основе объектов-микроядер

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

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

Объектно-ориентированный подход обеспечивает модульность, безо­пасность, легкость модернизации и повторного использования кода.

Роль API играет компилятор и динамический редактор объектных свя­зей (linker). При старте приложения динамический linker загружает нужные ему микроядра (в отличие от предыдущих систем, не все компоненты самой операционной системы должны быть загружены в оперативную память). Ес­ли микроядро уже загружено для другого приложения, то оно повторно не загружается, а используется код и данные уже имеющегося микроядра. Это позволяет сократить объем требуемой памяти.

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

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

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

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

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

Микроядра и DLL (Dynamically Linked Libraries, динамически связы­ваемые библиотеки). Многие системы оформляют библиотеки, из которых берутся функции при динамическом связывании, в виде специальных моду­лей, называемых DLL. DLL обеспечивает разделение своего кода и данных для всех работающих приложений, в то время, как для микроядер можно управлять доступом для каждого конкретного приложения. DLL не поддер­живает объектно-ориентированный подход, код DLL не является позиционно-независимым, и потому не может быть записан в ПЗУ.