1. Основные понятия систем реального времени.

Система – любой объект, который одновременно рассматривается как:

– единое целое;

– нечто, состоящее из множества связанных составных частей.

Такие системы, в которых время является базовой характеристикой, называютсясистемами реального времени (СРВ).

Среда. Нечто внешнее (внешняя среда) по отношению к объекту, которое воздействует на него (посылает возмущения), вызывая в нем какие - то изменения;

На рис. 1 дана общая схема СРВ, которая состоит из: объекта управления (ЧТО управляется); УУ (устройства управления) (ЧЕМ управляется).

Взаимодействие со средой и компонентами в СРВ определяется следующими сигналами:

X - возмущение, которое оказывает среда на объект. Она как бы старается "увести" объект от его (объекта) цели, которая заложена в УУ;

Y - реакция объекта на возмущение от среды в целях "нейтрализации" возмущений и возврата к цели объекта;

U - выработка "продукта" управления, для того чтобы объект "сопротивлялся" возмущениям среды, т.е. не "уходил" от своей цели.

2. Основные особенности систем реального времени.

• Гарантируемое время ответа - мы должны с достоверностью предсказать время ответа системы в самом худшем случае; эффективность важна, но предсказуемость - существеннее

• Параллельный контроль над отдельными компонентами системы - устройства работают параллельно в реальной жизни;

• Реализация СРВ в виде распределенных систем;

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

• Чрезвычайные требования к надежности и безопасности

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

• Система реального времени часто является частью более крупной программно-аппаратной системы, т.е. являются встраиваемыми системами.

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

3. Различие жестких и мягких систем реального времени.

Динамические свойства программ реального времени принято характеризовать тремя определениями: программы «жесткого» (hard), «мягкого» (soft) и интерактивного («условного») реального времени.

Жесткое реальное время. Предусматривает наличие гарантированного времени отклика системы на конкретное событие, например, аппаратное прерывание, выдачу команды управления и т.п. Абсолютная величина времени отклика большого значения не имеет. Так, если необходимо, чтобы программа отработала некоторую команду за 1 миллисекунду, но она справляется с этим заданием лишь в 95% случаев, а в 5% не укладывается в норматив, такую систему нельзя охарактеризовать как работающую в жестком реальном времени. Если же команду нужно отработать в течение часа, что и происходит в 100% случаев – налицо жесткое реальное время.

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

Мягкое реальное время. В этом случае ожидающееся время отклика системы является величиной скорее индикативной, нежели директивной. Конечно, предполагается что в большинстве случаев (процентов 80 — 90) отклик уложится в заданные пределы. Однако и остальные варианты – в том числе полное отсутствие реакции системы – не должны приводить к плачевным результатам. Обычно считается, что если временной норматив превышен на один порядок, то это еще терпимо .

Интерактивное реальное время. Является скорее психологической, нежели технической характеристикой. Определяет время, в течение которого оператор – человек – способен спокойно, без нервозности, ожидать реакции системы на данные им указания. В качестве примера можно привести весьма популярные сегодня игры из категории «стратегии реального времени» (real-time strategy, см. например квазар на основе Warhammer).

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

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

4. Алгоритмы реального времени и их особенности.

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

В связи с проблемами планирования в ОСРВ изучаются и развиваются два подхода - статические алгоритмы планирования (RMS - Rate Monotonic Scheduling) и динамические алгоритмы планирования (EDF - Earliest Deadline First).

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

• процесс должен быть завершен за время его периода,

• процессы не зависят друг от друга,

• каждому процессу требуется одинаковое процессорное время на каждом интервале,

• у непериодических процессов нет жестких сроков,

• прерывание процесса происходит за ограниченное время.

Процессы выполняются в соответствии с приоритетами. При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения.

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

Во всех системах реального времени требуется политика планирования, управляемая дедлайнами (deadline-driven scheduling). Однако этот подход находится в стадии разработки.

Обычно в ОСРВ используется планирование с приоритетами, прерывающими обслуживание, которое основано на RMS. Приоритетное прерывание обслуживания (preemption) является неотъемлемой составляющей ОСРВ, т.к. в системе реального времени должны существовать гарантии того, что событие с высоким приоритетом будет обработано перед событием более низкого приоритета. Все это ведет к тому, что ОСРВ нуждается не только в механизме планирования на основе приоритетов, прерывающих обслуживание, но также и в соответствующем механизме управления прерываниями. Более того, ОСРВ должна быть способна запрещать прерывания, когда необходимо выполнить критический код, который нельзя прерывать. Длительность обработки прерываний должна быть сведена к минимуму.

