Введение XX век стал веком освоения космического пространства (стр. 4 )

Рис. 1.2 - Монолитная архитектура ОСРВ

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

Рис.1.3 - слоевая архитектура ОСРВ

-Архитектура «клиент-сервер». Основной принцип данной архитектуры заключается в вынесении сервисов ОС в виде серверов прикладного уровня и выполнении микроядром функций диспетчера сообщений между клиентскими прикладными программами и серверами — системными сервисами. Преимущества данной архитектуры:

-Повышенная надёжность, благодаря выделению сервисов операционной системы в пользовательское пространство где проще производить его отладку и отслеживание ошибок;

-Улучшенная масштабируемость, сервисы в которых отсутствует необходимость могут быть безболезненно исключены из конфигурации системы;

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

       За счет исполнения микроядра и сервисов ОС в разных адресных пространствах и на разных уровнях защиты процессора архитектура клиент-сервер наименьшую, по сравнению с остальными архитектурами, производительность. Данное падение производительности связано с частыми переключениями из привилегированного в непривилегированный режим и обратно[29].

Рис.1.4 - клиент-серверная архитектура ОСРВ

Процессы, потоки, задачи

Концепция многозадачности (концепция псевдопараллелизма) является одной из основополагающих для системы реального времени, исполняющейся в системе с единственным процессором, от приложений которой требуется способность обрабатывать многочисленные внешние события, происходящие асинхронно в случайные моменты времени. Понятие процесса, пришедшее из мира операционной системы UNIX, недостаточно эффективно реализуемо в многозадачной системе реального времени, поскольку процесс имеет достаточно объемный TCB – Task Control Block – управляющую структуру, включающую в себя все сведения о процессе. В ОСРВ определяется понятие новой сущности -  потока, который реализуется как легковесный подпроцесс. Потоки выполняются в контексте одного процесса, благодаря чему межпоточное переключение происходит значительно быстрее, чем переключение порождающих процессов. При этом защита памяти между потоками отсутствует, что также увеличивает производительность из-за отсутствия проверок при обращениях к памяти. Потоки являются значительно более легковесными, за счет уменьшения регистрового контекста и содержимого управляющих блоков. Данные меры приводят к существенному уменьшению накладных расходов на сохранение и восстановление управляющих блоков переключаемых потоков. Таким образом, в системах реального времени процесс инкапсулирует в себе наименьшие единицы диспетчеризации - потоки. При анализе работы системы, построенной на базе ОСРВ, каждый процесс рассматривается как приложение. Систему стараются разрабатывать таким образом, чтобы минимизировать взаимодействие приложений имеющих различную природу – «жесткого» реального времени, «мягкого» реального времени, не реального времени.

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

В практических реализациях ОСРВ применяются два подхода к планированию выполнения задач – статические алгоритмы планирования (RMS – Rate Monotonic Scheduling) и динамические алгоритмы планирования (EDF – Earliest Deadline First). RMS используется при формальном обосновании условий предсказуемости системы. Для реализации описываемой дисциплины чтобы ОСРВ имело реализацию планирования на основе приоритетов прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет назначается каждому процессу перед его стартом. Запускаемые процессы в свою очередь должны отвечать следующим требования:

-процесс должен быть завершен за отведенное время;

-процессы не имеют зависимости от хода выполнения и результатов исполнения друг друга;

-каждому процессу требуется равные кванты процессорного времени на каждом интервале;

-прерывание процесса должно происходит за ограниченное время.

При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения. После исполнения данных процессов производится исполнения оставшихся с использованием принципа исполнения первыми наиболее коротких процессов.

В EDF приоритет процесса назначается динамически в зависимости от времени, оставшегося у процесса до окончания его исполнения. При больших загрузках системы EDF имеет преимущества перед RMS в части оптимальности исполнения.

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

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

-обеспечение выполнения процесса с наивысшим приоритетом в самую первую очередь;

-недопущение инверсии приоритетов, при которой задачи с высокими приоритетами вынуждены ожидать ресурсы, захваченные низкоприоритетными задачами.

Для борьбы с инверсией приоритетов в ОСРВ применяется механизм наследования приоритетов, однако при использовании данного механизма требуется отказ от планирования на основе RMS, поскольку приоритеты задач становятся динамическими.

В общем виде организацию процесса управления потоками и задачами можно представить на схеме:

Рис 1.5 Граф многозадачности

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

Память

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

-Модель без защиты – системное и пользовательское адресные пространства не разделены и не защищены друг от друга, используется всего два сегмента памяти: сегмент кода и сегмент данных, при этом от системы не требуется никакого специального управления памятью, также не требуется и MMU (memory management unit – устройство управления памятью - специальное аппаратное устройство для поддержки управления виртуальной памятью);

-Модель защиты система/пользователь – системное адресное пространство защищено от адресного пространства пользователя, при этом системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, для поддержки данной модели требуется MMU. Защита памяти основана на использовании механизма защиты отдельных страниц. Так различают всего два вида страниц – пользовательские и системные. Пользовательские приложения, выполняющиеся в одном адресном пространстве, не защищены друг от друга. Для реализации данной модели требуется выделение четырех сегментов в памяти – два сегмента для работы на уровне ядра ОС (сегменты кода и данных) и два сегмента для работы на пользовательском уровне. Механизм страничной защиты не добавляет накладных расходов, так как защита страницы проверяется одновременно с преобразованием адреса, которое выполняет MMU, при этом от ОС не требуется дополнительной функциональности по управлению памятью;