Управление задачами
Рассмотрим функции, позволяющие управлять задачами.
Создание задачи
Программный код функции (задачи) конечно оттранслирован заранее и загружен в память программ. «Создание» означает сообщение системе о том, что данную задачу необходимо планировать и диспетчировать для выполнения. ОС управляет только теми задачами, которые «созданы». При «создании» задачи ОС добавляет информацию о задаче в системные структуры, описывающие перечень задач, подлежащих выполнению.
Как уже было упомянуто, задача должна быть оформлена как функция, которая никогда не завершается. Это связано с тем, что если задача завершится, а ОС будет продолжать ее планирование и диспетчеризацию, то все рухнет – ОС возобновит выполнение кода в неопределенном контексте. Поэтому, если задачу не требуется более выполнять никогда, ее надо «уничтожить» (delete), т.е. сообщить ОС о необходимости удалить ее из списка подлежащих выполнению.
Приоритет – уникальная характеристика Задачи в микроСи/ОС-II. Она используется как параметр во многих системных сервисах.
Для этого служит системная функция «удаление Задачи» OSTaskDel.
Уничтожение (удаление) Задачи
Прототип функции.
INT8U OSTaskDel(INT8U prio);
Параметры функции
prio приоритет удаляемой Задачи, он в данном случае служит идентификатором Задачи, так как в uC/OS каждая Задача должна иметь уникальный приоритет. Задача может удалить не только другую Задачу, но и сама себя, для этого она может указать как собственный (известный ей) приоритет, так и значение OS_PRIO_SELF, которое вынудит операционную систему саму определить этот приоритет.
Задаче никто не мешает удалить самой себя. Напротив, задача не может завершиться как обычная функция, поскольку ОС будет думать, что эту задачу надо планировать и диспетчировать, а возвращать управление некуда – задача завершилась.
Помните, что код Задачи физически никуда не удаляется, он находится в памяти, впоследствии можно заново сделать эту Задачу активной (т.е. создать).
Две описанные функции – основные для управления задачами. Прочие функции используются (по Лаброссу) относительно редко.
Изменение приоритета задачи
Прототип функции.
INT8U OSTaskChangePrio(INT8U oldprio, INT8U newprio);
Функция изменяет приоритет указанной задачи, и, таким образом, позволяет динамически управлять приоритетами.
Присвоение задачам приоритетов является непростым делом в силу сложной природы систем реального времени. В большинстве систем не все задачи являются критичными ко времени их выполнения. Некритичным задачам обычно присваивается низкий приоритет. К большинству систем предъявляются требования как жесткого, так и мягкого реального времени. В системах мягкого реального времени задачи выполняются быстро насколько это возможно, но они не обязаны завершаться за определённое время. В системах жесткого реального времени задачи должны выполняться в срок, за предопределённое время.
Условные обозначения
Ti – период возникновения события, на которое должна реагировать Задача Di – срок реакции от момента возникновения события Ei – время выполнения обслуживающего кода. Ei/Ti – доля процессорного времени, занимаемая i-й Задачей.
Статические приоритеты
Rate Monotonic Algorithm (пропорциональная диспетчеризация)
Наиболее известное правило называемое пропорциональной диспетчеризацией может применяться для назначения задачам приоритетов пропорционально частоте их выполнения. Проще говоря, задаче с большей частотой обращения к процессору присваивается высший приоритет (см. рис.).
Пропорциональная диспетчеризация исходит из следующих предположений: 1. Все задачи периодичны (происходят регулярно). 2. Задачи не синхронизированы друг с другом, не разделяют ресурсов, и не обмениваются данными. 3. Процессор всегда выполняет задачу с наивысшим приоритетом, то есть должно использоваться ядро вытесняющего типа.
Рис.2.9. Пропорциональная диспетчеризация
Базовая теорема пропорциональной диспетчеризации утверждает, что для набора из n задач все требования жесткого реального времени выполняются, если соблюдено следующее неравенство:
Ei - наибольшее время выполнения задачи i Ti - период выхода задачи i на процессор
Другими словами, Ei/Ti - доля времени процессора, необходимого задаче i. Таблица 2.1 содержит значения величины n(21/n -1) в зависимости от числа задач n. Значение этого выражения для бесконечно большого числа задач представляется в виде ln 2, или 0.693. Это означает, что для того, чтобы обеспечить все требования жесткого реального времени в системе с пропорциональной диспетчеризацией необходимо, чтобы загрузка процессора критичными ко времени исполнения задачами была меньше 70 процентов! Заметьте, что при этом в системе могут выполняться и некритичные ко времени выполнения задачи, а общая загрузка процессора вполне может достигать 100 процентов. Замечу, что использование 100 процентов времени процессора не является желаемой целью, так как не позволяет расширять дизайн системы. Как правило, вы должны использовать 60-70 процентов процессорного времени.
Сказанное относится только к Задачам, к которым предъявляются требования реального времени. В системе могут быть Задачи, к которым не предъявляется никаких требований реального времени. Эти Задачи могут выполняться в промежутках между исполнением критичных ко времени Задач и таким образом, загрузка процессора может достигать 100%.
Количество задач |
n( 21/n - 1) |
1 |
1.000 |
2 |
0.828 |
3 |
0.779 |
4 |
0.756 |
5 |
0.743 |
... |
... |
∞ |
0.693 |
В случае пропорциональной диспетчеризации предполагается, что самая часто выполняемая задача имеет наивысший приоритет. Однако, в некоторых случаях самая часто выполняемая задача может не быть самой важной. Специфика собственно самого приложения является основанием для присвоения приоритетов. Методика пропорциональной диспетчеризации - это, конечно, хороший старт.
Пример стратегии динамического назначения приоритетов
Эта стратегия исходит из тех же предположений, что и пропорциональная диспетчеризация, но приоритеты Задач динамически изменяются во время работы.
В реальных приложениях Задачи требуют взаимной синхронизации, разделяют ресурсы и обмениваются данными. В этих условиях проблема выбора приоритетов оказывается весьма сложной и нетривиальной. Она в общем виде пока не решена.