ОСРВ должна обладать развитой системой приоритетов. Во-первых, это требуется потому, что система сама может рассматриваться как набор серверных приложений, подразделяющихся на потоки, и несколько высоких уровней приоритетов должно быть выделено системным процессам и потокам. Во-вторых, в сложных приложениях необходимо все потоки реального времени помещать на разные приоритетные уровни, а потоки не реального времени помещать на один уровень (ниже, чем любые потоки реального времени). При этом потоки не реального времени можно обрабатывать в режиме циклического планирования (RRS - round-robinscheduling), при котором каждому процессу предоставляется квант времени процессора, а когда квант заканчивается, контекст процесса сохраняется, и он ставится в конец очереди. Во многих ОСРВ для планирования задач на одном уровне используется RRS. Приоритетный уровень 0 обычно используется для холостого режима.

При планировании на основе приоритетов необходимо решить две обязательные проблемы:

• обеспечить выполнение процесса с наивысшим приоритетом,

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

Для борьбы с инверсией приоритетов в ОСРВ часто используется механизм наследования приоритетов, однако при этом приходится отказываться от планирования на основе RMS, поскольку приоритеты становятся динамическими.

5. Особенности современных СРВ.

Состоит из программного обеспечения реального времени, операционной системы реального времени и подсистемы ввода/вывода реального времени.

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

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

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

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

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

6. Классификация современных СРВ.

Рассмотрим следующие классы АСУ, являющихся СРВ:

• АСУ ТП - АСУ технологическими процессами (например, система управления ядерным реактором АЭС или система управления конвейером автозавода);

• АСНИ - автоматизированные системы научных исследований и комплексных испытаний (например, система вибрационных испытаний компонентов ракетной техники);

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

Также приведем примеры АСУ, не относящихся к классу СРВ: АСУП - АСУ промышленным производством в целом (например, система управления материальными и финансовыми потоками предприятия) и ОАСУ (например, АСУ отрасли - Единой энергетической системы).

7. Архитектурные особенности СРВ.

В своем развитии ОСРВ строились на основе следующих архитектур:

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

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

• Архитектура «клиент-сервер». Основной её принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами — системными сервисами. Преимущества такой архитектуры:

1. Повышенная надёжность, так как каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки.

2. Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к её работоспособности.

3. Повышенная отказоустойчивость, так как «зависший» сервис может быть перезапущен без перезагрузки системы.

Архитектуры операционных систем реального времени
Монолитная архитектура	Уровневая (слоевая) архитектура

Архитектура «клиент–сервер»

8. Стандарт POSIX.

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

У каждого интерфейса есть две стороны: вызывающая и вызываемая. Стандарт POSIX ориентирован в первую очередь на вызывающую. Его цель - сделать приложения мобильными на уровне исходного языка. Это значит, в частности, что при переносе C-программ на другую операционную платформу потребуется перекомпиляция. О мобильности выполнимых программ и/или объектных файлов речь не идет.

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

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

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

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

В стандарте POSIX проведено разделение на обязательные и дополнительные функции, причем обязательное ядро сделано повозможности компактным. Разумеется, особое внимание уделяется способам реализации стандартизуемых функций как в "классической" Unix-среде, так и на других операционных платформах, в сетевых и распределенных конфигурациях.

Разработчики новой версии стандарта POSIX очень бережно отнеслись и к его предыстории, и к предыстории Unix-систем, и, главное, к приложениям, удовлетворявшим более ранним версиям стандарта. Существующие интерфейсы старались сохранять; в процессе развития соблюдался принцип обратной совместимости ; новые интерфейсы добавлялись так, чтобы они не конфликтовали со старыми. Полностью избежать внесения изменений в приложения не удалось по вполне понятным причинам: потребовалось устранить противоречия между разными исходными спецификациями, а также отказаться от поддержки "традиционного" варианта языка C и перейти на его международный стандарт.

9. Система прерываний и ее роль в СРВ.

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

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

Механизм обработки прерываний независимо от архитектуры вычислительной системы включает следующие элементы:

