|
|
=== Прежде всего, Автор совершенно правильно указывает на то, что недопустимо рассматривать свойства RTOS в отрыве от всей системы реального времени. Однако данное утверждение является совершено избыточным - RTOS создаются именно исходя из потребностей систем реального времени и только для систем реального времени.
Позвольте с Вами не согдаситься. RTOS как говорится RTOSом, но она абсолютно ничего не решает. Его конфигурить под задачу надо. И я знаю много случаев, когда кривые руки запарывали практически любую задачу на практически любой RTOS. Собственно, SM уже высказал мнение, что RTOS это придаток к основной задачи. Типа подушечки при геморрое. Т.е. в принципе без нее можно и обойтись, но...
Поэтому, подушечка должна четко соответствовать геометрии зада, а ее упругость - форме заболевания. При этом (я правда не очень разбираюсь в таго рода подушечках) зад и подушечка образуют как бы систему, и я уверен, что не всякая подушечка может быть согласована с вышеупомянотым седалищем...
=== Далее Автор по непонятной мне причине выделяет системы реального времени для ЦОС в отдельный класс, подразумевая коммуникационные задачи.
И где конкретно сее непотребство подразумевает Автор???
=== Не вижу принципиальной разницы между коммуникационными задачами и другими hard realtime задачами - например, задачами автоматического управления оборудованием. Замечу, что задачи автоматического управления оборудованием часто являются более сложными, так как они, как правило, накладывают дополнительное требование на процесс обработки сигналов, отсутствующее в коммуникационных задачах ЦОС - внесение минимальных задержек обработки для уменьшения фазовых сдвигов в петле управления.
Да за ради Бога! Афтар не видет криминала! Пусть в задачи ЦОС включат задачи управления.
=== Данное Автором определение системы реального времени чрезмерно запутанно и при этом неполно - я так и не понял, что Автор имел в виду под временем прохождения реперных точек. Время прохождения любой точки в программе равно одному такту процессора в любой системе, вне зависимости, реального времени или нет.
Ну можно же определить в программе некие контрольные точки? Например получение каких либо данных или окончание их обработки...
=== Далее Автор из такого размытого определения делает несколько ложных выводов. Прежде всего, если на один (последовательный) процессор проектировщиком возложено исполнение нескольких задач - они могут исполняться только разделяя между собой процессорное время. Тем не менее, premptive multitasking совершенно не является необходимым для подобных систем - Автор же далее говорит про "тики" (т. е. кванты времени) как обязательном их свойстве.
А... как иначе-то???
=== Вывод о том, что задачи не должны прерывать друг друга, также ложен...
Не много не понял, а при чем тут моя статья? Ну, ясно дело, это хорошо на каждую задачу по процессору...
=== Приведу всего три примера.
первый пример не понял вообще... второй пример не корректен и т.д.
Давай те я лучше свой пример приведу? Вот делал я на одном проце следующие вещи: сначасла МР3, потом эквалайзер, 3D-саунд и т.п. И нет тут задач с меньшим приоритетом. В противном случае просто звук начнет прерываться. А вот спорадически возникающие задачи, типа пересчета коэффициентов эквалайзера, возникают... И чо делать?
=== любую систему реального времени следует реализовывать в виде поллинга всех задач в одном цикле, и в каждом цикле поллинга исполнения каждой задачей всей скопившейся работы. Замечу, что такая система разделения времени, действительно, часто применяется, так как она очень простая и в ней отсутствуют многие сложности, характерные для более навороченных систем - в ней нет проблем синхронизации паралельных задач со сложно обнаруживаемыми дедлоками, инверсией приоритетов и просто неатомарным доступом к управляющим структурам.
Делал я и это. Только вот сейчас у меня не получается сделать полинг для спектральной обработки на 2048 точек и кучи измерителей, которые хавают по входу отсчетов по 200... И снова: чо делать-то???
=== реальные задачи часто не укладываются в описанную примитивную модель.
Ага. Это точно. Афтар на такое и не претендует.
=== Кроме того, возможность использования флага (т. е. фактически критической секции) как единственного универсального средства синхронизации в hard realtime задачах, этакой панацеи от всех проблем синхронизации, вызывает мои сильнейшие сомнения.
Флаг не критическая секция. Критическая секция возникает при обращении к флагу. Кстати, в описанном случае (аудиоцентр), ничего кроме флага мне не нужно.
|
|
E-mail: 
info@telesys.ru
