RTOS vs не RTOS , да ёшкин кот!!!

[Majestio]

Буэнос, ночес амигос!

Вот такая тема. Туеву хучу времени убил на ее исследование. Да, возможно, "недоисследовал", поэтому и создаю эту тему. Есть "два кита" в работе ПО:

1. Точность исполнения кода по времени (детерминированность)
2. Скорость исполнения кода

Как показали "глубинные исследования" - одновременно это обеспечить крайне-крайне проблематично! Итак, на "разделочной доске" типичный Линукс с не-RTOS ядром и QNX (звезда буржуйских банкомётов и систем бронирования). Хотя, по честноку и для общего развития - щя QNX все больше внедряется в Embedding (слилcя?). Сейчаc они даже свой GUI стандартный рабочий (Photon) стол похерили!

Ланна. Поплачем потомъ!

И так. На раздtлочной доске "не RTOS":

• Монолитное ядро
• Вызовы происходят максимально быстро на уровне ядра
• А вот скорость обработки ни как не ограничена, типа "ну как получается" (прямые вызовы планировщик не контроллит)

На разделочной доске "RTOS":

• Микроядро + куча сервисов в user space
• Вызовы происходят не так быстро, ибо IPC несколько тормознуто
• Скорость обработки ограничена исключительно планировщиком

Вопрос: куда ехаем?

Для справедливости нужно сказать, что Венда, с какого-то времени перешла на гибридный режим: какая-то часть в ядре (с "ядерными" вызовами), какая-то часть модульная (но, не уверен, что в юзерспейсе)

Пожалуйста, высказывайтесь, критикуйте и уничтожайте!!!

[Qraizer]

Ядро у Винды RTOS. Но на одном ядре много не напрограмишь, без юзерспейса обойтись никак. Но можно исхитриться в юзерспейс вынести всё некритичное, и тогда ок. Не уверен, что хороший метод, но он есть.
Под реальным временем, вообще говоря, понимается не минимальное время реакции софта, а максимальное гарантированное время реакции. Если типичное время реакции, скажем, 1мкс, но оно плавает, как в Винде с юзерспейсом, это ни разу не реал-тайм. Если гарантированное время 10мс, и оно действительно гарантировано быть максимальным, это реал-тайм. Другое дело, что это самое максимальное гарантированное может не устроить, но это уже вопрос к конкретной реализации.

Сообщение отредактировано: Qraizer - 20.12.25, 19:23

[D_KEY]

Цитата Qraizer @ 20.12.25, 19:22

Ядро у Винды RTOS.

Почему ты так решил? Вроде в документации нигде этого нет. Быстрый гугл говорит, что windows kernel это GPOS.

[Qraizer]

Об этом говорят свойства её ядерного шедулера. Он планирует жёстко по приоритетам, и в документации указаны пределы активности на каждом уровне.

P.S. Справедливости ради следует отметить, что конкретные драйверы могут нарушать это аспекты. Это не контролируется, как должно было бы быть в настоящей RTOS. Но если играть по правилам, то требованиям реального времени ядро удовлетворяет.

Сообщение отредактировано: Qraizer - 22.12.25, 04:53

[Majestio]