1. Установление факта прерывания (прием сигнала на прерывание) и идентификация прерывания (в операционных системах иногда осуществляется повторно, на шаге 4).

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

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

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

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

6. Восстановление информации, относящейся к прерванному процессу (этап, обратный шагу 4).

7. Возврат в прерванную программу. Шаги 1-3 реализуются аппаратно, а шаги 4-7 — программно.

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

 распознавание или классификация прерываний;

передача управления соответственно обработчику прерываний;

 корректное возвращение к прерванной программе.

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

Стек – среда для размещения данных для возврата из подпрограмм, а так же их аргументы и автоматические данные.

Фраза «По принципу стека» означает: последним пришел, первым обслужен или первым пришел, последним обслужен.

Вектор прерывания – специальная область памяти, где находится адрес прерывающейся программы.

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

10. Время генерации прерывания в устройствах объекта. Определение аппаратно-зависимого времени прерывания. Зависимость времени обработки прерывания от свойств ОС.

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

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

Наличие сигнала прерывания не обязательно должно вызывать прерывание исполняющейся программы.

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

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

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

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

• с абсолютными приоритетами, то есть всегда обслуживается прерывание с наивысшим приоритетом. Для реализации этого режима необходимо на время обработки прерывания замаскировать все запросы с более низким приоритетом. При этом возможно многоуровневое прерывание, то есть прерывание программ обработки прерываний. Число уровней прерывания в этом режиме изменяется и зависит от приоритета запроса;

 по принципу стека, или, как иногда говорят, по дисциплине LCFS (last come ferst served) – последним пришел – первым обслужен. Механизм прерываний чаще всего поддерживает приоритезацию и маскирование прерываний.

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

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

11. Время переключения контекста и его определение.

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

В процедуру переключения контекста входит т. н. планирование задачи — процесс принятия решения, какой задаче передать управление.

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

Для корректного переключения процессора с одного процесса на другой необходимо сохранить контекст исполнявшегося процесса и восстановить контекст процесса, на который будет переключен процессор. Такая процедура сохранения/восстановления работоспособности процессов называется переключением контекста. Время, затраченное на переключение контекста, не используется вычислительной системой для совершения полезной работы и представляет собой накладные расходы, снижающие производительность системы. Оно меняется от машины к машине и обычно находится в диапазоне от 1 до 1000 микросекунд. Существенно сократить накладные расходы в современных операционных системах позволяет расширенная модель процессов, включающая в себя понятие threads of execution (нити исполнения или просто нити).

12. Меры компенсации транспортного запаздывания.

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

Начнем с задачи синтеза компенсатора для одномерного процесса с запаздыванием. В конце 50-х годов был предложен так называемый прогнозатор Смита. Структурная схема соответствующей системы управления показана на рис. 1.

Рис.1. Одномерная система управления с прогнозатором Смита для объекта с (одним) запаздыванием.

 

Цель введения компенсатора с передаточной функцией

 (1)

 

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

, то выход замкнутой системы задается выражением

 (2)

и соответствующее характеристическое уравнение содержит запаздывание на

 (3)

После введения прогнозатора Смита (1) выход замкнутой системы задается выражением

 

(4)

и соответствующее характеристическое уравнение уже не содержит запаздывания:

 

 (5)

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

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

Для многомерных систем со многими запаздываниями задача синтеза регулятора с компенсацией запаздывания существенным образом усложняется. Рассмотрим многомерную систему в частотной области (1) — (3). Зависимость между m-мерным вектором управлений и l-мерным вектором выходов \ задается передаточной матрицей G (s):

 (1)

а зависимость между y(s) и n-мерным вектором возмущений d(s)— с помощью передаточной функции G_d(s):

(2)

при этом передаточные матрицы имеют вид

  (6)

Во многих практических задачах, особенно если передаточ­ные функции восстанавливаются по результатам экспериментов, G(s) и Gd{s) обычно имеют простой вид [см. уравнение (2)]. Однако возможны и более сложные передаточные функции.

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

 (7)

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

 

t

Рис. 2. Блок-схема обыкновенной системы регулирования для многомерного объекта управления.

Как было отмечено выше, имеется много способов представления систем с запаздываниями. Так, в случае линейной си­стемы с постоянными запаздываниями наиболее общее пред­ставление во временной области имеет вид

! ,   (8)

(9)

 где х — n-мерный вектор состояний;  - постоянные запаздывания.

