Операционная  система ос2000

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

Разработка  ОС РВ базируется на следующих принципах:

• соответствие международным стандартам,
• мобильность,
• масштабируемость (конфигурируемость),
• использование концепции микроядра,
• использование объектно-ориентированного подхода,
• кросс-разработка.

Соответствие  стандартам

При разработке операционной системы использовались следующие международные стандарты:

• POSIX 1003.1, стандарт на мобильные операционные системы (программный интерфейс);
• стандарт С, описывающий язык и библиотеки языка С.

Изначально POSIX разрабатывался с целью устранить  разнобой в различных UNIX-системах и  тем самым способствовать мобильности  прикладных программ. UNIX был ориентирован не на решение задач реального времени, а на обеспечение одновременного доступа к ЭВМ со стороны нескольких пользователей, которые между собой не взаимодействуют или слабо взаимодействуют.

Редакция POSIX 1996 года уже охватывает (в качестве необязательной части) основные функции  операционных систем реального времени:

• потоки управления (threads),
• сигналы реального времени,
• средства синхронизации (семафоры, мьютексы и условные переменные);
• очереди сообщений,
• высокоточные таймеры,
• асинхронный ввод/вывод.

Операционная  система полностью соответствует  стандарту POSIX 1996 г. в части, относящейся  к реальному времени. Те части  стандарта, которые не относятся  к системам реального времени (традиционный UNIX) реализованы не полностью.

В рамках стандарта С 1990 г. реализованы математические функции (sin, exp, log и др.), функции обработки символов и строк, функции распределения памяти и др. Эти функции хорошо знакомы всем тем, кто разрабатывает программы на языке С. Они входят в состав таких хорошо известных средств разработки программ на языке С, как Borland C и Microsoft Development Studio C/C++.

При разработке средств обработки исключительных ситуаций с плавающей точкой использовался  стандарт IEEE 754, а также стандарт С 1999 г. Средства протоколирования в основном соответствуют стандарту POSIX 2001 г.

Для эмуляции протокола Ethernet в многопроцессорных системах, использующих шину VME, используется стандарт ANSI/VITA. Этот стандарт позволяет взаимодействовать через шину VME и общую память различным как по аппаратуре, так и по используемой операционной системе процессорным платам.

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

Отметим также, что использование стандартов облегчает освоение системы и  помогает при подготовке кадров программистов.

Мобильность

С целью  повышения мобильности операционная система разбита на три части:

• не зависящая от аппаратуры,
• зависящая только от типа центрального процессора,
• пакет поддержки модуля (поставляется отдельно).

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

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

Пакет поддержки модуля (ППМ) содержит ту часть ОС, которая зависит от конкретной ЭВМ (модуля). ППМ, в частности, содержит драйверы устройств и диспетчер  прерываний (за исключением пролога  и эпилога).

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

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

Архитектура программного обеспечения

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

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

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

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

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

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

Класс имеет описатель класса - структуру, которая содержит идентификатор  класса, функции обработки объектов класса (методы), а также общие  для всех объектов класса переменные. Каждый объект содержит указатель на описатель класса, к которому он относится.

Временные характеристики

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

• время ответа на прерывание,
• время ответа потока управления.

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

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

Задержка  планирования - это промежуток времени, когда планирование (переключения потоков управления) запрещено. Запрещение планирования является широко используемым методом взаимного исключения для защиты критических ресурсов. Для повышения скорости реакции системы важно, чтобы длительность задержки прерывания и задержки планирования была минимальна.

Время переключения контекста - это время, требующееся для того, чтобы одна задача прекратила свою работу, а другая начала.

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

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

2 Средства разработки

Для разработки прикладного программного обеспечения  используется комплекс, состоящий из двух ЭВМ, соединенных по сети:

• инструментальная ЭВМ (компьютер, с операционной системой типа UNIX),
• целевая ЭВМ (ЭВМ, для которой разрабатывается программное обеспечение).

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

Потоки  управления

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

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

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

Порождение  потоков

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

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

Завершение  потоков 

Поток может быть завершен по его собственной  инициативе (нормальное завершение) или  принудительно (функцией pthread_cancel() или посылкой сигнала). Нормальное завершение происходит в результате вызова функции pthread_exit() или возврата управления из функции, указанной при порождении потока.

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

Так как  потоки управления могут использовать общие ресурсы, то удаление потока в  произвольный момент времени может  помешать нормальной работе других потоков. Например, если удалить поток, добавляющий  элемент в двусвязный список, то список может остаться в состоянии  непригодном для дальнейшего  использования. Для решения подобного  рода проблем поток может запретить  или разрешить свое удаление. Если удаление запрещено, то запрос на удаление потока откладывается (запоминается) до тех пор, пока удаление не будет разрешено.

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

