"Тормозные" RTOS и запрещение прерываний Опции

[yuri_t]

В последнее время прочитал несколько сообщений в русскоязычных конференциях по электронике (Electronix, Caxapa)
о том, что есть замечательные варианты повышения быстродействия RTOS - "без блокировки прерываний вообще,
без spin-lockов, без циклов"(цитата) .

На эту тему замечу:

1) Системы с запрещением прерываний на время изменения системных данных надежно работают в любых проектах
и с любыми CPU.

2) Системы без запрещения прерываний на время изменения системных данных можно разделить на две категории

- системы, которые работают только в проекте автора (как правило, единственном) - здесь без комментариев

- Segmented Interrupt Architecture - системы, в которых прерывания не запрещаются, а просто останавливается
переключатель контекста. Если во время прерывания появляется условия, требующие переключения контекста,
то эти условия помещаются в специальную очередь и обрабатываются вне прерываний.
Такой подход кажется привлекательным на первый взгляд, но на практике имеет столь серьезные недостатки,
что мне известно только 2 коммерческих RTOS (CMX, Velocity) использующих такой подход. Для тех, кому
интересны детали, рекомендую статью W.Lamie (автор ThreadX RTOS) "Pardon the Interruption: Two Approaches to
RTOS Interrupt Architectures"

В общем, если вы не хотите получить случайные, совершенно непонятные баги и проклинать тот день, когда решили
связаться с операционной системой - используйте RTOS с запрещением прерываний (VxWorks, pSOS, ThreadX/Nucleous,
TNKernel, FreeRTOS, scmRTOS и т.п. ).

[VslavX]

что мне известно только 2 коммерческих RTOS (CMX, Velocity) использующих такой подход. Для тех, кому
интересны детали, рекомендую статью W.Lamie (автор ThreadX RTOS) "Pardon the Interruption: Two Approaches to
RTOS Interrupt Architectures"

ИМХО, статья несколько лукавая - "смотрите как хорошо в UIA и как не очень хорошо SIA", при этом приводится ряд спорных аргументов против SIA. Но, как ни странно, в целом выводы правильные . UAI имеет тот большой плюс что очень прост в реализации, и просто писать обработчики прерываний в приложениях. И этот подход хорошо подходит для простых OS, где системные структуры (данные с которыми ОС работает при обработке вызова - очереди задач, системные объекты и прочее) достаточно маленькие и простые. Поэтому секции кода с запрещенными прерываниями небольшие и RT страдает несильно.
А теперь рассмотрим ситуацию более сложной системы. У меня, например, есть реальная ситуация когда TNKernel выполняется на CortexM3 в непривилегированном режиме под отдельным специальным супервизором. При этом издержки на tn_interrupt_lock/unlock становяться достаточно заметными (вызываются привилегированные сервисы супервизора через swi), и уже не столь малыми по сравнению с вариантом на SIA. Второй пример (тоже скоро может перестать гипотетическим) - многоядерность. В таком варианте тоже простым interrupt_lock/unlock не обойдешься.
Если брать совсем уж сложные системы - типа Windows/Linux, то они все исповедуют очень развитую модель SIA - DPC/BottomHalf. И делали это они не красоты ради, а потому что выхода просто не было - системные структуры настолько сложны и секции кода их обрабатывающие могут занимать настолько долгое время, что RT был бы совсем уж плох.
Ну а "возвращаясь к нашим баранам" - UIA почти идеален для простых ОС, тут почти без вариантов. Рассматривать вариант SIA, ИМХО, стоит только в том случае если нужен совсем-совсем жестокий RT. Могу сказать в цифрах - я измерял interrupt latency на TNKernel (модель UIA) на lpc1768@100mhz - так максимальное время задержки было примерно 4uS. Оно конечно зависит от того что исполняется в данный момент, при тесте у меня шел активный обмен по UDP echo и сервисы ОС использовались достаточно активно и сторонних прерываний было достаточно. Если кому-то нужен RT более жесткий чем 4uS - то тут явно не процессор и RTOS надо использовать, SIA тут почти не поможет, поэтому все разговоры про SIA в простых ОС - это обычно просто популизм. Да, возможно улучшится незначительно RT - при соблюдении массы условий, но в целом системные вызовы будут работать медленее - так как код будет сложнее, и общее быстродейтсивие вообще может упасть.

[AlexandrY]

ИМХО, статья несколько лукавая - "смотрите как хорошо в UIA и как не очень хорошо SIA", при этом приводится ряд спорных аргументов против SIA. Но, как ни странно, в целом выводы правильные .

Эти пацаны из Express Logic толкают эту свою статью уже лет 6 , если не дольше.
С тех пор наука давно ушла вперед.
И между двумя ихними крайностями есть куча промежуточных решений.
Например та же RL ARM библиотека которая пожалуй покомпактней будет TNKernel может вызывать некоторые сервисы RTOS в незапрещаемых прерываниях.
Т.е. случай напоминающий сегментированную модель прерываний (SIA)
Но строится это на привязке к архитектуре Cortex-M3.