|
|
Позвольте выступить в качестве жесткого оппонента по поводу данной статьи. Заранее должен предупредить, что я не имею опыта использования каких-либо чужих RTOS. Тем не менее, опыт проектирования систем реального времения я имею. Как правило, программное обеспечение таких систем сводилось к упоминаемому ниже циклу поллинга совместно с иерархией прерываний.
Прежде всего, Автор совершенно правильно указывает на то, что недопустимо рассматривать свойства RTOS в отрыве от всей системы реального времени. Однако данное утверждение является совершено избыточным - RTOS создаются именно исходя из потребностей систем реального времени и только для систем реального времени.
Далее Автор по непонятной мне причине выделяет системы реального времени для ЦОС в отдельный класс, подразумевая коммуникационные задачи. Не вижу принципиальной разницы между коммуникационными задачами и другими hard realtime задачами - например, задачами автоматического управления оборудованием. Замечу, что задачи автоматического управления оборудованием часто являются более сложными, так как они, как правило, накладывают дополнительное требование на процесс обработки сигналов, отсутствующее в коммуникационных задачах ЦОС - внесение минимальных задержек обработки для уменьшения фазовых сдвигов в петле управления.
Данное Автором определение системы реального времени чрезмерно запутанно и при этом неполно - я так и не понял, что Автор имел в виду под временем прохождения реперных точек. Время прохождения любой точки в программе равно одному такту процессора в любой системе, вне зависимости, реального времени или нет. Кроме того, не формализовано понятие "обработка данных" - под этим процессом можно понимать все, что угодно. При этом неявно вводится понятие задачи - как будто это понятие само собой разумеется. Точная постановка требований, предъявляемых к исполняемым в системе реального времени задачам, является ключевым для корректного проектирования системы. Абстрактные рассуждения на уровне интуитивных понятий здесь недопустимы.
Далее Автор из такого размытого определения делает несколько ложных выводов. Прежде всего, если на один (последовательный) процессор проектировщиком возложено исполнение нескольких задач - они могут исполняться только разделяя между собой процессорное время. Тем не менее, premptive multitasking совершенно не является необходимым для подобных систем - Автор же далее говорит про "тики" (т. е. кванты времени) как обязательном их свойстве.
Вывод о том, что задачи не должны прерывать друг друга, также ложен. В качестве его обоснования приведены расплывчатые рассуждения о том, что всех ресурсов системы реального времени должно хватать на все задачи одновременно. Однако реальные системы реального времени всегда являются компромиссом между надежностью и стоимостью. Если система должна управлять подрывом атомной бомбы - вероятно, лучше поставить много процессоров, каждый из которых исполняет одну примитивную задачу. Часто в системах реального времени существует потребность исполнения некоорых некритичных задач в фоновом режиме, при этом ограниченное время отклика таких задач не является требованием. Кроме того, часто разные задачи предъявляют различные требования ко времени отклика на внешнее событие - время отклика на внешнее событие является тем самым самым важным ресурсом, за который всегда конкурируют hard realtime задачи. В конце концов, во многих случаях сложно априорно гарантировать время выполнения задачей текущей работы - но может требоваться безопасный режим обработки ситуаций перегрузки процессора, когда критичные задачи, такие, как контуры обеспечения безопасности, продолжают нормально работать за счет деградации менее критичных задач.
Приведу всего три примера.
1. В системах автоматического управления часто существуют несколько контуров управления с различными квантами управления. Внутренний быстрый и простой контур управления при этом прерывает внешний контур с более длительными рассчетами.
2. В системах, реализованных на дешевых 8-битных однокристалках, обычно задача выкачивания принятого символа из однобайтного буфера UART должна иметь наивысший приоритет, так как иначе символы будут теряться и обмен информацией с фоновой низкоприоритетной задачей мониторинга системы станет невозможен. Обычно такую задачу реализуют в виде прерывания.
3. В коммуникационных системах непрерывность процесса рассчета спектральных признаков часто менее важна, чем непрерывность маршрутизации перекачиваемых потоков данных.
При этом, если принять утверждение автора о том, что все задачи должны быть одного приоритета, и что вычислительных ресурсов всегда хватает на все задачи одновременно во всех возможных режимах работы системы, далее сразу же должен последовать простой вывод, что любую систему реального времени следует реализовывать в виде поллинга всех задач в одном цикле, и в каждом цикле поллинга исполнения каждой задачей всей скопившейся работы. Замечу, что такая система разделения времени, действительно, часто применяется, так как она очень простая и в ней отсутствуют многие сложности, характерные для более навороченных систем - в ней нет проблем синхронизации паралельных задач со сложно обнаруживаемыми дедлоками, инверсией приоритетов и просто неатомарным доступом к управляющим структурам.
Так если все так просто, зачем же многие неглупые инженеры тратят свое время на проектирование и изучение RTOS? Замечу, что Автор также не избежал соблазна спроектировать свою собственную систему. Ответ прост - реальные задачи часто не укладываются в описанную примитивную модель.
Во второй части статьи автор описывает пример диспетчера задач для коммуникационной системы реального времени. Безусловно, описываемая система представляет интерес для изучения как пример подобной системы, но ввиду всего вышеизложенного описываемая система не может претендовать ни на уникальность, ни на достаточность, ни на то, что описываемая система "типовая".
Кроме того, возможность использования флага (т. е. фактически критической секции) как единственного универсального средства синхронизации в hard realtime задачах, этакой панацеи от всех проблем синхронизации, вызывает мои сильнейшие сомнения.
|
|
E-mail: 
info@telesys.ru
