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

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

***но известное (т.е., например, в диспетчере: при сортировке очереди на выполнение прерывания запрещаются не на все время сортировки (которое зависит от размера очереди и поэтому не предсказуемо), а периодами - на время анализа очередного элемента (которое известно)***

Проблемы будут.
Например если список линейный, то если в данный момент(когда прерывания запрещены) поле next у текущего элемента имеет одно значение, то если вы прерывания разрешили, а потом опять запретили...поле next может быть уже совсем другим. а самого элемента this - может уже и не быть в очереди. Кто то его вытащил.
То есть кто-то может вам просто "оборвать" список. Это будет трудноуловимой ошибкой, поскольку получится при коллизии доступа к текущему или следующему элемента списка.

То есть если вы работаете с элементом - монопольно, вы не имеете права брать next от текущего элемента, запоминать и использовать его в следующем "такте" монопольной работы.
Если же вы будете думать что текущий в "такте" монопольной работы - действительно в списке(поскольку в предыдущем такте он там был!) - вас ударит с другого конца. Если его уже вытащили оттуда, его поле - next - будет nil.
Как будем выкручиваться?