На счёт винды - интересно, я загуглил. Получил, что Microsoft явно позиционирует Windows как soft real-time (в Windows IoT Enterprise с 21H2 ввели "soft real-time" режим с изоляцией ядер, но даже там это не hard RT). Стандартная Windows - это general-purpose OS (GPOS), но не RTOS. Нет жёстких гарантий детерминизма. Даже real-time потоки могут быть задержаны из-за DPC (Deferred Procedure Call) /ISR (Interrupt Service Routine), которые выполняются на повышенном IRQL и могут "залипать", page faults, системных процессов, power management и т.д. Латентность "плавает" - типично микросекунды/миллисекунды, но worst-case может быть десятки мс или больше. Даже при идеальном коде (без плохих драйверов) ядро не даёт гарантий на максимальное время реакции. Нет механизмов вроде priority inheritance по умолчанию для всех ресурсов (Windows полагается на random priority boosts или developer'а), нет полной изоляции от системных активностей.

[D_KEY]

Кажется, тут есть о чем поспорить и в чем разобраться. Но что-то лень

[Qraizer]

Majestio, ты расписал юзер-мод. Юзер мод весь работает на IRQL == 0, + разве что APC, для которых IRQL == 1. Подсистема шедулера юзермода, включая объекты синхронизации, работает на IRQL == 2, и это максимальный уровень для всего, что может синхронизироваться и тем более свопиться.
Я говорил о кернеле. Там нет никаких рандомов, всё чётко по приоритетам с (к сожалению, лишь) рекомендациями по времени занятия IRQL. IRQL > 2 всё жёсткое и точное. В теории. Если попытаться залипнуть в мьютекс или не дай бог допустить страничный отказ, шедулер с его IRQL == 2 немедленно будет отложен как низкоприоритетный, и твой код словит блюскрин.

Добавлено 22.12.25, 18:10

Цитата Majestio @ 22.12.25, 16:22

Даже real-time потоки могут быть задержаны из-за DPC (Deferred Procedure Call) /ISR (Interrupt Service Routine)

Потоки TIME_CRITICAL это всё ещё PASSIVE, у которого IRQL == 0

[Majestio]

Цитата Qraizer @ 22.12.25, 18:03

Majestio, ты расписал юзер-мод

Это ты в каком месте увидел, что я говорил про IRQL == 0?

Цитата Qraizer @ 22.12.25, 18:03

Я говорил о кернеле. Там нет никаких рандомов, всё чётко по приоритетам с (к сожалению, лишь) рекомендациями по времени занятия IRQL

В этом принципиальная разница! Microsoft действительно документирует рекомендации (guidelines), чтобы код на повышенном IRQL (>2) выполнялся быстро (обычно микросекунды). Но это именно рекомендации для разработчиков драйверов, а не жёсткие гарантии ядра. Ядро не гарантирует лимиты, не гарантирует, что код не превысит их. Плохой драйвер может "залипнуть" на высоком IRQL надолго - это приведёт к снижению производительности или даже к зависанию системы. DPC могут накапливаться в очереди, ISR зависеть от hardware, и нет механизма принудительного ограничения времени.

Впрочем, тебе лучше поспорить с самими Мелкомягкими - они-то уже признались

[Qraizer]

Так я это и сам сказал, ещё в начале. И тем не менее, ты всегда можешь перенести в кернел критичную обработку данных, не спеша отдавая в PASSIVE LEVEL уже результаты. Рассчитать гарантии откликов несложно, они зависят от количества IRQL выше твоего. Если тебе не хватает лимитов времени... ну, тут либо наращивать мощность железа, либо увеличивать отклик в N раз, отдавая низкоприоритетным ядерным потокам кванты, ...либо читерить и не отдавать, что как раз и будет тем самым нарушением, которое тебя в Windе не устраивает.
MS не собирась позиционировать свою ОСь как RTOS. У неё в планах было выпустить десктоп, а не эмбеддед. Поэтому жёсткого контроля и нет. И на десктопе и не должно быть. Пользователям не нравится, когда их любимые слитые с торрентов паки внезапно вырубают USBю там или принтера. И всё из-за того, что строгий ядерный шедулер прибил высокоприоритетный поток, исчерпавший свой лимит на кванты. Но тебе никто не мешает сконфигурировать ОСь так, чтобы тебе ничего не мешало. Выкинуть ненужное железо, проапгрейдить нужное, наставить исключительно сертифицированных драйверов и определиться с нужным тебе IRQL. Сложно? Ну так ты, вероятно, с настройкой RTOS дела не имел. Они-то тоже не с потолка свои гарантии берут и не волшебным образом обеспечивают. За всё нужно платить.

Сообщение отредактировано: Qraizer - 23.12.25, 19:28

[Majestio]

Цитата Qraizer @ 23.12.25, 19:20

Они-то тоже не с потолка свои гарантии берут и не волшебным образом обеспечивают. За всё нужно платить

Вот они и платят - уменьшением скорости работы своей оси. Да, за всё нужно "платить", и за жёсткий контроль процессов по времени. По большому счёту - винда более "быстрая", а QNX - менее, но за то 100% предсказуемая по "временам".

Скрытый текст

[Qraizer]

Круто. Пощупаешь, расскажешь?

Добавлено 25.12.25, 10:10

Цитата Majestio @ 24.12.25, 17:08

Да, за всё нужно "платить", и за жёсткий контроль процессов по времени.

Та дело не во времени ж. Я в своём первом посте об этом писал. Ты поди настрой её, чтоб всё работало, как планируется.

[Majestio]

Цитата Qraizer @ 25.12.25, 10:09

Круто. Пощупаешь, расскажешь?

Увы, не пощупаю и не расскажу. И это пичяль!!! Это на виртуалке "мемориал". Там нет репозитариев, нет и систем разработки. А сейчас QNX вообще выпилила графический UI, и ушла вообще и полностью а embed. Да, я пробовал пару-тройку раз поставить хотя бы binutils + с/++. Облом. Возможно у меня просто знаний не хватает, а возможно - одно из двух! Но "пичялька" у меня по этому поводу - просто зашкаливает

Цитата Qraizer @ 25.12.25, 10:09

Та дело не во времени ж. Я в своём первом посте об этом писал. Ты поди настрой её, чтоб всё работало, как планируется.

Ты можешь "отнекиваться" скока угодно. Но именно эта концепция RTOS и декларируется. Это её суть.

[Qraizer]

Ну так я разницы-то и не увидел.