Имеет ли смысл смешивать ОСРВ и циклический исполнитель?

Question

В небольшом проекте встроенной системы у нас есть некоторый код, который мы хотели бы запустить в потоке, поэтому мы решили построить его поверх встроенной RTOS (eCos).

Ранее мы использовали циклический исполнитель в main(), который управлял задачами, каждая из которых была реализована как конечный автомат.Для некоторых задач мы столкнулись с проблемами, когда задачу приходилось разбивать на множество мелкозернистых состояний, что делало код еще более сложным.

При переходе на RTOS мы обнаружили, что использование памяти для стека каждого потока быстро увеличивается, если мы выделяем каждой отдельной задаче собственный поток.(у нас есть только 64 КБ, и нам нужна память для наших коммуникационных буферов)

Мы рассматриваем возможность использования одного потока для нашей задачи связи и другого потока для циклического исполнительного механизма.Циклический руководитель будет управлять другими логическими задачами.

Имеет ли смысл вот так смешивать ОСРВ и циклический исполнитель?

Answer 1

Это совершенно верный дизайн.
В одном из наших продуктов мы использовали аналогичную конструкцию, в которой асинхронные каналы ввода-вывода (TCP/IP, 2 последовательных потока) выполняли свои собственные задачи, а у нас была «основная» задача, которая отвечала за несколько областей функциональности. .

Думайте о задачах как о механизме разделения, позволяющем упростить дизайн.

Answer 2

Да, наличие циклического исполнителя в одном потоке ОС, выполняющего несколько «задач», может иметь смысл.Фактически, если две задачи не конфликтуют с потребностями планирования (одна должна блокироваться, одна имеет более высокий приоритет, чем другая, а задача с низким приоритетом требует много времени для выполнения и т. д.), я бы рекомендовал поместить их в один поток.

Это особенно актуально в случае, когда вы используете облегченную RTOS без защиты памяти:отдельные потоки не безопаснее, чем один поток (нет защиты адресных пространств MMU), фактически они потенциально более опасны из-за большей потребности в защите одновременного выполнения.Даже если ваша схема IPC надежна и не подвержена неправильному использованию программистами, ее накладные расходы обычно не равны нулю, поэтому отказ от нее может привести к увеличению производительности.

Answer 3

Если вы посмотрите FreeRTOS, они на самом деле запускают в задаче другой планировщик, вроде :)

И, как говорят другие, в дизайне нет ничего плохого.Нет причин, по которым (некоторые из) ваших задач не могут быть конечными автоматами, если есть четкий способ выразить что-то таким образом.

Answer 4

Это правильный дизайн, но мне кажется, что я вообще упустил причину наличия этой ОС.

Какие возможности ОС вы планируете использовать?

Судя по доступной информации, кажется, что в конечном итоге вы перенесете сложность задач в свой новый основной цикл.