Соответствующее представление в частотной области получим, беря преобразование Лапласа от (8), (9):

(10)

где

(11)

(12)

Отметим, что передаточные функции (11), (12) имеют гораздо более сложный вид, чем обычно бывает в реальных задачах. Это характерно для тех сравнительно редких на практике случаев, когда модель объекта уп­равления с самого начала задается в виде системы дифференциальных уравнений и нет необходимости восстанавливать ее по результатам экспериментов.

Оказывается, что для многомерных систем с запаздыванием можно построить компенсатор, аналогичный прогнозатору Смита и приводящий к тому, что запаздывающие члены в характеристическом уравнении замкнутой системы исчезают. Однако в отличие от одномерной задачи, где синтез компенсатора сводится к прогнозу выхода на время запаздывания, в многомерном случае компенсация связана с прогнозом некоторых «фиктивных» переменных состояния в заданные моменты времени. Структура многомерной си­стемы с запаздываниями, охваченной обратной связью с ком­пенсатором в контуре регулирования, изображена на рис. 2. Заметим, что эта структура аналогична рассмотренному выше одномерному случаю, т. е. собственно регулятору Смита. Передаточную функцию компенсатора О_к можно выбирать разными способами

Рис. 2. Блок-схема системы регулирования с компенсатором запаздываний для многомерного объекта управления.

Покажем, что при

 (13)

(где — соответствующие Н и G передаточные функции

без запаздываний) устраняется запаздывание по выходам и запаздывание в характеристическом уравнении замкнутой системы. Найдем передаточную функцию внутреннего контура G* на схеме рис. 2. Имеем  или

 (14)

Полная передаточная функция системы в этом случае задается выражением

 (15)

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

 (16)

 

где   (17)

 

Если G — квадратная невырожденная матрица¹), то, воспользовавшись леммой об обращении матриц, получим

Из выражения (16) следует соотношение

. Подставив выражения для и для в (17), найдем

 (18)

Устойчивость замкнутой системы определяется корнями характеристического уравнения

 .(19)

Как видно из (19), членов с запаздыванием в характеристическом уравнении уже нет, и, стало быть, запаздывания не влияют на устойчивость замкнутой системы. Это верно, однако, лишь в том случае, когда модель управляемого процесса абсолютно адекватна ему. На практике, конечно, этого достичь не удается и всегда остается некоторая неточность — ошибка аппроксимации объекта выбранной моделью; поэтому компен­сация запаздываний не является полной, и при настройке параметров регулятора приходится соблюдать некоторую осторожность. Несмотря на это, качество регулирования в системе с компенсацией запаздываний оказывается значительно более высоким, чем без нее.

13. Архитектура параллельных систем

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

1) независимость функционирования отдельных устройств ЭВМ - данное требование относится ко всем основным компонентам вычислительной системы - к устройствам ввода-вывода, к обрабатывающим процессорам и к устройствам памяти;

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

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

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

Массивно-параллельная архитектура

Главная особенность массивно-параллельной архитектуры (MPP – massive parallel processing) состоит в том, что память физически разделена. В этом случае система строится из отдельных модулей, содержащих процессор, локальный банк операционной памяти (ОП), коммуникационные процессоры (рутеры) или сетевые адаптеры, иногда – жесткие диски и/или другие устройства ввода/вывода. По сути такие модули представляют собой полнофункциональные компьютеры (рис. 1.4). Доступ к банку ОП из данного модуля имеют только процессоры (ЦП) из этого же модуля. Модули соединяются специальными коммуникационными каналами. Пользователь может определить логический номер процессора, к которому он подключен, и организовать обмен сообщениями с другими процессорами. Используются два варианта работы операционной системы (ОС) на машинах MPP-архитектуры. В одном полно-ценная операционная система (ОС) работает только на управляющей машине(front-end), на каждом отдельном модуле функционирует сильно урезанный вариант ОС, обеспечивающий работу только расположенной в нем ветви параллельного приложения. Во втором варианте на каждом модуле работает полноценная UNIX-подобная ОС, устанавливаемая отдельно.

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

Недостатки:

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

• каждый процессор может использовать только ограниченный объем локального банка памяти;

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

Системами с раздельной памятью являются суперкомпьютеры МВС-1000, IBM RS/6000 SP, SGI/CRAY T3E, системы ASCI, Hitachi SR8000, системы Parsytec.

