вопросо о QNX теоритичекого характера Опции

[katarsis]

Некоторое время назад QSS был куплен RIM, и немного спустя был анонсирован планшет, основанный на QNX.
меня интересуют 2 теоретических вопроса, которые я хотел бы прояснить при помощи знающих людей.
и так.
в QNX есть ряд архитектурных особенностей, который являются плюсом в пром автоматизации, но могут быть минусом в случае использовании для гаджета. а именно:
a. многозадачность. как ни странно, использование полноценной многозадачности требует дополнительных затрат по питанию.
б. есть мнение, что жесткое реально время только вредит мобильной системе. в линуксе, при вычислении приоритета процесса используется "степень интерактивности" - интерактивный процесс, занимающийся визуализацией на экран, имеет больше приоритет чем фоновый. так вот, обыграно ли это както в QNX, ведь в случае жесткого реально времени - вполне себе нормальна ситуация, когда интерактивный процесс отрисовки видео может быть прерван для подгрузки данных из интернета фоновым процессом.

как быть? что сделано в QNX, обходящие эти особенности, или может это вообще не особенности и мне все кажется?
спасибо

[_4afc_]

a. многозадачность. как ни странно, использование полноценной многозадачности требует дополнительных затрат по питанию.

Многозодачность обеспечивается в ядре ОС. Ядро маленькое. В QNX можно регулировать периоды вызова ядра.
Я уже лет 8 им не занимаюсь, но помоему в QNX4 изначально ядро дёргают каждые 25мс и это время можно уменьшить до 1мс.
В QNX6 вроде до 0.125мс можно поставить.

б. есть мнение, что жесткое реально время только вредит мобильной системе. в линуксе, при вычислении приоритета процесса используется "степень интерактивности" - интерактивный процесс, занимающийся визуализацией на экран, имеет больше приоритет чем фоновый. так вот, обыграно ли это както в QNX, ведь в случае жесткого реально времени - вполне себе нормальна ситуация, когда интерактивный процесс отрисовки видео может быть прерван для подгрузки данных из интернета фоновым процессом.

Не может. Во первых есть 3 типа планирование процессов (scheduling). Во вторых ни интернет, ни показ видео не являются отдельными процессами.
Они каждый состоят из кучи процессов со своими приоритетами.

Видеокадр заполняется с двойной буферизацией. Поэтому главное успеть декодировать новый кадр за межкадровое время.
Данные для начала поподяют из езернета в память карты - оттуда в драйвер с высоким приоритетом по прерыванию.
Далее стек TCPIP (интернета) уже будет медленно обнюхивать эти данные на предмет выуживания из них информации.

Естественно, что если идёт показ видео получаемого из интернета, и существующий буфер не успевает гасить неравномерность поступающих пакетов и их потерю - будут затыки в воспроизведении.

Передавать любой синхронный поток через пакетный канал - хреново и здесь РТОС не спасёт от его особенностей. Просто грамотно организовав систему - можно будет добиться меньшей латентности при передаче, а следовательно решить задачу с меньшим объёмом ОЗУ и на более слабом проце.

Степень интерактивности будет зависеть от радиуса кривизны рук разработчика...