Состояния потоков

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

• ожидает освобождения ресурса,
• ожидает события,
• ожидает истечения интервала времени,
• приостановлен.

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

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

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

Поток может быть приостановлен отладочными  средствами, если он достиг точки останова, установленной отладчиком, или если при выполнении потока произошла  ошибка (например, деление на 0).

Планирование  потоков

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

В соответствии с POSIX операционная система позволяет  использовать следующие три стратегии  планирования:

С каждым потоком управления должна быть связана  соответствующая стратегия планирования и приоритет. Таким образом, в  рамках одной системы разные потоки управления могут использовать различные  стратегии планирования. Например, высокоприоритетные потоки могут использовать стратегию SCHED_FIFO, а низкоприоритетные - SCHED_RR.

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

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

При приоритетном планировании (SCHED_FIFO) поток выполняется  до тех пор, пока он не перестанет быть работоспособным или пока не появится более приоритетный работоспособный  поток.

Приоритетное  планирование с разделением времени (SCHED_RR) аналогично стратегии SCHED_FIFO с  дополнительным условием: если текущий  поток управления занимает процессор  в течение определенного периода  времени (кванта) или дольше, этот поток  сначала извлекается из очереди, а затем вновь устанавливается  в очередь (то есть становится последним  среди потоков с данным приоритетом). При этом ему выделяется новый  квант времени.

Смысл этой стратегии заключается в  том, чтобы запретить монопольное  использование процессора. Более  точно, поток управления со стратегией планирования SCHED_RR не может монопольно использовать процессор, если есть другие потоки с тем же приоритетом.

В настоящей  версии SCHED_OTHER совпадает с SCHED_RR.

Сигналы

Назначение  и основные сведения

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

• при обработке исключений (деление на 0, использование неверного адреса и др.);
• для сообщения об асинхронном событии (об окончании операции ввода/вывода, срабатывании таймера и др.);
• для организации взаимодействия потоков управления.

Сигналы могут генерироваться (посылаться прикладной программе) как операционной системой, так и прикладной программой.

В системе  имеется несколько видов сигналов. Каждому сигналу соответствует  уникальное положительное число (номер  сигнала). Кроме того, для сигналов определены имена.

Возможна  как асинхронная, так и синхронная обработка сигналов. В случае асинхронной  обработки при поступлении сигнала  выполнение потока управления приостанавливается и производится обработка сигнала. В этом случае говорят, что сигнал был доставлен. Говорят, что в промежутке времени между генерацией сигнала и его доставкой или приемом он задержан.

Асинхронная обработка сигналов может быть временно запрещена. Запрет обработки сигналов производится в рамках потока, а  не прикладной программы. Каждый поток  имеет свою собственную маску сигналов, обработка которых запрещена (заблокирована, замаскирована). Если сигнал пришел в тот момент, когда его обработка запрещена, факт прихода сигнала запоминается. В этом случае сигнал будет обработан, когда обработка сигналов будет вновь разрешена, если сигнал не будет ранее обработан синхронным образом.

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

Синхронная  обработка сигналов производится с  помощью функций sigwait(), sigwaitinfo() или sigtimedwait(). В этом случае поток приостанавливается до тех пор, пока не придет сигнал. Говорят, что сигнал был принят, если он был обработан синхронным образом.

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

Сигналы реализованы в соответствии с POSIX. При этом надо иметь в виду, что  в ОС реализованы только потоки управления, но не процессы (с точки зрения POSIX в системе имеется только один процесс). Доставка сигнала процессу трактуется как доставка сигнала  прикладной программе (без указания потока управления).

Сигналы можно разбить на две группы:

• обычные сигналы,
• сигналы реального времени.

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

В случае обычного сигнала функция обработки  сигнала получает только один аргумент - номер сигнала. В случае сигнала  реального времени имеется второй аргумент - значение связанное с сигналом (целое число или указатель). Значение сигнала указывается при порождении сигнала.

Порождение  сигналов

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

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

• завершение операции асинхронного ввода/вывода,
• поступление сообщения в пустую очередь,
• истечение интервала времени, связанного с программным таймером.

В этих случаях способ уведомления о  событии (реакции на событие) указывается  прикладной программой в структуре  sigevent. Возможны следующие способы уведомления о событии:

• послать сигнал,
• выполнить функцию уведомления в контексте специально созданного для этого потока,
• выполнить функцию уведомления в контексте потока или функции обработки прерываний, производящего уведомление,
• игнорировать событие (не производить уведомления).

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

Обработка сигналов

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

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