"Тормозные" 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]

Статьи Ralph Moore и David Kliedermacher я читал (и не только их).

Здесь (ИМНО) две вещи

- техническая

об этом хорошо написал VslavX в этом топике

- рекламная

Например, собрался инженер покупать RTOS - a их на рынке несколько десятков и все совсем не дешевые.. Какую
выбрать? А тут ему ребята из компании, у которой RTOS имеет Segmented Interrupt Architecture и говорят: " У нас -
продвинутая архитектура, а у других - каменный век" и далее в таком же духе..
К чести производителей коммерческих RTOS, таких компаний очень мало, но "умы смущают©" - ведь большинство
инженеров не связаны непосредственно с разработкой RTOS и, следовательно, не посвящены в тонкие детали
дизайна таких систем.

[sasamy]

А тут ему ребята из компании, у которой RTOS имеет Segmented Interrupt Architecture и говорят: " У нас - продвинутая архитектура, а у других - каменный век"

И ведь они совершенно правы

[kikos]

И ведь они совершенно правы

не так давно в России кто-то запатентовал "бутылку стеклянную" ... и был бы "прав" до сих пор, если бы автора не занесло потребовать от пивных компаний отчислений за использование его изобретения. Тут его патент и кансельнули...

Сообщение отредактировал kikos - May 25 2011, 07:15

[sasamy]

не так давно в России кто-то запатентовал "бутылку стеклянную" ... и был бы "прав" до сих пор, если бы автора не занесло потребовать от пивных компаний отчислений за использование его изобретения. Тут его патент и кансельнули...

Вы об этом ?
http://electronix.ru/forum/index.php?showtopic=69735

только я не понял какое отношение патенты имеют к типу обработки прерываний в ОС

[evg123]

Несколько замечаний из собственного опытов:
1) На Cortex-M3 (Luminary) я использовал Keil-овскую RTOS "RTL"; 2) на DSP TMS320VC5509a - техасовскую DSP/BIOS.

В первом случае: a)keil декларирирует, что RTL не запрещает прерываний, что хотите, то и делайте. б) RTL предоставляет ряд механизмов: семафоров, "сигналы" (ихнее собственное понятие), с помощью которых ISR может взаимодействовать с шедьюлером RTOS.
Можно использовать как UIA так и SIA - архитектуры. Я пользовался как тем так и другим. Но официально KEIL рекомендует пользоваться SIA-подходом. Они говорят, что "у нас есть замечательный механизм сигналов; вы пишете ISR, который просто выставляет сигнал, а какая-то высокоприоритетная задача его ожидает и отрабатывает действие, в этом случае не необходимости иметь высокоприоритетные/низкоприоритетные прерывания - так как ISR выполняют только установку бита сигнала, который ловится "фактическим обработчиком прерывания" - задачей, которая ожидает этот сигнал. И этот фактический обработчик прерывания - он уже имеет приоритет". Это - они говорят - наиболее правильный подход. Т.е. SIA в чистом виде. Этим способом я пользовался. Т.е. ISR-обрабочик SPI у меня просто устанавливал сигнал, и дальше высокприоритетная легковесная задача "делала своё дело". Передача сигнала операционкой RTL делается очень быстро. (Можно посмотреть спецификации этой RTOS - они есть в документации - я на вскидку здесь их не приведу). Второй вариант: ISR обработки SPI при приёме данных может формировать небольшой массив из байт (например 32 байта) и по готовности массива отправить сигнал в высокоприоритетную задачу-обработчик, которая берёт этот массив и кдадёт его в почтовый ящик для следующей по ходу задачи. То есть ISR уже не тупая, а более "интеллектуальная". Т.е. возможны гибкие решения. И главное, что всё работает быстро.

