АкушерствоАнатомияАнестезиологияВакцинопрофилактикаВалеологияВетеринарияГигиенаЗаболеванияИммунологияКардиологияНеврологияНефрологияОнкологияОториноларингологияОфтальмологияПаразитологияПедиатрияПервая помощьПсихиатрияПульмонологияРеанимацияРевматологияСтоматологияТерапияТоксикологияТравматологияУрологияФармакологияФармацевтикаФизиотерапияФтизиатрияХирургияЭндокринологияЭпидемиология

Монолитные операционные системы

Монолитные ОС являются прямой противоположностью микроядерным ОС. При этом можно согласиться с тем, как трактуется архитектура монолитных ОС в ра­боте [54]. В монолитной ОС, несмотря на ее возможную сильную структуриза­цию, очень трудно удалить один из уровней многоуровневой модульной струк­туры. Добавление новых функций и изменение существующих для монолитных ОС требует очень хорошего знания всей архитектуры ОС и чрезвычайно боль­ших усилий. Поэтому более современный подход к проектированию ОС, кото­рый может быть условно назван как «клиент-серверная» технология, позволяет в большей мере и с меньшими трудозатратами реализовать перечисленные выше принципы проектирования ОС.

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

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

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

Микроядерные ОС в настоящее время разрабатываются чаще монолитных. Од­нако следует заметить, что использование технологии клиент—сервер — это еще не гарантия того, что ОС станет микроядерной. В качестве подтверждения мож­но привести пример с ОС Windows NT, которая построена на идеологии клиент-сервер, но которую тем не менее трудно назвать микроядерной. Для того чтобы согласиться с таким высказыванием, достаточно сравнить ОС QNX и ОС Win­dows NT.

Требования, предъявляемые к ОС реального времени

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

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

Q Одновременность обработки: даже если наступает более одного события од­новременно, все временные ограничения для всех событий должны быть вы­держаны. Это означает, что системе реального времени должен быть присущ параллелизм. Параллелизм достигается использованием нескольких процес­соров в системе и/или многозадачного подхода.

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

Иногда можно услышать из разговоров специалистов, что различают системы «мягкого» и «жесткого» реального времени. Различие между жесткой и мягкой СРВ зависит от требований к системе — система считается жесткой, если «нару-

шение временных ограничений не допустимо», и мягкой, если «нарушение вре­менных ограничений нежелательно». Ведется множество дискуссий о точном смысле терминов «жесткая» и «мягкая» СРВ. Можно даже аргументировать, что мягкая СРВ не является СРВ вовсе, ибо основное требование соблюдения временных ограничений не выполнено. В действительности термин СРВ часто неправомерно применяют по отношению к быстрым системам.

Часто путают понятия СРВ и ОСРВ¹, а также неправильно используют атрибу­ты «мягкая» и «жесткая». Иногда говорят, что та или иная ОСРВ мягкая или жесткая. Нет мягких или жестких ОСРВ. ОСРВ может только служить основой для построения мягкой или жесткой СРВ. Сама по себе ОСРВ не препятствует тому, что ваша СРВ будет мягкой. Например, вы решили создать СРВ, которая должна работать через Ethernet по протоколу TCP/IP. Такая система не может быть жесткой СРВ, поскольку сама сеть Ethernet в принципе непредсказуема вследствие использования случайного метода доступа к среде передачи данных, в отличие, например, от IBM Token Ring или ARC-Net, в которых используются детерминированные методы доступа.

Итак, перечислим основные требования к ОСРВ.

Дата добавления: 2015-01-18 | Просмотры: 807 | Нарушение авторских прав