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

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

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

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

А ваша инверсия приоритетов - более запутанный вариант этого типа "взаимодействия".

[bmf]

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

Думаю вы в корне заблуждаесь исходя только из своего личного опыта, в реальных сложных задачах все очень даже переплетается, кроме дисковой системы может быть индикация или например разделяемая внешняя шина или доступ к какому-то контроллеру. Доступ осуществляется только через блокировки, и без решения на уровне OS проблемы инверсии приоритетов ваша OS реально не будет RTOS, и проблема инверсии не тогда когда ресурс заблокирован задачей с более низким приоритетом (в этом случае процессор освободит ее максимально и расчетно быстро), а когда в этот момент начинает выполняться другая задача скажем среднего приоритета, которая не знает что высокий приоритет ждет освобождения ресурса, в этом случае блокировка может затянутся на слишком долгое как для RTOS время. Такая блокировка может случаться не часто, но ее последствия...
Самый извесный пример из инета - потеря американцами своего марсохода как раз из-из отсутсвия инверсии.
для ознакомления наберите в google "mars priority inversion"