Параметры оценки архитектуры ОС, предлагаю Опции

[TMX]

Хочу обзор сделать, по существующим на рынке ОС для мк.
Не просто краткую аннотацию, такие уже есть,
например:
http://www.realtime-info.be/encyc/buyersgu...tos/Dir228.html
http://www.dspconsulting.com/rtos.html
(это просто первые в моем URL-album)
, а хочу обзирать именно конкретные подходы к построению архитектур.

Предлагаю сокращенный набор параметров для оценки архитектуры:
(их больше, просто, чтобы показать принципы)

-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)
-. Приоритеты задач (стат, динам, несравниваемые и др.)
-. Особенности переключения задач (контекст, стеки и т.д.)
-. Реализация планировщика.
-. Реализация диспетчера.
-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.
-. Предотвращение инверсии приоритетов (есть, нет, методы)
-. Реализация искл. доступа к ресурсам.
-. Контроль задач (события, таймеры и др.)
-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)
-. Реализация HAL.
-. API - предоставляемые возможности.
-. Доп. средства (GUI, TCP/IP и т.д.)
-. Общая оценка.

Результаты желаю выложить в интернет.
Примерная производительность - 4 ОС/мес, если не попрет.
Предлагаю это из шкурных соображений:
1. закончились новые идеи, а спросить не у кого.
2. последняя моя ОС получилась хороша, но вдруг изобрел велосипед?

Поэтому объявление:
Приму в дар исходники коммерческих ОС для исследовательских целей, (это не пиратство, это промышленный шпионаж).
Особо интересуют:
-. Integrity - как реализовано переключение задач без выкл. прерываний,
-. PORTOS - реализация приоритетных функций,
-. smx - реализация связных стеков задач
-. все остальные.

[merk0]

***Мнея эта тема интересует в том числе и прагматической точки зрения.
В данный момент я работаю с разработкой приложения на WinCE.
Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi??***

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

***-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)
-. Приоритеты задач (стат, динам, несравниваемые и др.)
-. Особенности переключения задач (контекст, стеки и т.д.)
-. Реализация планировщика.
-. Реализация диспетчера.
-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.
-. Предотвращение инверсии приоритетов (есть, нет, методы)
-. Реализация искл. доступа к ресурсам.
-. Контроль задач (события, таймеры и др.)
-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)
-. Реализация HAL.
-. API - предоставляемые возможности.
-. Доп. средства (GUI, TCP/IP и т.д.)
-. Общая оценка.***

Вообще-то я занимался разработкой ртос. Но ваши вопросы как то уж очень широко поставлены.
Это называется курс лекций по теме - разработка и архитектура ртос...
Как все это обсуждать в форуме?
Или вы хотите сформулировать пособие по разработке ртос для всех желающих...а оно надо? добром не кончится если все желающие станут писать ртосы. По пособиям.

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

Мое мнение в результате опыта разработки
Хорошая ртос это
1. реализованная на C++
2. четкий и компактный HAL
3. Нечто вроде микроядра с релизацией подкачки компонент ядра и других компонент оси
4. Многозадачность вытесняющая, с динамическими приоритетами
5. Синхронная - листенеры(хуки) и асинхронная активация(события) кода
6. Разделение ресурсов методом вроде синхронизирующих механизмов java. Вообще вычислительная модель java - видится как минимальная но полная. То есть ее и надо посмотреть в первую очередь.
7. Хорошая защита системы от "лома". То есть разделение прав доступа задач и тредов к программным и физическим обьектам.

8. Проблемы устойсчивости - то есть упавшая задача не должна обрушить систему целиком. Вопросы утилизации ресурсов занятых упавшей задачей и все такое.

9. Реализация "стандартных" протоколов и драйверов, вроде компортов, тср/ip и проч

... разумеется тут писать можно много и долго..это я бессистемно написал первое что приходит в голову, ...по опыту работы.

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

Вообще архитектуру ртос надо анализировать и формулировать на уровне системного анализа и математики кое какой...а как там пишут ртос отдельные авторы... все равно что изучать архитектуру зданий по конструкции избушек в деревне.