Когда не нужна ОС РВ?, навеяно постом "Я написал RTOS" Опции

[Виктория]

Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972
загубил на корню возможность обсуждения, я и открыла новую тему.

Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ...
Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

Приглашаю всех к дискуссии.

[zltigo]

Мое мнение однозначно - ОС РВ нужна тогда, когда лень писать качественный софт (или нет на это времени) и есть лишние ресурсы у железа. Во всех остальных случаях не нужна. Качественный софт это такой, который при выполнении заданных требований потребляет минимум ресурсов (всех, байтов, тактов, и т.п.)

Столь усеченно-однобокую трактовку "качественно софта" оставлю на Вашей совести.
А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -
RTOS позволяет делить ресурсы в случае их нехватки. А когда ресурсов "завались" можно и бездумно и беcсистемно заниматься чем-нибудь другим.

[SM]

А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -
RTOS позволяет делить ресурсы в случае их нехватки.

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

[Olej]

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

Нет. Это не так.
Почему это вы решили, что достаточно простые (а другими они быть и не могут) "ручные" реализации будут оптимальнее, чем те, которые "обкатаны", скажем, в течении 20-30 лет? Ну и что, станете вы писать адаптивную или спорадическую диспетчеризации параллельных веток вместо round-robin для единоразового использования? И сколько ещё скрытых ошибок вы оставите в "ручной" реализации?

А если ресурсов хватает (впритык),

Если до такой степени впритык - то это признак того, что платформа выбрана неадекватная, и "выбирателя" пора гнать с работы... . Такая постановка ещё могла бы быть правомочной ... лет 20 назад.

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

[SM]

Почему это вы решили, что достаточно простые (а другими они быть и не могут) "ручные" реализации будут оптимальнее, чем те, которые "обкатаны", скажем, в течении 20-30 лет? Ну и что, станете вы писать адаптивную или спорадическую диспетчеризации параллельных веток вместо round-robin для единоразового использования? И сколько ещё скрытых ошибок вы оставите в "ручной" реализации?

Это я решил, базируясь на собственном опыте (и поверьте, богатом) построения многоканальных систем цифровой обработки сигналов. Где присутствует очень жесткое реальное время. Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом в бесконечном цикле. С жесткой оговоркой - сколько тактов процессора разрешено на обработку одного состояния в каждом КА. Все остальные схемы, включая всевозможные самодельные диспетчеры, готовые и опробованные RTOS, и т.п. проиграли.

А если ресурсов хватает (впритык),

Если до такой степени впритык - то это признак того, что платформа выбрана неадекватная, и "выбирателя" пора гнать с работы... . Такая постановка ещё могла бы быть правомочной ... лет 20 назад.

Категорически не согласен. В части задач разрабатывается параллельно программное обеспечение, микропроцессорное ядро под него и обвязка периферии, которая потом размещается в полностью заказной микросхеме. Кол-во ресурсов - это площадь - это доллары и центы. А зачастую экономия 10-ти центов полностью определяет выигрыш в конкуррентной борьбе. Так что ресурсы это золотой запас, о котором я думаю в первую очередь. (я сам являюсь проектировщиком RTL и топологии своих ИМС, кроме решения самих ДСП-задач, и разработки системы в целом).

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

Пока таковыми были ВСЕ решаемые мной задачи ЦОС. Они касались обработки голосовых каналов и каналов цифровой передачи данных (модемы). А также и не совсем ЦОС... Я еще не встретил ни одного чужого (не самодельного) планировщика, который был бы оптимален с моей точки зрения.

, или bios (как заметил SM)?

Я заметил не bios, а DSP/Bios, что является торговой маркой и названием полноценной RTOS.

[Olej]

Это я решил, базируясь на собственном опыте (и поверьте, богатом) построения многоканальных систем цифровой обработки сигналов. Где присутствует очень жесткое реальное время. Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом в бесконечном цикле. С жесткой оговоркой - сколько тактов процессора разрешено на обработку одного состояния в каждом КА. Все остальные схемы, включая всевозможные самодельные диспетчеры, готовые и опробованные RTOS, и т.п. проиграли.

Ну вот вы сами же и говорите, что это - достаточно узкая область, в ней работающие законы нельзя переносить на "вообще".

Категорически не согласен. В части задач разрабатывается параллельно программное обеспечение, микропроцессорное ядро под него и обвязка периферии, которая потом размещается в полностью заказной микросхеме. Кол-во ресурсов - это площадь - это доллары и центы. А зачастую экономия 10-ти центов полностью определяет выигрыш в конкуррентной борьбе. Так что ресурсы это золотой запас, о котором я думаю в первую очередь. (я сам являюсь проектировщиком RTL и топологии своих ИМС, кроме решения самих ДСП-задач, и разработки системы в целом).

Да, и это ещё более суженная сфера применения, когда нечто нужно вогнать "под крышку чипа". Но далеко не всем этого хочется ...

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

Пока таковыми были ВСЕ решаемые мной задачи ЦОС. Они касались обработки голосовых каналов и каналов цифровой передачи данных (модемы). А также и не совсем ЦОС... Я еще не встретил ни одного чужого (не самодельного) планировщика, который был бы оптимален с моей точки зрения.

Пока таковыми были все решаемые вами задачи ЦОС в очень узкой сфере потоковой передачи информации (голос, модем). А вот в хорошо известной мне области - радиолокационных системах, задача потоковой ЦОС (и не менее напряжённой ЦОС) - это только одна из сопутствующих параллельных задач (выделение отметок, целеуказание, и др. и др.) - и при неэффективном их планировании сама задача ЦОС никому и даром не нужна (т.е. с большой вероятностью просто некому уже будет наслаждаться результатами её решения ).

Так почему вы так категорично считаете, что из "таковости" ВСЕХ решаемых вами задач - вытекает, что и все прочие должны поступать и думать только так?