Комментарии 8
Прям как вернулся на предметы по сетям и ОС :)
EDF относится к частично-динамическим дисциплинам планирования, в то время, как стандартом в системах жесткого реального времени являются статические. Мифа #7 является мифом лишь в классе не-статических процедур. В промышленных задачах миф #7 оказывается полностью выполнимым, поскольку c 2001 года известны условия, при которых гарантируется 100% соблюдение дедлайнов в статике в SMP-системах.
В части указанных недостатков современная наука дает однозначный ответ — полностью динамические дисциплины, такие как PFair.
В части указанных недостатков современная наука дает однозначный ответ — полностью динамические дисциплины, такие как PFair.
Да, действительно, в системах жесткого реального времени стандартом являются дисциплины планирования со статическими приоритетами. Однако, теория говорит что динамические дисциплины работают лучше. EDF позволяет выполнять все дедлайны при полной утилизации, а RM (Rate-Monotonic) гарантирует это только при утилизации не выше 69%.
Дело не в том используем ли мы статические или динамические приоритеты. Если у нас имеется hard-RT-система, то мы про нее все знаем и можем найти осуществимое расписание, при условии что оно существует. Если мы можем найти расписание со статическими приоритетами, то найдется и расписание с динамическими приоритетами, так как это более широкий класс расписаний.
В этом мифе речь про soft-RT-системы, в которых существует неопределенность (overrun и/или overload). Формулировка мифа, согласен, несколько преувеличена.
Дело не в том используем ли мы статические или динамические приоритеты. Если у нас имеется hard-RT-система, то мы про нее все знаем и можем найти осуществимое расписание, при условии что оно существует. Если мы можем найти расписание со статическими приоритетами, то найдется и расписание с динамическими приоритетами, так как это более широкий класс расписаний.
В этом мифе речь про soft-RT-системы, в которых существует неопределенность (overrun и/или overload). Формулировка мифа, согласен, несколько преувеличена.
Теоретический предел по времени отклика в 69% справедлив только для систем с единственным процессором. Согласитесь, в современных реалиях апеллирование к оценке второй половины прошлого века выглядит более чем странно. RM и EDF не применяются в явном виде в SMP, поскольку в этом классе систем они не оптимальны. В том числе ввиду влияния эффекта Далла (Dhall's effect), от которого свободны такие методы, как RM_US/SM_US и многочисленные многопроцессорные модификации EDF. Касательно последних встает вопрос об их применимости в промышленности, ввиду их явной академичности. Во всяком случае, об их серьезном применении в промышленности для решения реальных задач на реальном же железе ничего не известно (впрочем, буду рад переубедиться).
Все замечания отношу исключительно к Hard Real-Time системам, поскольку Soft являются утопией. Там, где не требуется Hard можно обойтись и без Real-Time. Если цена пропуска дедлайна не имеет значения, не имеет смысла и заморачиваться с RTOS.
P.S. Прошу прощения, запостил не в ответ.
Все замечания отношу исключительно к Hard Real-Time системам, поскольку Soft являются утопией. Там, где не требуется Hard можно обойтись и без Real-Time. Если цена пропуска дедлайна не имеет значения, не имеет смысла и заморачиваться с RTOS.
P.S. Прошу прощения, запостил не в ответ.
Тема планирования для SMP многократно более сложная, чем для систем с одним процессором. Статья не затрагивает SMP-планирование практически ни в каком виде. Дело в том, что вся теория RT-систем обычно подразумевает планирование CPU, но вполне применима к планированию доступа к сети и к дискам. А сетевые интерфейсы и диски уже не являются «одинаковыми с точки зрения планировщика» как ядра процессора. Тут как раз и выясняется что старая, хорошо изученная область остается востребованной и вполне применимой к реальности.
Более того, замечу, что существует огромный пласт задач и систем их решения, в которых узким местом является именно диски и сеть. В основном, речь про задачи связанные с обработкой больших объемов данных.
Есть ряд примеров, в которых применения hard-дедлайнов делает систему необоснованно дорогой и недоутилизированной. Например, если в системе есть задача, которая в среднем выполняется 10 мс, а в худшем случае 1 сек (что, кстати, вполне соответствует профилю времени записи на современных HDD). По логике hard-RT-систем мы должны планировать все исходя их худшего случая, что приведет к максимальной утилизации диска в 1%.
HDD в этом смысле не исключение, для CPU можно легко представить алгоритм, скажем, поиска мишени на изображении, с сильно различающимся среднем и худшем временами выполнения.
Более того, замечу, что существует огромный пласт задач и систем их решения, в которых узким местом является именно диски и сеть. В основном, речь про задачи связанные с обработкой больших объемов данных.
Есть ряд примеров, в которых применения hard-дедлайнов делает систему необоснованно дорогой и недоутилизированной. Например, если в системе есть задача, которая в среднем выполняется 10 мс, а в худшем случае 1 сек (что, кстати, вполне соответствует профилю времени записи на современных HDD). По логике hard-RT-систем мы должны планировать все исходя их худшего случая, что приведет к максимальной утилизации диска в 1%.
HDD в этом смысле не исключение, для CPU можно легко представить алгоритм, скажем, поиска мишени на изображении, с сильно различающимся среднем и худшем временами выполнения.
Дело в том, что вся теория RT-систем обычно подразумевает планирование CPU
Вот тут немного не соглашусь, зарубежные труды по этой теме уже много десятилетий приводят примеры из разных областей.
Поскольку трудов по применению классики в новых условиях не предвидится, хотелось бы верить, что будет в будущем статья на эту тему, как раз раскрывающая эти тезисы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scheduling: мифы и реальность. Опыт Яндекса