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

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

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

Одним из основополагающих требований к организации работы с  памятью в системе реального времени заключается в том, что время доступа к ней должно быть детерминировано. Прямым следствием из данного требования становится запрет на использование техники выгрузки страниц и  загрузки страниц по запросу с внешних устройств для процессов требующих реального времени. Поэтому системы, реализующие механизм виртуальной памяти, должны также блокировать процессы реального времени в оперативной памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому что не является предсказуемой по времени выполнения. Если системой поддерживается страничная организация памяти, соответствующее отображение страниц в физические адреса необходимо выполнить как часть контекста процесса. В противном случае появляется непредсказуемость, неприемлемая для ОСРВ. Для процессов, не являющихся процессами "жесткого" реального времени, возможно использование механизма динамического распределения памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на запрос памяти, т. е. ограничение на предсказуемое время ожидания. В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход неприменим в среде реального времени, так как во время уплотнения перемещаемые задачи не могут выполняться, что ведет к потере непредсказуемости поведения системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA будут оставаться не самым лучшим выбором для систем жесткого реального времени. В системах жесткого реального времени обычно применяется статическое распределение памяти. В системах мягкого реального времени возможно динамическое распределение памяти, без виртуальной памяти и без уплотнения.

Прерывания

При описании управления прерываниями обычно различают две процедуры, а именно:

-программа обработки прерывания (ISR – interrupt servicing routine) – программа низкого уровня в ядре с ограниченными системными вызовами;

-поток обработки прерывания (IST – interrupt servicing thread) – поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

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

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

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

Рис 1.6 -  Схема унифицированной архитектуры прерываний

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

Часы и таймеры

В любой ОСРВ используются различные службы ведения и выдачи времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их исполнение на определенные интервалы. Службы времени ОСРВ используют высокоточные аппаратные часы для своей работы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры. Для каждого процесса и потока определяются объекты следящие за использованием процессорного времени. На базе данных объектов создаются таймеры, которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения, а также профилировать приложение. В высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, так как при этом работа системы может выйти за рамки допустимого времени отклика. Таймеры контролирующие время исполнения процессов или потоков позволяют выявлять возникновение перерасхода времени и активизировать соответствующие действия по предотвращению такого поведения. Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм, так как там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, тогда нужен тактовый генератор и/или таймер. Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не применяется. Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.

Стандарты ОСРВ

Наиболее ранним и известным стандартом ОСРВ считается стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). В своем первоначальном варианте стандарт POSIX был представлен в 1990 г. и был направлен на UNIX-подобные системы, первые версии которых были разработаны в 70-х годах двадцатого века. Спецификации POSIX регламентируют механизмы определяющие взаимодействие прикладного программного обеспечения и операционной системы. На данный момент спецификации POSIX насчитывают более чем  30 специализированных стандартов. К стандартам ОСРВ относятся семь спецификаций (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в распространенных ОСРВ приобрели только 1003.1a, 1003.1b, 1003.1c. Несмотря на некоторые явно устаревшие положения стандарта POSIX и большую востребованность обновлений методологии и механизмов стандартизации ОСРВ, значительного прогресса в этом направлении не наблюдается. Ряд представителей наиболее успешных компании, занятых разработкой ОСРВ объявляют о своем решении предложить на рассмотрение в качестве нового стандарта спецификации разрабатываемых ими ОСРВ. Так поступила TRON (the RTOS Nucleus), которая в 1987г. выпустила в свет первые ITRON спецификации – ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. Наибольшее распространение данный формат получил в Японии. Военная и аэрокосмическая отрасли традиционно предъявляют наиболее жесткие требования к вычислительным средствам, влияющим на общий показатель безопасности целевой системы. В авиационной промышленности используются два следующих стандарта для ОСРВ – стандарт DO-178B и стандарт ARINC-653. Поскольку данные стандарты были разработаны в США, необходимо указать наличие европейского стандарта ED-12B, который, по сути, является аналогом DO-178B. Распространенным также является стандарт OSEK/VDX, который первоначально развивался для систем, используемых в автомобильной индустрии.

POSIX

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