Кластерная архитектура

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

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

Такие суперкомпьютерные системы являются самыми дешевыми, поскольку собираются на базе стандартных комплектующих элементов ("off the shelf"), процессоров, коммутаторов, дисков и внешних устройств.

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

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

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

В 1994 году Томас Стерлинг (Sterling) и Дон Беккер (Becker) создали 16-и узловой кластер «Beowulf» из процессоров Intel DX4, соединенных сетью 10Мбит/с Ethernet с дублированием каналов. Кластер возник в центре NASA Goddard Space Flight Center для поддержки необходимыми вычислительными ресурсами проекта Earth and Space Sciences. Проектно-конструкторские работы над кластером быстро превратились в то, что известно сейчас под названием проект Beowulf.

Проект стал основой общего подхода к построению параллельных кластерных компьютеров и описывает многопроцессорную архитектуру, которая может с успехом использоваться для параллельных вычислений. Beowulf-кластер, как правило, является системой, состоящей из одного серверного узла (который обычно называется головным узлом), а также одного или нескольких подчинённых узлов (вычислительных узлов), соединённых посредством стандартной компьютерной сети. Система строится с использованием стандартных аппаратных компонент, таких как ПК, запускаемых под Linux, стандартных сетевых адаптеров (например, Ethernet) и коммутаторов. Нет особого программного пакета, называемого «Beowulf». Вместо этого имеется несколько кусков программного обеспечения, которые многие пользователи нашли пригодными для построения кластеров Beowulf. Beowulf использует такие программные продукты как операционную систему Linux, системы передачи сообщений PVM, MPI, системы управления очередями заданий и другие стандартные продукты. Серверный узел контролирует весь кластер и обслуживает файлы, направляемые к клиентским узлам.

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

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

Наиболее эффективной является архитектура с топологией fat-tree – (1) архитектура кольца с полной связью по хордам, (2) - кластерная архитектура Fat Free, вид спереди (а) и вид сверху (б).

14. Управление ресурсами параллельной системы

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

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

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

Таким образом, можно сформулировать следующие задачи современной управляющей системы параллельных ВС:

1. Обеспечение безопасного удаленного доступа многих пользователей к ВС.

2. Прием входного потока параллельных задач разной сложности и размеров от разных пользователей.

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

4. Выделение необходимых вычислительных ресурсов для нужд параллельной задачи.

5. Освобождение выделенных вычислительных ресурсов после окончания счета параллельной задачи.

6. Организация ввода-вывода и информационного обмена для многих ветвей выполняющейся параллельной задачи.

7. Обеспечение равномерной загрузки процессоров параллельной ВС.

8. Обеспечение мониторинга вычислительных ресурсов и восстановления после отказов.

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

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

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

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

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

На втором уровне принимаются локальные, автономные решения по распределению ресурсов в рамках одного вычислительного модуля.

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

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

Существует три основных типа организации вычисли­тельного процесса в параллельных ВС:

· ведущий – ведомый;

· раздельное выполнение заданий в каж­дом процессоре;

· симметричная, или однородная, обработ­ка во всех процессорах.

15. Теория планирования в реальном времени

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

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

11.1.1. Планирование периодических задач. Изначально алгоритмы планирования в реальном времени разрабатывались для независимых периодических задач, то есть таких периодических задач, кото­рые не взаимодействуют друг с другом и, следовательно, не нуждаются в синхро­низации. С тех пор было проведено множество теоретических исследо­ваний, результаты которых теперь можно применять к практическим задачам, что и будет продемонстрировано на примерах. Но начнем мы с базового метода моно­тонного анализа частот для независимых периодических задач, чтобы понять, как обобщить его на более сложные ситуации.

Периодическая задача характеризуется периодом Т (частота запуска) и вре­менем выполнения С (время ЦП, необходимое для завершения одного запуска). Коэффициент использования ЦП для нее равен U = С/Т. Задача называется пла­нируемой(schedulable), если она удовлетворяет всем временным ограничениям, то есть ее исполнение завершается до истечения периода. Группа задач именуется планируемой, когда планируемой является каждая входящая в нее задача.

Если дано множество независимых периодических задач, то алгоритм моно­тонных частот назначает каждой задаче фиксированный приоритет, вычисляе­мый на основе ее периода: чем короче период, тем выше приоритет. Рассмотрим задачи t_a, t_b и t_c с периодами 10, 20 и 30 соответственно. Наивысший приоритет будет назначен задаче t_a с самым коротким периодом, средний приоритет - задаче t_b а самый низкий – задаче t_c, период которой максимален.

