Монотонное планирование
В информатике — монотонное по скорости планирование ( RMS ). [ 1 ] — это алгоритм назначения приоритетов, используемый в операционных системах реального времени (RTOS) с классом планирования со статическим приоритетом. [ 2 ] Статические приоритеты назначаются в соответствии с продолжительностью цикла задания, поэтому более короткая продолжительность цикла приводит к более высокому приоритету задания.
Эти операционные системы, как правило, являются упреждающими и имеют детерминированные гарантии в отношении времени отклика. Монотонный анализ скорости используется вместе с этими системами для обеспечения гарантий планирования для конкретного приложения.
Введение
[ редактировать ]Простая версия монотонного анализа предполагает, что потоки обладают следующими свойствами:
- Нет совместного использования ресурсов (процессы не совместно используют ресурсы, например, ресурс аппаратный , очередь или любой вид семафора блокировки или неблокировки ( ожидание занятости ))
- Детерминированные сроки в точности равны периодам
- Статические приоритеты (выполняемая задача с наивысшим статическим приоритетом немедленно вытесняет все остальные задачи)
- Статические приоритеты назначаются в соответствии с монотонными соглашениями о ставках (задачи с более короткими периодами/сроками имеют более высокий приоритет)
- Время переключения контекста и другие потоковые операции бесплатны и не влияют на модель.
Это математическая модель, содержащая рассчитанное моделирование периодов в закрытой системе, в которой планировщики циклического перебора и разделения времени в противном случае не могут удовлетворить потребности планирования. Монотонное планирование скорости учитывает моделирование выполнения всех потоков в системе и определяет, сколько времени необходимо для выполнения гарантий для рассматриваемого набора потоков.
Оптимальность
[ редактировать ]Назначение приоритета с монотонной скоростью является оптимальным при данных предположениях, а это означает, что если какой-либо алгоритм планирования со статическим приоритетом может уложиться во все сроки, то и алгоритм с монотонной скоростью тоже может это сделать. Алгоритм монотонного по срокам планирования также оптимален при равных периодах и сроках, ведь в этом случае алгоритмы идентичны; кроме того, монотонное планирование по срокам является оптимальным, когда сроки меньше периодов. [ 3 ] Для модели задачи, в которой сроки могут превышать периоды, алгоритм Одсли, оснащенный точным тестом на планирование для этой модели, находит оптимальное назначение приоритетов. [ 4 ]
Верхние границы использования
[ редактировать ]Наименьшая верхняя граница
[ редактировать ]Лю и Лэйланд (1973) доказали, что для набора из n периодических задач с уникальными периодами существует осуществимый график, который всегда будет соответствовать установленным срокам, если загрузка ЦП ниже определенного предела (в зависимости от количества задач). Тест на планирование для RMS:
где U — коэффициент использования, C i — время вычислений для процесса i , T i — период выпуска (с крайним сроком на один период позже) для процесса i , а n — количество процессов, которые необходимо запланировать. Например, U ≤ 0,8284 для двух процессов. Когда число процессов стремится к бесконечности , это выражение будет стремиться к:
Поэтому приблизительная оценка, когда заключается в том, что RMS может уложиться во все сроки, если общая загрузка ЦП U составляет менее 70%. Остальные 30% ЦП могут быть выделены для задач с более низким приоритетом, не выполняемых в режиме реального времени. Для меньших значений n или в случаях, когда U близко к этой оценке, следует использовать рассчитанную границу использования.
На практике для процесс, должно представлять наихудшее (т.е. самое продолжительное) время вычислений и должен представлять собой крайний срок для наихудшего случая (т. е. кратчайший период), в течение которого должна произойти вся обработка.
Связь с теорией массового обслуживания
[ редактировать ]В теории массового обслуживания T i называется временем между прибытиями , а C i называется временем обслуживания . Эти два параметра часто указываются как ставки:
- - скорость прибытия , и
- это тариф за обслуживание .
Тогда использование для каждой задачи, обозначаемое ρ i , будет следующим:
как указано выше.
Верхняя граница для гармоничных наборов задач
[ редактировать ]Лю и Лейланд отметили, что эту границу можно ослабить до максимально возможного значения 1,0, если для задач , где и , является целым числом, кратным , то есть все задачи имеют период, который не просто кратен самому короткому периоду, , но вместо этого период любой задачи кратен всем более коротким периодам. Это известно как гармонический набор задач . Примером этого может быть: . Лю и Лейланд признают, что не всегда возможно иметь гармоничный набор задач и что на практике вместо этого могут использоваться другие меры по смягчению последствий, такие как буферизация для задач с мягкими сроками или использование подхода динамического назначения приоритетов, чтобы позволить для более высокой границы.
Обобщение на гармонические цепи
[ редактировать ]Ко и Мок [ 5 ] показал, что для набора задач, состоящего из K подмножеств гармонических задач (известных как гармонические цепочки ), тест наименьшей верхней границы принимает вид:
В случае, когда для каждой задачи ее период кратен периоду любой другой задачи, которая имеет более короткий период, набор задач можно рассматривать как состоящий из n гармонических подмножеств задач размером 1 и, следовательно, , что делает это обобщение эквивалентным наименьшей верхней границе Лю и Лейланда. Когда , верхняя граница становится равной 1,0, что соответствует полному использованию.
Стохастические границы
[ редактировать ]Было показано, что случайно сгенерированная система периодических задач обычно обеспечивает соблюдение всех сроков, когда загрузка составляет 88% или меньше. [ 6 ] однако этот факт зависит от знания точной статистики задач (периоды, сроки), которая не может быть гарантирована для всех наборов задач, и в некоторых случаях авторы обнаружили, что загрузка достигла наименьшей верхней границы, представленной Лю и Лэйландом.
Гиперболическая граница
[ редактировать ]Гиперболическая граница [ 7 ] является более строгим достаточным условием планируемости, чем то, которое было представлено Лю и Лэйландом:
- ,
где U i — загрузка ЦП для каждой задачи. Это самая точная верхняя граница, которую можно найти, используя только коэффициенты использования отдельных задач.
Совместное использование ресурсов
[ редактировать ]Во многих практических приложениях ресурсы являются общими, и немодифицированная RMS будет подвержена риску инверсии приоритетов и возникновения тупиковой ситуации . На практике это решается отключением preemption или наследованием приоритетов . Альтернативные методы — использовать алгоритмы без блокировок или избегать совместного использования мьютекса/семафора между потоками с разными приоритетами. Это сделано для того, чтобы конфликты ресурсов не могли возникнуть в первую очередь.
Отключение приоритета
[ редактировать ]- The
OS_ENTER_CRITICAL()
иOS_EXIT_CRITICAL()
примитивы, которые блокируют прерывания ЦП в ядре реального времени, например MicroC/OS-II - The
splx()
семейство примитивов, которые встраивают блокировку прерываний устройства (FreeBSD 5.x/6.x),
Приоритетное наследование
[ редактировать ]- Базовый протокол наследования приоритетов [ 8 ] повышает приоритет задачи, которая удерживает ресурс, до приоритета задачи, которая запрашивает этот ресурс во время выполнения запроса. При освобождении ресурса первоначальный уровень приоритета до продвижения восстанавливается. Этот метод не предотвращает взаимоблокировки и страдает от цепной блокировки . То есть, если задача с высоким приоритетом последовательно обращается к нескольким общим ресурсам, ей, возможно, придется ожидать (блокировать) задачу с более низким приоритетом для каждого из ресурсов. [ 9 ] Патч реального времени , заархивированный 13 октября 2020 г. на Wayback Machine, для ядра Linux включает реализацию этой формулы. [ 10 ]
- Протокол максимального приоритета [ 11 ] расширяет протокол наследования базового приоритета, назначая каждому семафору максимальный приоритет , который является приоритетом самого высокого задания, которое когда-либо будет иметь доступ к этому семафору. Задание не может вытеснить критический раздел с более низким приоритетом, если его приоритет ниже максимального приоритета для этого раздела. Этот метод предотвращает взаимоблокировки и ограничивает время блокировки не более чем длиной одного критического раздела с более низким приоритетом. Этот метод может быть неоптимальным, поскольку может вызвать ненужную блокировку. Протокол максимального приоритета доступен в VxWorks ядре реального времени . Он также известен как протокол наивысшего приоритета шкафчика (HLP). [ 12 ]
Алгоритмы наследования приоритетов можно охарактеризовать двумя параметрами. Во-первых, является ли наследование ленивым (только когда это необходимо) или немедленным (повышение приоритета до возникновения конфликта). Во-вторых, наследование оптимистичное (увеличение минимальной суммы) или пессимистическое (увеличение суммы, превышающей минимальную):
пессимистичный | оптимистичный | |
---|---|---|
немедленный | OS_ENTER_CRITICAL() / OS_EXIT_CRITICAL()
|
splx() , самый высокий шкафчик
|
ленивый | протокол потолка приоритета, протокол наследования базового приоритета |
На практике нет математической разницы (с точки зрения границы использования системы Лю-Лейланда) между ленивыми и немедленными алгоритмами, а немедленные алгоритмы более эффективны в реализации, и поэтому именно они используются большинством практических систем. [ нужна ссылка ]
Пример использования базового наследования приоритетов связан с « Mars Pathfinder ». ошибкой сброса [ 13 ] [ 14 ] что было исправлено на Марсе путем изменения флагов создания семафора, чтобы включить наследование приоритета.
Подпрограммы обслуживания прерываний
[ редактировать ]Все процедуры обслуживания прерываний (ISR), независимо от того, имеют ли они жесткий крайний срок в реальном времени или нет, должны быть включены в анализ RMS, чтобы определить возможность планирования в тех случаях, когда ISR имеют приоритет над всеми задачами, управляемыми планировщиком. ISR уже может иметь соответствующий приоритет в соответствии с правилами RMS, если период его обработки короче, чем у самого короткого процесса, не относящегося к ISR. Однако ISR с периодом/сроком, превышающим любой период процесса, не относящийся к ISR, с критическим сроком, приводит к нарушению RMS и препятствует использованию рассчитанных границ для определения планируемости набора задач.
Смягчение последствий неправильно расставленных приоритетов ISR
[ редактировать ]Одним из методов смягчения последствий ISR с неправильным приоритетом является корректировка анализа путем сокращения периода ISR, чтобы он был равен периоду самого короткого периода, если это возможно. Введение этого более короткого периода приводит к установлению приоритетов, которые соответствуют RMS, но также приводят к более высокому коэффициенту использования для ISR и, следовательно, для общего коэффициента использования, который все еще может быть ниже допустимой границы, и, следовательно, можно доказать возможность планирования. В качестве примера рассмотрим аппаратный ISR, время вычисления которого равно 500 микросекунд и период, , 4 миллисекунды. Если самая короткая задача, управляемая планировщиком, имеет период, Если значение составляет 1 миллисекунду, то ISR будет иметь более высокий приоритет, но более низкую скорость, что нарушает RMS. Для доказательства планируемости положим и пересчитать коэффициент использования для ISR (что также повышает общий коэффициент использования). В этом случае, изменится с к . Этот коэффициент использования будет использоваться при сложении общего коэффициента использования набора задач и сравнении с верхней границей для подтверждения возможности планирования. Следует подчеркнуть, что настройка периода ISR предназначена только для анализа и что истинный период ISR остается неизменным.
Другой метод смягчения последствий ISR с неправильным приоритетом заключается в использовании ISR только для установки нового семафора/мьютекса при перемещении трудоемкой обработки к новому процессу, которому был присвоен соответствующий приоритет с помощью RMS и который будет блокироваться на новом семафоре/мьютексе. При определении планируемости предел использования ЦП, обусловленный активностью ISR, следует вычесть из наименьшей верхней границы. ISR с незначительным использованием можно игнорировать.
Примеры
[ редактировать ]Пример 1
[ редактировать ]Процесс | Время расчета C | Период выпуска Т | Приоритет |
---|---|---|---|
П1 | 1 | 8 | 2 |
П2 | 2 | 5 | 1 |
П3 | 2 | 10 | 3 |
В рамках RMS P2 имеет самую высокую скорость выпуска (т. е. самый короткий период выпуска) и поэтому будет иметь самый высокий приоритет, за ним следует P1 и, наконец, P3.
Наименьшая верхняя граница
[ редактировать ]Использование будет:
- .
Достаточное условие для Процессы, из которых можно сделать вывод, что система является планируемой, это:
Потому что , а поскольку наличие ниже наименьшей верхней границы является достаточным условием, система гарантированно будет планируемой.
Пример 2
[ редактировать ]Процесс | Время расчета C | Период выпуска Т | Приоритет |
---|---|---|---|
П1 | 3 | 16 | 3 |
П2 | 2 | 5 | 1 |
П3 | 2 | 10 | 2 |
В рамках RMS P2 имеет самую высокую скорость выпуска (т. е. самый короткий период выпуска) и поэтому будет иметь наивысший приоритет, за ним следует P3 и, наконец, P1.
Наименьшая верхняя граница
[ редактировать ]Используя границу Лю и Лейланда, как в примере 1, достаточное условие для процессов, при которых можно сделать вывод о планируемости поставленной задачи, остается:
Общий объем использования составит:
- .
С , определяется, что система не может быть гарантированно запланирована по границе Лю и Лэйланда.
Гиперболическая граница
[ редактировать ]Используя более жесткую гиперболическую границу следующим образом:
обнаружено, что набор задач является планируемым.
Пример 3
[ редактировать ]Процесс | Время расчета C | Период выпуска Т | Приоритет |
---|---|---|---|
П1 | 7 | 32 | 3 |
П2 | 2 | 5 | 1 |
П3 | 2 | 10 | 2 |
При RMS P2 имеет самую высокую скорость (т.е. самый короткий период) и, следовательно, будет иметь самый высокий приоритет, за ним следует P3 и, наконец, P1.
Наименьшая верхняя граница
[ редактировать ]Используя границу Лю и Лейланда, как в примере 1, достаточное условие для процессов, при которых можно сделать вывод о планируемости поставленной задачи, остается:
Общий объем использования составит:
- .
С , определяется, что система не может быть гарантированно запланирована по границе Лю и Лэйланда.
Гиперболическая граница
[ редактировать ]Используя более жесткую гиперболическую границу следующим образом:
С определено, что система не может быть гарантированно запланирована с помощью гиперболической границы.
Гармонический анализ набора задач
[ редактировать ]Потому что , задачи 2 и 3 можно рассматривать как гармоническое подмножество задач. Задача 1 образует собственное подмножество гармонических задач. Следовательно, количество подмножеств гармонических задач K равно 2 .
Используя рассчитанный выше общий коэффициент использования (0,81875), поскольку система определена как планируемая.
См. также
[ редактировать ]- Дедлайн-монотонное планирование
- Deos , разделенная во времени и пространстве операционная система реального времени, содержащая работающий монотонный планировщик скорости.
- Динамическое планирование приоритетов
- Первое планирование самого раннего срока
- RTEMS — операционная система реального времени с открытым исходным кодом, содержащая работающий планировщик скорости Monotonic.
- Планирование (вычисления)
- Теория массового обслуживания
- Формула Кингмана
Ссылки
[ редактировать ]- ^ Лю, CL ; Лэйланд, Дж. (1973), «Алгоритмы планирования для мультипрограммирования в среде жесткого реального времени», Журнал ACM , 20 (1): 46–61, CiteSeerX 10.1.1.36.8216 , doi : 10.1145/321738.321743 , S2CID 207669821 .
- ^ Бове, Дэниел П.; Чесати, Марко, Понимание ядра Linux , http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#85347. Архивировано 21 сентября 2014 г. на Wayback Machine .
- ^ Люнг, JY; Уайтхед, Дж. (1982), «О сложности планирования периодических задач реального времени с фиксированным приоритетом», Performance Evaluation , 2 (4): 237–250, doi : 10.1016/0166-5316(82)90024- 4 .
- ^ Алан Бернс и Энди Веллингс (2009), Системы реального времени и языки программирования (4-е изд.), Аддисон-Уэсли, стр. 391, 397, ISBN 978-0-321-41745-9
- ^ Т.-В. Куо; АК Мок (1991). «Регулировка нагрузки в адаптивных системах реального времени». [1991] Материалы Двенадцатого симпозиума по системам реального времени . стр. 160–170. дои : 10.1109/REAL.1991.160369 . ISBN 0-8186-2450-7 . S2CID 31127772 .
- ^ Лехочки, Дж.; Ша, Л.; Дин, Ю. (1989), «Алгоритм монотонного планирования скорости: точная характеристика и поведение в среднем случае», Симпозиум IEEE Real-Time Systems Symposium , стр. 166–171, doi : 10.1109/REAL.1989.63567 , ISBN 978-0-8186-2004-1 , S2CID 206524469 .
- ^ Энрико Бини; Джорджио К. Бутаццо; Джузеппе М. Бутаццо (2003), «Монотонный анализ скорости: гиперболическая граница», IEEE Transactions on Computers , 52 (7): 933–942, doi : 10.1109/TC.2003.1214341 , hdl : 11382/200358
- ^ Лэмпсон, Британская Колумбия ; Ределл, Д.Д. (1980), «Опыт работы с процессами и мониторами в Mesa», Communications of the ACM , 23 (2): 105–117, CiteSeerX 10.1.1.46.7240 , doi : 10.1145/358818.358824 , S2CID 1594544 .
- ^ Бутаццо, Джорджио (2011), Вычислительные системы жесткого реального времени: алгоритмы и приложения предсказуемого планирования (Третье изд.), Нью-Йорк, Нью-Йорк: Springer, стр. 225
- ^ «Linux Wiki реального времени» . ядро.org. 26 марта 2008 г. Проверено 14 марта 2014 г.
- ^ Ша, Л.; Раджкумар, Р.; Лехоцки, Дж.П. (1990), «Протоколы наследования приоритетов: подход к синхронизации в реальном времени», IEEE Transactions on Computers , 39 (9): 1175–1185, doi : 10.1109/12.57058 .
- ^ Бутаццо, Джорджио (2011), Вычислительные системы жесткого реального времени: алгоритмы и приложения предсказуемого планирования (Третье изд.), Нью-Йорк, Нью-Йорк: Springer, стр. 212
- ^ «Майк Джонс из Microsoft Research» .
- ^ «Ошибка сброса Mars Pathfinder — интересная антология» . Архивировано из оригинала 5 октября 2011 г. Проверено 9 сентября 2008 г.
Дальнейшее чтение
[ редактировать ]- Бутаццо, Джорджио (2011), Вычислительные системы жесткого реального времени: алгоритмы и приложения предсказуемого планирования , Нью-Йорк, Нью-Йорк: Springer .
- Алан Бернс и Энди Веллингс (2009), Системы реального времени и языки программирования (4-е изд.), Аддисон-Уэсли, ISBN 978-0-321-41745-9
- Лю, Джейн В.С. (2000), Системы реального времени , Аппер-Сэддл-Ривер, Нью-Джерси: Прентис-Холл , Глава 6.
- Джозеф, М.; Пандия, П. (1986), «Определение времени отклика в системах реального времени», BCS Computer Journal , 29 (5): 390–395, doi : 10.1093/comjnl/29.5.390 .
- Ша, Луи; Гуденаф, Джон Б. (апрель 1990 г.), «Теория планирования в реальном времени и Ada», IEEE Computer , 23 (4): 53–62, doi : 10.1109/2.55469 , S2CID 12647942
Внешние ссылки
[ редактировать ]- Ошибка Mars Pathfinder от исследования @ Microsoft
- Что на самом деле произошло на марсоходе Pathfinder, автор Майк Джонс из The Risks Digest, Vol. 19, Выпуск 49
- [1] Фактическая причина ошибки Mars Pathfinder, указанная теми, кто действительно имел с ней дело, а не кем-то, чья компания и, следовательно, стоимость акций зависели от описания проблемы, или кем-то, кто слышал, как кто-то говорил о проблеме.