![](/user_photo/1334_ivfwg.png)
- •2. Ядра и операционные системы реального времени
- •2.1. Задачи, процессы, потоки
- •2.2. Основные свойства задач
- •2.3. Планирование задач
- •2.4. Синхронизация задач
- •2.5. Тестирование
- •2.6. Можно ли обойтись без ОС РВ?
- •3. Обзор некоторых операционных систем реального времени
- •3.1. Linux реального времени
- •3.2. Операционные системы реального времени и Windows
- •3.3. Операционная система QNX
- •3.4. Проект Neutrino
- •4.1. Организация промышленных систем
- •4.2. Аппаратная архитектура
- •4.3. Стандарты шин
- •4.4. Технологии VME и PCI
- •4.5. Мезонинные технологии
- •4.6. Полевые системы
- •4.7. Программное обеспечение промышленных систем
- •4.8. Управление производством
- •Часть 2. ПРОЕКТИРОВАНИЕ СРВ
- •5. UML проектирование систем реального времени
- •5.1. Объектно-ориентированные методы и UML
- •5.2. Метод и нотация
- •5.3. Системы и приложения реального времени
- •6. Обзор нотации UML
- •6.1. Диаграммы UML
- •6.2. Диаграммы прецедентов
- •6.3. Нотация UML для классов и объектов
- •6.4. Диаграммы классов
- •6.5. Диаграммы взаимодействия
- •6.6. Диаграммы состояний
- •6.7. Пакеты
- •6.8. Диаграммы параллельной кооперации
- •6.9. Диаграммы развертывания
- •6.10. Механизмы расширения UML
- •7.1. Среды для параллельной обработки
- •7.2. Поддержка исполнения в мультипрограммной и мультипроцессорной средах
- •7.3. Планирование задач
- •7.4. Вопросы ввода/вывода в операционной системе
- •7.6. Технология World Wide Web
- •7.7. Сервисы распределенных операционных систем
- •7.8. ПО промежуточного слоя
- •7.9. Стандарт CORBA
- •7.10. Другие компонентные технологии
- •7.11. Системы обработки транзакций
- •8. Разбиение на задачи
- •8.1. Вопросы разбиения на параллельные задачи
- •8.2. Категории критериев разбиения на задачи
- •8.3. Критерии выделения задач ввода/вывода
- •8.4. Критерии выделения внутренних задач
- •8.5. Критерии назначения приоритетов задачам
- •8.6. Критерии группировки задач
- •8.7. Пересмотр проекта путем инверсии задач
- •8.8. Разработка архитектуры задач
- •8.9. Коммуникации между задачами и синхронизация
- •8.10. Спецификация поведения задачи
- •9. Проектирование классов
- •9.1. Проектирование классов, скрывающих информацию
- •9.2. Проектирование операций классов
- •9.3. Классы абстрагирования данных
- •9.4. Классы интерфейса устройства
- •9.5. Классы, зависящие от состояния
- •9.6. Классы, скрывающие алгоритмы
- •9.7. Классы интерфейса пользователя
- •9.10. Внутренние программные классы
- •9.11. Применение наследования при проектировании
- •9.12. Примеры наследования
- •9.13. Спецификация интерфейса класса
- •10. Детальное проектирование ПО
- •10.1. Проектирование составных задач
- •10.2. Синхронизация доступа к классам
- •10.4. Логика упорядочения событий
- •11.1. Теория планирования в реальном времени
- •11.2. Развитие теории планирования в реальном времени
- •11.5. Пример анализа производительности с помощью анализа последовательности событий
- •11.6. Пример анализа производительности с применением теории планирования в реальном времени
- •11.8. Пересмотр проекта
- •11.9. Оценка и измерение параметров производительности
- •12. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
Министерство образования и науки Российской Федерации
УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Кафедра автоматизированных систем управления
А.М.СУЛЕЙМАНОВА
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ
Учебное пособие
Уфа 2004
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
2 |
Составитель А.М. Сулейманова УДК 004.415.2 ББК 32.973.26-018.1
Сулейманова А.М. Системы реального времени: учебное посо- бие/ Уфимск. гос. авиац. техн. ун-т.– Уфа, 2004.– 292 с.
Учебное пособие состоит из двух частей. В первой части даны определения систем реального времени, рассматриваются вопросы функционирования в реальном масштабе времени. Приведены обзор
исравнительный анализ некоторых операционных систем реального времени. Описаны современные индустриальные системы реального времени. Во второй части описан процесс создания систем реального времени с точки зрения проектирования архитектуры системы. Под- робно рассмотрены ключевые вопросы, возникающие в процессе раз- работки: управление временем отклика, синхронизация, актуальность
инепротиворечивость данных. На примерах показано как с помощью одной и той же универсальной нотации UML, можно описать такие далекие друг от друга области, как, например, автоматизированная банковская система и бортовой компьютер автомобиля – без привяз- ки к какой либо программной или аппаратной платформе.
Предназначено для студентов специальностей «Автоматизиро- ванные системы обработки информации и управления» и «Приклад- ная информатика в экономике».
Библиогр.: 29 назв.
Научный редактор: канд.техн.наук, доцент М.Я.Парфенова
Рецензенты: канд.техн.наук, доцент, заведующая кафедрой Информатики БАГСУ С.М.Ибатуллина Канд.техн.наук, доцент, заместитель заведующего кафедрой Управления в ОВД В.А.Пестриков
©Уфимский государственный авиационный технический университет, 2004
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A3x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
3 |
Часть 1. СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ. |
|
ОПРЕДЕЛЕНИЯ. ОБЗОР. ОПЕРАЦИОННЫЕ |
|
СИСТЕМЫ ................................................................. |
7 |
1. Что такое функционирование в «Реальном |
|
масштабе времени»........................................ |
7 |
2. Ядра и операционные системы реального |
|
времени......................................................... |
12 |
2.1. Задачи, процессы, потоки ............................. |
14 |
2.2. Основные свойства задач .............................. |
15 |
2.3. Планирование задач ..................................... |
17 |
2.4. Синхронизация задач.................................... |
21 |
2.5. Тестирование ............................................... |
29 |
2.6. Можно ли обойтись без ОС РВ? ...................... |
30 |
3. Обзор некоторых операционных систем |
|
реального времени....................................... |
35 |
3.1. Linux реального времени ............................... |
36 |
3.2. Операционные системы реального времени |
|
и Windows .................................................. |
41 |
3.3. Операционная система QNX........................... |
52 |
3.4. Проект Neutrino ........................................... |
57 |
4. Современные индустриальные системы, |
|
функционирующие в режиме реального |
|
времени......................................................... |
76 |
4.1. Организация промышленных систем .............. |
76 |
4.2. Аппаратная архитектура ............................... |
78 |
4.3. Стандарты шин............................................. |
79 |
4.4. Технологии VME и PCI ................................... |
79 |
4.5. Мезонинные технологии................................ |
82 |
4.6. Полевые системы.......................................... |
83 |
4.7. Программное обеспечение промышленных |
|
систем........................................................ |
85 |
4.8. Управление производством............................ |
91 |
Часть 2. ПРОЕКТИРОВАНИЕ СРВ........................... |
93 |
5. UML проектирование систем реального |
|
времени......................................................... |
93 |
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A4x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
4 |
5.1. Объектно-ориентированные методы и UML ..... |
94 |
5.2. Метод и нотация ........................................... |
95 |
5.3. Системы и приложения реального времени..... |
96 |
6. Обзор нотации UML......................................... |
99 |
6.1. Диаграммы UML ............................................ |
99 |
6.2. Диаграммы прецедентов................................ |
99 |
6.3. Нотация UML для классов и объектов ........... |
100 |
6.4. Диаграммы классов..................................... |
101 |
6.5. Диаграммы взаимодействия......................... |
103 |
6.6. Диаграммы состояний ................................. |
104 |
6.7. Пакеты....................................................... |
106 |
6.8. Диаграммы параллельной кооперации ......... |
106 |
6.9. Диаграммы развертывания .......................... |
107 |
6.10. Механизмы расширения UML...................... |
109 |
7. Технологии параллельных и |
|
распределенных систем ............................. |
111 |
7.1. Среды для параллельной обработки............. |
111 |
7.2. Поддержка исполнения в |
|
мультипрограммной и мультипроцессорной |
|
средах...................................................... |
113 |
7.3. Планирование задач ................................... |
117 |
7.4. Вопросы ввода/вывода в операционной |
|
системе .................................................... |
120 |
7.5. Технологии клиент-серверных и |
|
распределенных систем............................. |
123 |
7.6. Технология World Wide Web......................... |
128 |
7.7. Сервисы распределенных операционных |
|
систем...................................................... |
130 |
7.8. ПО промежуточного слоя............................. |
133 |
7.9. Стандарт CORBA ......................................... |
137 |
7.10. Другие компонентные технологии .............. |
140 |
7.11. Системы обработки транзакций.................. |
142 |
8. Разбиение на задачи .................................... |
145 |
8.1. Вопросы разбиения на параллельные |
|
задачи...................................................... |
145 |
8.2. Категории критериев разбиения на задачи... |
146 |
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A5x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
5 |
8.3. Критерии выделения задач ввода/вывода .... |
147 |
8.4. Критерии выделения внутренних задач........ |
156 |
8.5. Критерии назначения приоритетов задачам.. |
163 |
8.6. Критерии группировки задач ....................... |
165 |
8.7. Пересмотр проекта путем инверсии задач .... |
177 |
8.8. Разработка архитектуры задач .................... |
181 |
8.9. Коммуникации между задачами и |
|
синхронизация.......................................... |
184 |
8.10. Спецификация поведения задачи............... |
194 |
9. Проектирование классов.............................. |
197 |
9.1. Проектирование классов, скрывающих |
|
информацию............................................. |
197 |
9.2. Проектирование операций классов .............. |
198 |
9.3. Классы абстрагирования данных ................. |
202 |
9.4. Классы интерфейса устройства.................... |
205 |
9.5. Классы, зависящие от состояния.................. |
210 |
9.6. Классы, скрывающие алгоритмы.................. |
213 |
9.7. Классы интерфейса пользователя ................ |
214 |
9.8. Классы бизнес-логики................................. |
216 |
9.9. Классы-обертки базы данных ...................... |
218 |
9.10. Внутренние программные классы ............... |
220 |
9.11. Применение наследования при |
|
проектировании........................................ |
220 |
9.12. Примеры наследования ............................. |
222 |
9.13. Спецификация интерфейса класса ............. |
228 |
10. Детальное проектирование ПО .................. |
231 |
10.1. Проектирование составных задач............... |
231 |
10.2. Синхронизация доступа к классам.............. |
239 |
10.3. Проектирование разъемов для |
|
межзадачных коммуникаций...................... |
250 |
10.4. Логика упорядочения событий ................... |
256 |
11. Анализ производительности проекта |
|
параллельной системы............................... |
258 |
11.1.Теория планирования в реальном времени . 258
11.2.Развитие теории планирования в реальном
времени ................................................... |
268 |
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
6 |
11.3. Анализ производительности с помощью анализа последовательности событий ........ 274
11.4.Анализ производительности с помощью теории планирования в реальном времени
и анализа последовательности событий...... |
275 |
11.5.Пример анализа производительности с помощью анализа последовательности
событий.................................................... |
276 |
11.6.Пример анализа производительности с применением теории планирования в
реальном времени..................................... |
281 |
11.7.Анализ производительности по теории планирования в реальном времени и
анализа последовательности событий ........ |
284 |
11.8. Пересмотр проекта.................................... |
293 |
11.9. Оценка и измерение параметров |
|
производительности.................................. |
294 |
12. ЗАКЛЮЧЕНИЕ.............................................. |
296 |
СПИСОК ЛИТЕРАТУРЫ ......................................... |
297 |
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A7x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
7 |
Часть 1. СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ. ОПРЕДЕЛЕНИЯ. ОБЗОР. ОПЕРАЦИОННЫЕ СИСТЕМЫ
1. Что такое функционирование в «Реальном масштабе времени»
Внастоящее время в документах и публикациях с различной те- матикой встречаются слова о требовании, поддержке и т.д. «работы в режиме реального времени», «режима реального времени» или про- сто «реального времени». Что же такое «режим реального времени» применительно к компьютерным системам? Постараемся представить различные современные точки зрения на это понятие.
Толковый словарь по вычислительным системам [7], дает такое определение (стр. 399):
R.052 real-time system система реального времени (СРВ)
Любая система, в которой существенную роль играет время ге- нерации выходного сигнала. Это обычно связано с тем, что входной сигнал соответствует каким-то изменениям в физическом процессе, и выходной сигнал должен быть связан с этими же изменениями. Вре- менная задержка от получения входного сигнала до выдачи выходно- го сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции. Время реакции является системной характеристикой:
при управлении ракетой требуется реакция в течении нескольких миллисекунд, тогда как для диспетчерского управления движением пароходов требуется время реакции, измеряемое днями. Системы обычно считаются системами реального времени, если время их ре- акции имеет порядок миллисекунд; диалоговыми считаются системы
свременем реакции порядка нескольких секунд, а в системах пакет- ной обработки время реакции измеряется часами или днями. Приме- рами систем реального времени являются системы управления физи- ческими процессами с применением вычислительных машин, систе- мы торговых автоматов, автоматизированные системы контроля и ав- томатизированные испытательные комплексы.
Втолковом словаре по информатике [8] дается такое определе- ние (стр. 335): Режим реального времени [real time processing]. Режим
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
8 |
обработки данных, при котором обеспечивается взаимодействие вы-
числительной системы с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов.
Каноническое определение системы реального времени дано Дональдом Гиллиесом и выглядит так:
«Системой реального времени является такая система, коррект- ность функционирования которой определяется не только корректно- стью выполнения вычислений, но и временем, в которое получен тре- буемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы». Другие добавляют: «По- этому необходимо, чтобы было гарантировано [аппаратными и про- граммными средствами и алгоритмами обработки] выполнение тре- бований по времени. Гарантия выполнения требований по времени необходима, чтобы поведение системы было предсказуемо. Также желательно, чтобы система обеспечивала высокую степень использо- вания ресурсов, чтобы удовлетворять требованиям по времени [с ми- нимальными затратами]».
Хорошим примером является робот, который должен брать что- либо с ленты конвейера. Объекты на конвейере движутся, и робот имеет некоторый небольшой интервал времени для того, чтобы схва- тить объект. Если робот опоздает, то объекта уже не будет на месте, и поэтому работа будет неверной, даже если робот переместил захват в правильное положение. Если робот поспешит, то объекта там еще не будет, более того, робот может заблокировать движение объектов.
Другой пример – цикл управления самолетом, летящим на авто- пилоте. Датчики самолета должны постоянно передавать измеренные данные в управляющий компьютер. Если данные измерений теряют- ся, то качество управления самолетом падает, возможно вместе с са- молетом.
Отметим следующую особенность: в примере с роботом и имеем настоящий, «жесткий» режим реального времени (hard real time), и если робот опоздает, то это приведет к полностью ошибочной опера- ции. Однако это мог бы быть режим «квазиреального» времени (soft real time), если бы опоздание робота приводило бы только к потере производительности. Многое из того, что сделано в области про- граммирования в реальном времени, в действительности работает в режиме «квазиреального» времени. Грамотно разработанные систе- мы, как правило, имеют уровень безопасности/коррекции поведения
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
9 |
даже для случая, когда вычисления не закончились в необходимый момент, так что если компьютер чуть-чуть не успевает, то это может быть скомпенсировано.
Бывает, что термин «система реального времени» применяют в значении «интерактивная система» (on-line). Часто это просто рек- ламный ход. Например, системы заказа билетов или системы склад- ского учета не являются системами «реального времени», так как че- ловек-оператор без проблем перенесет задержку ответа на несколько сотен миллисекунд.
Также можно встретить случаи, когда термин «система реально- го времени» применяют просто в значении «быстродействующая сис- тема». Необходимо отметить, что определение «реального времени» не является синонимом для определения «быстродействующая». Еще раз: термин «система реального времени» не означает, что система дает ответ на воздействие мгновенно – задержка может достигать се- кунд и более – но означает тот факт, что гарантируется некоторая максимально возможная величина задержки ответа, что позволяет системе решать поставленную задачу. Необходимо также отметить, что алгоритмы, обеспечивающие гарантированное время ответа, час- то имеют меньшую среднюю производительность, чем алгоритмы, которые не гарантируют время ответа.
Из приведенного выше можно сделать выводы:
–термин «система реального времени» в настоящее время мо- жет быть записан так: “Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в ко- торое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы”.
Для того чтобы система могла удовлетворить требованиям, предъявляемым к системам реального времени, аппаратные, про- граммные средства и алгоритмы работы системы должны гарантиро- вать заданные временные параметры реакции системы. Время реак- ции не обязательно должно быть очень маленьким, но оно должно быть гарантированным (и отвечающим поставленным требованиям);
–использование термина «система реального времени», опреде- ленного выше, для обозначения интерактивных и высокопроизводи- тельных систем неверно;
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
10 |
–термин «квазиреальное время» (soft real-time) хотя и использу- ется, но четко не определен. До его четкого определения вряд ли воз- можно его применение в документах (кроме рекламных). С уверен- ностью можно сказать, что смысл термина «реальное время» тракту- ется специалистами по-разному в зависимости от области их профес- сиональных интересов, от того, являются они теоретиками или прак- тиками, и даже просто отличного опыта и круга общения.
–практически все системы промышленной автоматизации явля- ются системами реального времени.
–принадлежность системы к классу систем реального времени никак не связана с ее быстродействием. Например, если ваша система предназначена для контроля уровня грунтовых вод, то даже выполняя измерения с периодичностью один раз за полчаса, она будет работать
вреальном времени.
Исходные требования к времени реакции системы и другим временным параметрам определяются или техническим заданием на систему, или просто логикой ее функционирования. Например, шах- матная программа, думающая над каждым ходом более года, работает явно не в реальном времени, так как шахматист скорее всего не до- живет до конца партии. Однако точное определение «приемлемого времени реакции» не всегда является простой задачей, а в системах, где одним из звеньев служит человек, подвержено влиянию субъек- тивных факторов. Впрочем, человек – это своеобразная вычислитель- ная машина.
Интуитивно понятно, что быстродействие системы реального времени должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы оценить необхо- димое быстродействие для систем, имеющих дело со стационарными процессами, часто используют теорему Котельникова [6], из которой следует, что частота дискретизации сигналов должна быть как мини- мум в 2 раза выше граничной частоты их спектра.
При работе с широкополосными по своей природе переходными процессами (транзиент-анализ) часто применяют быстродействую- щие АЦП с буферной памятью, куда с необходимой скоростью запи- сывается реализация сигнала, которая затем анализируется и/или ре- гистрируется вычислительной системой. При этом требуется закон- чить всю необходимую обработку до следующего переходного про-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
11 |
цесса, иначе информация будет потеряна. Подобные системы иногда называют системами квази-реального времени.
Принято различать системы «жесткого» и «мягкого» реального времени. Эти различия не связаны с органолептическими свойствами систем. Тогда что же это такое?
1.Системой «жесткого» реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в за- данное время является отказом и ведет к невозможности решения по- ставленной задачи.
Последствия таких отказов могут быть разные, от пролива дра-
гоценной влаги на линии по розливу алкогольных напитков до более крупных неприятностей, если, например, вовремя не сработала сис- тема аварийных блокировок атомного реактора.
Многие теоретики ставят здесь точку, из чего следует, что время реакции в «жестких» системах может составлять и секунды, и часы, и недели. Однако большинство практиков считают, что время реакции
всистемах «жесткого» реального времени должно быть все-таки ми- нимальным. Идя на поводу у практиков, так и будем считать. Разуме- ется, однозначного мнения о том, какое время реакции свойственно «жестким» системам, нет. Более того, с увеличением быстродействия микропроцессоров это время имеет тенденцию к уменьшению, и если раньше в качестве границы называлось значение 1 мс, то сейчас, как правило, называется время порядка 100 мкс.
2.Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда относятся все системы реального времени, не попадающие в категорию «жестких».
Так как система «мягкого» реального времени может не успе- вать все делать ВСЕГДА в заданное время, возникает проблема опре- деления критериев успешности (нормальности) ее функционирова- ния. Вопрос этот совсем не простой, так как в зависимости от функ-
ций системы это может быть максимальная задержка в выполнении каких-либо операций, средняя своевременность отработки событий и т. п. Более того, эти критерии влияют на то, какой алгоритм планиро- вания задач является оптимальным. Вообще говоря, системы «мягко- го» реального времени проработаны теоретически далеко не до кон- ца.
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A12x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
12 |
2. Ядра и операционные системы реального времени
Примем как очевидные следующие моменты.
1.Когда-то операционных систем совсем не было.
2.Через некоторое время после их появления возникло направ- ление ОС РВ.
3.Все ОС РВ являются многозадачными операционными систе- мами. Задачи делят между собой ресурсы вычислительной системы, в том числе и процессорное время.
Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возмож- ностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуника- ция, управление памятью и т.п. Операционные системы в дополнение
кэтому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.
По своей внутренней архитектуре ОС РВ можно условно разде- лить на монолитные ОС, ОС на основе микроядра и объектно- ориентированные ОС. Графически различия в этих подходах иллюст- рируются рисунками 2.1, 2.2, 2.3. Преимущества и недостатки раз- личных архитектур достаточно очевидны, поэтому подробно мы на них останавливаться не будем.
Рис. 2.1. ОС РВ с монолитной архитектурой
www.pdffactory.com
![](/html/1334/288/html_m6nYKfMCGV.keWm/htmlconvd-lXqC2A13x1.jpg)
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
13 |
Рис.2.2. ОС РВ на основе микроядра
Рис. 2.3. Объектно-ориентированная ОС РВ
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
14 |
2.1. Задачи, процессы, потоки
Существуют различные определения термина «задача» для мно- гозадачной ОС РВ. Мы будем считать задачей набор операций (ма- шинных инструкций), предназначенный для выполнения логически законченной функции системы. При этом задача конкурирует с дру-
гими задачами за получение контроля над ресурсами вычислительной системы.
Принято различать две разновидности задач: процессы и потоки.
Процесс представляет собой отдельно загружаемый программный модуль (файл), который, как правило, во время исполнения имеет в памяти свои независимые области для кода и данных. В отличие от
этого потоки могут пользоваться общими участками кода и данных в рамках единого программного модуля.
Хорошим примером многопоточной программы является редак- тор текста WORD, где в рамках одного приложения может одновре- менно происходить и набор текста, и проверки правописания.
Преимущества потоков.
1. Так как множество потоков способно размещаться внутри од- ного EXE-модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти.
2. Использование потоками общей области памяти позволяет эффективно организовать межзадачный обмен сообщениями (доста- точно передать указатель на сообщение). Процессы не имеют общей области памяти. Поэтому ОС должна либо целиком скопировать со-
общение из области памяти одной задачи в область памяти другой (что для больших сообщений весьма накладно), либо предусмотреть специальные механизмы, которые позволили бы одной задаче по- лучить доступ к сообщению из области памяти другой задачи.
3.Как правило, контекст потоков меньше, чем контекст процес- сов, а значит, время переключения между задачами-потоками мень- ше, чем между задачами-процессами.
4.Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается использование про- грамм-отладчиков (debugger).
Недостатки потоков.
1.Как правило, потоки не могут быть подгружены динамически. Чтобы добавить новый поток, необходимо провести соответствую- щие изменения в исходных текстах и перекомпилировать приложе-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
15 |
ние. Процессы, в отличие от потоков, подгружаемы, что позволяет динамически изменять функции системы в процессе ее работы. Кро- ме того, так как процессам соответствуют отдельные программные модули, они могут быть разработаны различными компаниями, чем
достигается дополнительная гибкость и возможность использования ранее наработанного ПО.
2. То, что потоки имеют доступ к областям данных друг друга, может привести к ситуации, когда некорректно работающий поток способен испортить данные другого потока. В отличие от этого про- цессы защищены от взаимного влияния, а попытка записи в «не свою» память приводит, как правило, к возникновению специального прерывания по обработке «исключительных ситуаций».
Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаимодействия опре- деляются конкретным ПО РВ.
2.2. Основные свойства задач
Как правило, вся важная, с точки зрения операционной системы,
информация о задаче хранится в унифицированной структуре данных
– управляющем блоке (Task Control Block, TCB). В блоке хранятся та- кие параметры, как имя и номер задачи, верхняя и нижняя границы стека, ссылка на очередь сообщений, статус задачи, приоритет и т. п.
Приоритет – это некое целое число, присваиваемое задаче и характеризующее ее важность по сравнению с другими задачами, вы- полняемыми в системе. Приоритет используется в основном плани- ровщиком задач для определения того, какая из готовых к работе за- дач должна получить управление. Различают системы с динамиче- ской и статической приоритетностью. В первом случае приоритет за- дач может меняться в процессе исполнения, в то время как во втором
приоритет задач жестко задается на этапе разработки или во время начального конфигурирования системы.
Контекст задачи – это набор данных, содержащий всю необхо-
димую информацию для возобновления выполнения задачи с того места, где она была ранее прервана. Часто контекст хранится в TCB и включает в себя такие данные, как счетчик команд, указатель стека, регистры CPU и FPU и т. п. Планировщик задач в случае необходи- мости сохраняет контекст текущей активной задачи и восстанавлива- ет контекст задачи, назначенной к исполнению. Такое переключение
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
16 |
контекстов и является, по сути, основным механизмом ОС РВ при пе- реходе от выполнения одной задачи к выполнению другой.
Состояние (статус) задачи. С точки зрения операционной сис- темы, задача может находиться в нескольких состояниях. Число и на- звание этих состояний различаются от одной ОС к другой. По- видимому, наибольшее число состояний задачи определено в языке Ada. Тем не менее, практически в любой ОС РВ загруженная на вы- полнение задача может находиться, по крайней мере, в трех состоя- ниях.
1.Активная задача – это задача, выполняемая системой в теку- щий момент времени.
2.Готовая задача – это задача, готовая к выполнению и ожи- дающая у планировщика своей «очереди».
3.Блокированная задача – это задача, выполнение которой при- остановлено до наступления определенных событий. Такими собы- тиями могут быть освобождение необходимого задаче ресурса, по- ступление ожидаемого сообщения, завершение интервала ожидания и т. п.
Пустая задача (Idle Task) – это задача, запускаемая самой опе-
рационной системой в момент инициализации и выполняемая только тогда, когда в системе нег других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как пра- вило, представляет собой бесконечный цикл «ничего не делать». На-
личие пустой задачи предоставляет операционной системе удобный механизм отработки ситуаций, когда нет ни одной готовой к выпол- нению задачи.
Многократный запуск задач. Как правило, многозадачные ОС позволяют запускать несколько копий одной и той же задачи. При этом для каждой такой копии создается свой TCB и выделяется своя область памяти. В целях экономии памяти может быть предус-
мотрено совместное использование одного и того же исполняемого кода для всех запущенных копий. В этом случае программа должна обеспечивать повторную входимость (реентерабельность). Кроме то- го, программа не должна использовать временные файлы с фиксиро- ванными именами и должна корректно осуществлять доступ к гло- бальным ресурсам.
Реентерабельность (повторная входимость) означает возмож-
ность без негативных последствий временно прервать выполнение
www.pdffactory.com