11.1.2. Теорема о верхней границе коэффициента использования ЦП. Пользуясь теорией планирования, можно показать, что группа независимых пе­риодических задач всегда удовлетворяет временным ограничениям при условии, что сумма отношений С/Тпо всем задачам меньше некоторого граничного значения.

Теорема о верхней границе коэффициента использования ЦП (теорема 1) гласит:

Множество из п независимых периодических задач, планируемых согласно алго­ритму монотонных частот, всегда удовлетворяет временным ограничениям, если

где С_i и Т_i – время выполнения и период задачи t_i соответственно.

Верхняя граница U(n) стремится к 69% (ln 2), когда число задач стремится к бесконечности. Значения верхней границы для числа задач от 1 до 9 приведены в табл.11.1. Это оценка для худшего случая, но, как показано в работе [22], для случайно выбранной группы задач вероятная верхняя граница равна 88%. Если периоды задач гармоничны (являются кратными друг другу), то верхняя граница оказывается еще выше.

16. Анализ производительности проекта параллельных систем

На этапе определения требований задается время реакции системы на внеш­ние события. После разбиения на задачи можно предпринять первую попытку выделения временных бюджетов параллельным задачам. Для выявления задач, которые необходимо выполнить при обслуживании данного внешнего события, используется анализ последовательности событий. Чтобы показать последова­тельность событий и задач, активизируемых приходом внешнего события, применяется диаграмма последовательности событий, основанная на диаграмме параллельной кооперации.

Следует рассмотреть внешнее событие, определить, какая задача ввода/выво­да активизируется таким событием и какая ожидается цепочка внутренних собы­тий. Для этого необходимо знать, какие задачи активизируются и какие задачи ввода/вывода генерируют отклик системы на внешнее событие. Далее нужно оце­нить время ЦП, потребляемое каждой задачей, и накладные расходы, состоящие из затрат на контекстное переключение, обработку прерывания и межзадачные коммуникации и синхронизацию. Надо проанализировать также другие задачи, выполняемые в тот же период времени. Суммарное время ЦП, потребляемое все­ми задачами, которые участвуют в цепочке событий, и всеми дополнительными задачами, которые исполнялись в то же время, плюс накладные расходы – все вместе не должно превысить заданное время реакции системы. Если вы не знаете точно времени ЦП, потребляемого каждой задачей, принимайте оценку для худ­шего случая.

Для анализа полного коэффициента использования ЦП необходимо рассчитать время, потребляемое каждой задачей на данном интервале. Если существует не­сколько путей выполнения задачи, то нужно получить оценку времени для каждого из них. Затем следует оценить частоту активизации задач. Для периодических задач это легко. Для асинхронных задач удобно рассмотреть среднюю и макси­мальную частоту активизации. Умножьте время ЦП для каждой задачи на ее час­тоту активизации, просуммируйте результаты и вычислите коэффициент исполь­зования ЦП.

17. Квантование и его использование в системах реального времени.

Во многих операционных системах алгоритмы планирования построены с использованием как концепции квантования, так и приоритетов. К примеру, в базе планирования лежит квантование, но величина кванта и/или порядок выбора потока из очереди готовых определяется приоритетами потоков. Именно так реализовано планирование в системе Windows NT, в которой квантование сочетается с динамическими абсолютными приоритетами. На выполнение выбирается готовый поток с наивысшим приоритетом. Ему выделяется квант времени. В случае если во время выполнения в очереди готовых появляется поток с более высоким приоритетом, то он вытесняет выполняемый поток. Вытесненный поток возвращается в очередь готовых, причем он становится впереди всœех остальных потоков имеющих такой же приоритет.

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

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

Активная задача выполнила системный вызов, связанный с запросом на ввод-вывод или на доступ к ресурсу, который в настоящий момент занят (к примеру, файл данных). Планировщик переводит задачу в состояние ожидания и выполняет перепланирование.

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

Внешнее (аппаратное) прерывание, ĸᴏᴛᴏᴩᴏᴇ сигнализирует о завершении периферийным устройством операции ввода-вывода, переводит соответствующую задачу в очередь готовых, и выполняется планирование.

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

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

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