Министерство образования и науки Российской Федерации

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра автоматизированных систем управления

А.М.СУЛЕЙМАНОВА

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

Учебное пособие

Уфа 2004

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

2

Составитель А.М. Сулейманова УДК 004.415.2 ББК 32.973.26-018.1

Сулейманова А.М. Системы реального времени: учебное посо- бие/ Уфимск. гос. авиац. техн. ун-т.– Уфа, 2004.– 292 с.

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

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

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

Предназначено для студентов специальностей «Автоматизиро- ванные системы обработки информации и управления» и «Приклад- ная информатика в экономике».

Библиогр.: 29 назв.

Научный редактор: канд.техн.наук, доцент М.Я.Парфенова

Рецензенты: канд.техн.наук, доцент, заведующая кафедрой Информатики БАГСУ С.М.Ибатуллина Канд.техн.наук, доцент, заместитель заведующего кафедрой Управления в ОВД В.А.Пестриков

©Уфимский государственный авиационный технический университет, 2004

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ	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

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ	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

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ	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

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

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

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

12

2. Ядра и операционные системы реального времени

Примем как очевидные следующие моменты.

1.Когда-то операционных систем совсем не было.

2.Через некоторое время после их появления возникло направ- ление ОС РВ.

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

Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возмож- ностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуника- ция, управление памятью и т.п. Операционные системы в дополнение

кэтому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.

По своей внутренней архитектуре ОС РВ можно условно разде- лить на монолитные ОС, ОС на основе микроядра и объектно- ориентированные ОС. Графически различия в этих подходах иллюст- рируются рисунками 2.1, 2.2, 2.3. Преимущества и недостатки раз- личных архитектур достаточно очевидны, поэтому подробно мы на них останавливаться не будем.

Рис. 2.1. ОС РВ с монолитной архитектурой

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

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