Во втором случае DSP/BIOS - мощная RTOS, (кейловская RTL - это малютка по сравнению с ней). а) DSP/BIOS может по своему усмотрению запрещать прервания.
б)даёт ряд механизмов, из которых ISR может взаимодействовать с операционкой - в частности: семафоры (которые могут ожидаться задачами с определёнными приоритетами); вызовы программных прерываний SWI - software interrupts; выделение памяти из специальных memory pool-ов и отправка их в "очереди" или "почтовые ящики" (это стандартные "системные" объекты RTOS) - тут обилие всяческих вариантов. Т.е. можно с легкостью построить как SIA так и UIA - модель. в)Есть также изумительная абстракция драйвера. Кто-то со стороны может написать определённым образом "оформленный" модуль - "драйвер", и вы можете его подключить к своей программе и общаться с устройством на уровне "пакетов". Послал пакет/получил пакет. И всё. Но по сути тут вот что: вы из контекста задачи кладёте в некую "скрытую", организованную на memory pool-е, очередь и из контекста вашей задачи запускаете устройство в работу (например SPI или McBSP). Прерывание (ISR) этого устройства из контекста прерывания разгребает эту очередь (т.е., например отправляет все её пакеты). Если очередь переполнена (вы пытаетесь положить больше пакетов, чем позволяет её максим. длина), то ваша задача "засыпает", и проснётся только после того, когда такая возможность появится. Это порисходит всё внутри RTOS, а вы пользуетесь примитивным стандартным вызовом функции драйвера - "отправить очередной пакет".

Мой лично вывод - RTOS должна позволять и то и это (и SIA и UIA). А если нет, то что-то тут не так. (Но те RTOS, что я юзал - коммерческие, и очень толково сделаны).

[VslavX]

Несколько замечаний из собственного опытов:
1) На Cortex-M3 (Luminary) я использовал Keil-овскую RTOS "RTL";
...
В первом случае: a)keil декларирирует, что RTL не запрещает прерываний, что хотите, то и делайте.

Может быть "RTX" имелся ввиду?
Когда они пишут что не запрещают прерывания - то лукавят, конкретно в порту для CM3 используется исключение SVC. Ессно, при вызове обработчика инструкцией SVC приоритет прерываний снижается до фактического запрета. Да, очереди событий они сделали прикольные, но - жрут память, и беспомощны перед переполнением. Я точно не помню, но там кажется только один единственный сервис может быть вызван из ISR - "положить событие в очередь".

Можно использовать как UIA так и SIA - архитектуры.

Нет, насколько я понял RTX не поддерживает SIA в понимании данного топика.

Я пользовался как тем так и другим. Но официально KEIL рекомендует пользоваться SIA-подходом. Они говорят, что "у нас есть замечательный механизм сигналов; вы пишете ISR, который просто выставляет сигнал, а какая-то высокоприоритетная задача его ожидает и отрабатывает действие, в

Это стандартная практика, я много лет пользуюсь ей в TNKernel, но к SIA это не имеет никакого отношения, ИМХО.

Во втором случае DSP/BIOS - мощная RTOS, (кейловская RTL - это малютка по сравнению с ней). а) DSP/BIOS может по своему усмотрению запрещать прервания.
б)даёт ряд механизмов, из которых ISR может взаимодействовать с операционкой - в частности: семафоры (которые могут ожидаться задачами с определёнными приоритетами); вызовы программных прерываний SWI - software interrupts; выделение памяти из специальных memory pool-ов и отправка их в "очереди" или "почтовые ящики" (это стандартные "системные" объекты RTOS) - тут обилие всяческих вариантов.

Это все есть (кроме SWI который есть не на всякой архитектуре и вообще особо не нужен, и даже вреден если Вы пишете мультиплатформенный софт) и в TNKernel, которая ни разу не SIA.

пакетов, чем позволяет её максим. длина), то ваша задача "засыпает", и проснётся только после того, когда такая возможность появится. Это порисходит всё внутри RTOS, а вы пользуетесь примитивным стандартным вызовом функции драйвера - "отправить очередной пакет".

И это есть в TNKernel

Но те RTOS, что я юзал - коммерческие, и очень толково сделаны).

Ага, TNKernel тоже... ну - Вы поняли , за исключением того что она свободная, и даже свободней чем, скажем, софт под GPL