Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.1. Учебное пособие
.pdf
2.3. Состояния процесса
31
Тупики появляются тогда, когда два или более процесса владеют
каждый своим ресурсом, но ожидают освобождения другого ресурса, которым владеет “конкурент”.
Голодовка возникает тогда, когда один процесс монополизировал
процессор и никак не может его освободить.
Для устранения подобных проблем существуют различные механизмы, но общим в них является правило: никогда не допускается создание
задачи, если ресурсов для выполнения недостаточно. Проблемой может
здесь являться только ситуация, когда учтенный при создании процессов
ресурс вдруг становится недоступным.
2.3. Состояния процесса
Сейчас все задачи и процессы делятся на три основные группы.
1. Процессы, которые решают поставленные задачи и у них есть все
необходимые активные и пассивные ресурсы и доступ к процессору.
2. Процессы, которые готовы к выполнению и у них есть все ре-
сурсы, но им не выделено процессорное время. Такие процессы называются “кандидатами” на выполнение. Они находятся в режиме ожидания.
3. Неактивные процессы, которым не хватило ресурсов, даже пас-
сивных. Как правило, таким процессам вообще не будет выделено процессорное время.
В любом случае, над процессами могут проводиться следующие операции со стороны операционной системы.
1. Создание процесса – переход из состояния “рождения” в состоя-
ние готовности.
2. Уничтожение процесса – переход из состояния ожидания или вы-
полнение в состояние “смерти”.
3. Восстановление процесса – переход из состояния готовности в
состояние выполнения.
4. Блокировка процесса – переход из состояния выполнения в со-
стояние ожидания.
5. Пробуждение процесса – переход из состояния ожидания в со-
стояние готовности.
2. Основные положения
32
6. Запуск процесса – переход из состояния готовности в состояние
выполнения.
Также следует отметить, что процессы не возникают “из ниоткуда”. Всегда существует “родительский” процесс, который создал текущий процесс.
Запущенный или созданный процесс называется “дочерним” (child)
процессом или потомком. Процесс, который породил этот процесс, называется “родителем” или “предком” (parent).
У любого процесса есть минимум два собственных идентификатора:
идентификатор процесса – PID (Process ID).
идентификатор родительского процесса – PPID (Parent Process ID).
На рис. 2 (а, б) ниже показана часть процессов операционной системы с указанными идентификаторами и другими метриками.
а
Рис. 2. Пример таблицы процессов ОС:
а – левая часть дампа; б – правая часть дампа
2.3. Состояния процесса
33
б
Рис. 2. Окончание
Под потоками (нитями) будем понимать “облегченную” разновид-
ность процесса. Процессы, пришедшие во все операционные системы из
“мира” UNIX-систем, плохо реализуются в многозадачной среде, так как
они имеют тяжеловесный контекст и требуют полного переключения. Новая концепция легковесных процессов (потоков), воспринимаемых как
“подпроцессы”, помогает реализовывать многозадачность, так как поток
или нить выполняется в рамках и в контексте полновесного процесса.
С помощью потоков также можно реализовывать концепцию парал-
лельного выполнения программ. Кроме того, сейчас большинство программ являются многопоточными, а большинство современных языков
программирования имеют встроенные модули и функции для создания и
2. Основные положения
34
управления потоками. Причем потоки могут быть как именованными (полноценными), так и анонимными, которые “погибают”, как только выполнят
свою функцию, параллельно с остальной программой.
Каждая операционная система имеет свой механизм формирования
потоков. Для UNIX-подобных систем это механизм “форков” (fork), для
других “выполнений” (exec). Это необходимо учитывать при разработке
кроссплатформенных приложений.
В любом случае есть два основных требования к потокам:
поток, выполняемый в контексте процесса, имеет возможность
доступа к определенным ресурсам. Он расположен в виртуальном адресном пространстве процесса. Кроме того, поток может иметь доступ к ресурсам за пределами процесса, с определенными ограничениями;
поток также подвержен диспетчеризации и, как следствие, изме-
нениям порядка выполнения.
Владельцу ресурса (процесса, задачи) принадлежат: адресное пространство, отдельный доступ к микропроцессору, доступ к другим процессам, файлам и ресурсам ввода-вывода.
Модулю диспетчеризации подчиняются: состояния выполнения потока и процесса, механизмы сохранения и загрузки контекста задачи, инструменты управления стеком и статической памятью для хранения переменных, ресурсы памяти и ресурсы самого процесса.
Все потоки в той или иной мере разделяют общие ресурсы. При этом
изменения, вносимые одним потоком, становятся доступны другим потокам.
Преимущества потоков перед процессами следующие.
1. Потоки более легковесные и все используют адресное простран-
ство порождающего процесса, для них требуется меньше времени на переключение.
2. Требуется меньше времени для завершения потока.
3. В пределах одного процесса коммуникационные расходы мини-
мальны, так как ресурсы делятся и данные, продуцируемые одним потоком,
сразу же становятся известны другим потокам.
Операционная система реального времени, реализующая концепцию многопоточности, имеет следующие определенные преимущества.
1. В такой системе реакция или “отклик” приложений гораздо лучше,
чем у других систем. Сложные приложения всегда проектируются так, чтобы
2.4. Стандарты на операционные системы реального времени
35
часть задач выполнялась в фоне, т.е. в виде параллельных потоков. Например, хорошим тоном является разделение бизнес-логики приложения и алгоритмов отрисовки интерфейса пользователя таким образом, чтобы логика,
получение данных по сети, математические расчеты и сложные вычисления
происходили в своих потоках, отдельно от графики. Пользователю не нужно
ожидать завершения работы фонового процесса – данные “сами” появятся на
графических элементах и “зависаний интерфейса” не будет.
2. Подобные ОС более эффективно используют возможности мно-
гопроцессорных систем. Производительность приложения может равномерно увеличиваться с ростом числа доступных ядер и процессоров благодаря так называемому “горизонтальному масштабированию”, когда вычислительные алгоритмы в фоне занимают свободные ресурсы. Этот эффект
становится более явным, если реализуемые программой алгоритмы хорошо
распараллеливаются. Примером таких алгоритмов являются операции над
матрицами.
3. Программы для ОС с многопоточностью имеют более высокое ка-
чество и лучшую структуризацию сразу на этапе проектирования. Это обусловлено тем, что программа разрабатывается сразу с учетом многопоточности, т.е. она представляется в виде набора нескольких слабозависимых алгоритмических и программных единиц и уже не является монолитной.
4. ОС с поддержкой многопоточности более эффективно расхо-
дуют ресурсы. Этот эффект вызван тем, что программы, использующие более одного процесса, имеют доступ к общим данным посредством разделяемой памяти и содержат более одного потока управления. При этом каждый поток видит полное адресное пространство и множество состояний в
операционной системе.
2.4. Стандарты на операционные системы реального времени
Так как операционные системы – это такой же промышленный про-
дукт, как автомобиль, на них распространяется действие определенных
стандартов. Долгое время единственным стандартом был легендарный
POSIX (IEEE Portable Operating System Interface for Computer
Environments, IEEE 1003.1/). Первый вариант стандарта появился еще в
2. Основные положения
36
1990 г. и распространялся на произведенные, начиная с 1970 г., операционные системы различного вида. Спецификация POSIX распространяется
на механизмы взаимодействия прикладных программ и ядра операционной системы. Стандарт POSIX является собирательным и включает в себя
более чем 30 документов.
Для коммерческих систем наиболее распространены следующие три
стандарта:
1003.1a;
1003.1b;
1003.1c.
Следует упомянуть, что начиная с 90-х гг. особого продвижения в
стандартах ОС РВ не наблюдается. Возможно, это вызвано тем, что компьютерная техника развивается скорее по пути увеличения мощности и степени интеграции, а научного прорыва и революционных технологий пока
не наблюдается.
POSIX разработан в Америке, а в Европе существуют свои варианты
стандартов, например, DO-178B или OSEK/VDX [OSEK].
На рис. 3 приведена структура системы стандартов POSIX.
POSIX был задуман как интерфейс между сервисами операционных
систем, позволяющий создавать переносимые приложения. Сейчас POSIX
является целым семейством стандартов с собирательным номером IEEE Std
1003.n.
Что касается этого стандарта, наиболее важные его части охватывают следующие особенности операционных систем реального времени.
Рассмотрим некоторые из них в рамках 1003.1b:
Блокирование виртуальной памяти (1003.1b). Включено в стандарт
вследствие широкого распространения виртуальной памяти в UNIXсистемах. Раздел стандарта описывает механизмы работы программ, напрямую не относящихся к реальному времени. Это в основном функции фиксации или, другими словами, блокировки в памяти общего адресного пространства процесса или отдельных его областей. Эти функции в основном
используются в работе процессов, для которых критично время работы.
Четкое соблюдение рекомендаций стандарта помогает сделать процессы
более предсказуемыми.
2.4. Стандарты на операционные системы реального времени
37
Рис. 3. Стандарты POSIX
Синхронизация процессов (1003.1b). Является подразделом упомя-
нутого выше стандарта. В нем объясняются принципы использования семафоров-счетчиков для синхронизации процессов. Вся суть подхода заключается в том, что стандарт задает некоторое определенное пространство имен процессов, имена которых являются производными. Следует отметить, что это пространство имен может совпадать с пространством имен
файлов, но это не обязательно. Семафоры-счетчики здесь – это обобщенное
понятие для элементов механизма синхронизации, контролирующего взаимоисключающий доступ к разделяемым ресурсам, а также формирование и
обработку сигналов этой синхронизации.
Разделяемая память (1003.1b). Данный раздел стандарта описывает
методы работы с разделяемой памятью, которые особенно важны в том
2. Основные положения
38
случае, когда процессы делят между собой части физической памяти. Это
происходит чаще всего с приложениями реального времени, которым требуется обработать большие объемы данных.
Сигналы реального времени (1003.1b). События в ОС РВ не теряются потому, что, согласно этой части стандарта, они помещаются в очередь, как и задачи. Номер сигнала в очереди также служит индикатором
приоритета. Необработанные задачи извлекаются из очереди и отправляются на выполнение. Сигналы реального времени содержат дополнительное поле с данными. Оно служит для передачи информации между генератором сигнала и его обработчиком. Кроме всего прочего, это поле может
использоваться и для идентификации сигнала в очереди.
Взаимодействие процессом (1003.1b). Каждое сообщение имеет дополнительное поле приоритета, также принадлежащее пространству имен,
определяемое стандартом. Передача сигналов и сообщений, а также их обработка может блокироваться и разрешаться вновь. При этом передача и
получение сообщений никак особо не синхронизируются. Это значит, что
отправитель сообщения не ждет, когда оно будет взято из очереди и обработано. Следует упомянуть, что очереди сообщений часто используются и
на прикладном уровне, внутри программных комплексов, части которых
имеют слабую связь.
Таймеры (1003.1b). Синхронизация и очередность событий в системе реализуется при помощи таймеров и счетчиков. При этом таймеры
могут быть не только аппаратные, но и программные. В этом случае система должна обеспечивать действительно “реальное” время работы, чтобы
периоды таймера были равной величины. Таймеры могут работать в различных режимах. Например, наследуется принцип работы старых таймеров
микропроцессорного комплекта i8086: генератор и делитель частоты, единичного импульса, меандра.
Асинхронный ввод-вывод (1003.1b). Стандарт определяет работу
процессов ввода-вывода вместе с прикладными задачами. Ввод и вывод
данных обычно являются асинхронными операциями и инициируются данными приложения. Когда операция завершается, может генерироваться дополнительный сигнал, который также может начинать другие события.
В сравнении с рассмотренным выше стандартом, европейский аналог DO-178B создан Радиотехнической комиссией по аэронавтике (RTCA,
2.5. Основные требования к операционным системам реального времени
39
Radio Technical Commission for Aeronautics). Изначально он использовался
для бортовых систем авиации. В большей степени этот стандарт ориентирован на сохранение уровня безопасности систем, поэтому он сейчас используется, например, для стандартизации уровней отказов ОС и прикладного программного обеспечения.
Он включает пять уровней безопасности и требует соблюдения норм
каждого пункта: катастрофический (А), опасный (В), существенный (С),
несущественный (D) и не влияющий (Е).
Другим дополнительным стандартом для POSIX является стандарт
ARINC-653, разработанный компанией ADINC в 1997 г. Он регламентирует универсальный программный интерфейс APEX между операционной
системой и прикладным программным обеспечением. В стандарте подразумевается, что прикладное программное обеспечение может осуществлять
контроль диспетчеризации, связывание и изменение состояния внутренних
элементов.
Стандарт APEX обновился в 2003 г. и стал включать в себя обнов-
ленную архитектуру изолированных виртуальных машин.
Существует стандарт OSEK/VDX, являющийся собирательным. Он
родился в отрасли автомобилестроения среди компаний BMW, Bosch,
Daimler Benz, Opel, Siemens, и Volkswagen, Renault, а также нескольких институтов. Первоначально стандарт предназначался для построения программных интерфейсов API. Он получился настолько обширным и абстрактным, что вышел за рамки автомобильной отрасли. Состоит из четырех основных частей: стандарт операционной системы, коммуникационный стандарт, стандарт сетевого менеджера, а также специальный описательный язык для реализации стандарта.
2.5. Основные требования к операционным
системам реального времени
Исходя из приведенного выше материала, можно сформировать
следующие основные требования для операционной системы реального
времени.
1. ОС РВ должна быть многозадачной, т.е. реализовывать концеп-
цию многопоточности и обрабатывать прерывания.
2. Основные положения
40
2. ОС РВ должна быть предсказуемой, т.е. для любого штатного про-
цесса должно быть определено максимальное время реакции на событие и
максимальное время, за которое эта реакция должна быть реализована.
3. ОС РВ должна иметь планировщик задач. Планировщик должен
иметь возможность создать любой процесс, направить на выполнение и
прервать его.
4. ОС РВ должна реализовывать концепцию потоков и приорите-
тов. Любой активный элемент системы должен иметь приоритет.
5. ОС РВ должна иметь механизм выделения, распределения и кон-
троля ресурсов. В идеале ОС отдает ресурс согласно требованиям потребителя и его приоритетом, а также определяет крайний срок его использования. Для этого в ОС должны быть четко определены и заранее известны
временные интервалы выполнения различных действий программ. На самом деле это практически невозможно, поэтому данный принцип действует
с ограничениями. Для каждой задачи вводится понятие уровня приоритета,
и временные ограничения затем сводятся к управлению приоритетами.
Управление реализуется через расписание, методы случайного доступа и
имитационное моделирование.
6. ОС РВ должна поддерживать механизмы синхронизации. Задачи
должны общаться друг с другом, если они разделяют какие-либо ресурсы.
7. ОС РВ должна поддерживать механизмы наследования приори-
тетов. Здесь имеется в виду повышение приоритета до уровня вызывающего потока. Наследование означает, что блокирующая ресурс нить наследует приоритет блокируемой нити (справедливо лишь в том случае, если
блокируемая нить имеет более высокий приоритет).
8. ОС РВ должна иметь директивный, т.е. определенный срок вы-
полнения задачи. Этот срок называется “дэдлайн” (deadline). Еще раз
напомним, что выполнение любой задачи должно занимать не более определенного временного интервала.
9. ОС РВ должна иметь регулированный разброс значений, называ-
емый “джиттером” (jitter). В среднем, по статистике, этот разброс сходится
к одному значению. В хорошей системе джиттер стандартизирован и минимален.
10. ОС РВ должна иметь определенную латентность (latency). Это за-
держка системы. Значение латентности должно быть минимальным. К минимизации этой величины сводится процесс оптимизации ОС.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]