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

[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]

по моему вы увлекаетесь этими приоритетами. Как показывает практика управлять динамикой задач, просто играя их приортетами, можно только вочень узком дипазоне и потом - это очень неустойчивая система если системе необходим точный тюнинг приоритетов.
Просто софт делится на слои - более важные, менее важные, не важные, совсем никакие и проч. И реально в системе крутятся треды всего-то с 6-7 разными приритетами, вообще их не меняя никогда. И все работает стабильно. ЕСли не работает стабильно то
- что-то написано плохо(обычно как раз то что плохо работает)
- кто-то внаглую отьедает чье-то время и важная задача тормозит.
- система настолько перегружена высокоприоритетными задачами, что никакая новая идеология уже не поможет. Просто надо брать более мощный процессор и больше памяти. либо все написано из рук вон плохо.
Вообщем я бы делал приоритеты статическими, делил систему на слои и имел запас по мощности проца.
И ну их - эти повышения приоритетов по тикам. Кстати чего ради приоритет должен расти от времени? Приоритет это Важность данной задачи по отношению к другим задачам. Важность - понятие статическое. Значит и приоритет должен быть статическим.

[TMX]

По моему мнению, критерий РВ один - предсказуемость. Из этого вытекает мой интерес к приоритетам. Для инверсии приоритетов (основной проблемы для предсказуемости) достаточно трех слоев задач, обращающихся к одному ресурсу. Или в Вашей модели доступ к ресурсам зависит от слоя? Как тогда организуется доступ к памяти (особенно важно для С++)?

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

Ну как это, ради чего - существует модель анализа Deadline Monotonic, в которой приоритет задачи обратно пропорционален времени до дедлайна. Т.е. указываем время, в течение которого задача должна быть обработана - оно статическое, но если задачу не обрабатывать, то приоритет растет.