"Тормозные" 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 и т.п. ).

[yuri_t]

Применение Segmented Interrupt Architecture в малых RTOS - это (ИМХО) просто достаточно
неуклюжая попытка перетащить механизм обработки прерываний из больших OS (в Velocity -из Unix).
Для небольших по своей природе RTOS - это как "авианосец в домашней ванной(с)".

[AlexandrY]

Применение Segmented Interrupt Architecture в малых RTOS - это (ИМХО) просто достаточно
неуклюжая попытка перетащить механизм обработки прерываний из больших OS (в Velocity -из Unix).
Для небольших по своей природе RTOS - это как "авианосец в домашней ванной(с)".

Понятие "малая" RTOS слегка сместилось за последнее время.
Такие RTOS как RTXC, ThreadX, VxWorks, Nucleus и т.д. спокойно нынче размещаются в дешевых чипах на Cortex-M3 или Cortex-M4 даже без внешней памяти.
А в них сегментированные прерывания ключевая фишка. И очень удобная я вам скажу.
Сам их использую вовсю даже в простейших контроллерах узлов оборудования.
Потому что когда у вас в чипе количество периферии генерирующей прерывания переваливает за несколько десятков,
хочешь не хочешь начинаешь искать способы облегчения процедур ISR не отказываясь от сервисов RTOS.
А в этих осях есть четкая градация на легкие и тяжелые ISR. Легкие могут использовать всего один сервис RTOS - это вызов тяжелой ISR.
Но вход в легкие ISR почти такой же быстрый как во FreeRTOS, uCOS и т.д.
А тяжелая ISR может уже использовать почти все сервисы RTOS , которые не приводят к ожиданиям.
Но вход в тяжелую ISR почти повторяет динамическую процедуру создания новой задачи. Т.е. выделение стека, управляющих структур и т.д.

[VslavX]

Но вход в тяжелую ISR почти повторяет динамическую процедуру создания новой задачи. Т.е. выделение стека, управляющих структур и т.д.

А обязательно использовать именно "тяжелую ISR" (aka DPC/BottomHalf)? Я спокойно выношу всю эту часть в приоритетный поток и вместо приглашения "тяжелой ISR" просто пробуждаю его. "Реальный" реалтайм все равно будет только в легкой ISR, а тяжелые все равно откладываются в очередь.