Есть ли смысл смешивать RTOS и циклический исполнитель?

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

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

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

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

Есть ли смысл так смешивать RTOS и циклический исполнительный механизм?


multithreading embedded rtos
person JeffV    schedule 22.09.2008    source источник

Ответы (4)


arrow_upward
6
arrow_downward

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

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

person Benoit    schedule 22.09.2008

arrow_upward
2
arrow_downward

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

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

person KeyserSoze    schedule 02.10.2008

arrow_upward
1
arrow_downward

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

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

person XTL    schedule 18.11.2011

arrow_upward
0
arrow_downward

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

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

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

person itj    schedule 22.09.2008
comment
Возможность вытеснения потоков позволяет нам избежать создания слишком сложного конечного автомата в задаче связи. Имея поток для коммуникационной части, код довольно прост. Если бы мы разбили его на состояние в каждой точке, которое в настоящее время имеет тип блока сна (1000), код будет в основном спагетти-кодовым беспорядком из очень маленьких состояний. Это можно сделать, однако мы предпочли бы, чтобы код был чистым и поддерживаемым. Другие конечные автоматы варьируются от простых до довольно сложных (один имеет ~ 15 состояний). Конечный автомат связи стал бы еще более удобным. - person JeffV; 22.09.2008