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

Question

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

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

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

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

Имеет ли смысл смешивать RTOS и циклический исполнитель следующим образом?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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