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

[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 - реализация связных стеков задач
-. все остальные.

[xyzzy]

-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)

Как насчет многопроцессорности? SMP, NSMP, NUMA, etc..
Еще интересный фактор - меж-процессное взаимодействие (включая методы синхронизации, в том числе распределенные.)

--zzyxy

[TMX]

-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)

Как насчет многопроцессорности? SMP, NSMP, NUMA, etc..
Еще интересный фактор - меж-процессное взаимодействие (включая методы синхронизации, в том числе распределенные.)

--zzyxy

Не, я в межпроцессорном взаимодействии не компетентен. А методы синхронизации и в однопроцессорных системах не оптимальны - например:
Если есть счетный семафор на ресурс (например блоки памяти) - часто используется при формировании сетевых сообщений, например, при реализации OSEK/NMI, при этом используется Priority Ceiling, как рекомендуется в том же OSEK/VDX. И что получается? - сообщение, захватившее ресурс, автоматически становится наиболее приоритетным, а остальные ждут его, т.е. реально используется всего один ресурс. Если сделать Priority Inheritance, то при N ресурсах высокоприоритетное сообщение будет ждать всех низкоприоритетных в худшем случае. Эта проблема, на мой взгляд, интересна для обсуждения, если ставить задачу действительно разработать систему жесткого реального времени (т.е. предсказуемую).
А многопроцессорные системы слишком сложны для моего мозга.

[RVlad]

>... Эта проблема, на мой взгляд, интересна для обсуждения, если ставить >задачу действительно разработать систему жесткого реального времени (т.е. >предсказуемую).А многопроцессорные системы слишком сложны для моего >мозга.

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

[TMX]

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

Вот-вот, я и Вас не понимаю :-). То что, все просчитать нельзя (т.е. NP-трудность), насколько я знаю, известно давно (Мок, 1984). Поэтому были предложены определенные ограничения (обзор Одсли, 1992) Зачем динамические приоритеты считать, если их не делать?
Предсказуемость, с моей точки зрения, это возможность расчета времени реакции на событие. Ну и как переключение контекста влияет на предсказуемость? В uCOS II, например переключение контекста очень быстрое, ну и что - она не предсказуема, поскольку м.б. инверсия приоритетов.
О многопроцессорных системах я читал (например, статьи Тинделла об организации обмена в таких системах), но эта область с практической точки зрения меня не интересует - просто не имею достаточной подготовки и нет реальных задач.
А ОС, как средство управлять разделяемыми ресурсами по каким-то законам, позволяющим сделать расчет времени - достойная на мой взгляд задача.
Насчет контроля сбоев ничего сказать не могу.
Мне кажется, что расчеты для многопроцессорных систем гораздо сложнее.

[RVlad]

Я думаю , что в значительной степени то - о чем мы говорим - это вопрос терминологический.
- Если говорить в терминах определений RTOS - то существует точка зрения, готорая гласит - RTOS - система ориентированная на конкретное приложение:=> если для приложения можно выполнить некоторые определнные требования real-time-a , то и система на основе которой построено это приложение является RTOS. Соответственно различные коммерческие RTOS и делаются для того , чтобы улучшить показатели (и расширить сферу применимости данной OS как RTime).
- Другой вопрос, что при проектировании достаточно сложных RT приложений значительно легче разбить его на несколько слабосвязанных задач (если это получаеться) и разместить их на отдельных процессорах. Уменьшение сложности проектирования достигаеться из -за того , что вместо одно большого графа - получаются неслько графов меньшего размера , ну и соответственно ...В этом варианте и требования к OS .для реализации этих подзадач - соответственно снижаются(латентность, мертвое время и пр...).
- А вот если не получаеться слабосвязанных задач - то это проблема не RTOS а проблема алгоритма и/или архитектуры вычислений. RTOS здесь уже совсем не поможет.. Тут начинаются всякие MIMD &SIMD и прочие Data flow навороты.
Вот тогда при построении DFSG задачи на таких распределенных вычислителях вопрос real-time определяется латентностью переключения этого графа из одного сотояния в другое и соответственно латентностью конвейера данных, обрабатывающих то или иное событие от его появления до выработки решения (результата).
Т.о. сначала спецификация на RT приложение - потом выбор архитектуры - а затем уже (если можно и нужно ) спецификация на RTOS. Таак мне кааажется..
Ну а всякие FPGA+(NIOS+command extensions)+Linux и дают эту возможность ..реализовывать целевую архитектуру приложения.

[TMX]

Вы правы, я тоже стараюсь разбить систему на несколько задач с четкими интерфейсами и явно выделенными состояниями.
После этого уже не имеет принципиального значения, выполняются ли они на нескольких процессорах или на одном с разделением времени между задачами. А общие ресурсы могут быть и на многопроцессорной системе.
При таком подходе вполне достаточно модели с циклическим исполнением - она легко поддается расчетам. Недостаток - необходимо разбивать задачи на состояния с жесткими временными рамками, это иногда приводит к значительным затратам времени при внесении изменений. Кроме того, обращение к общим ресурсам представляет некоторую проблему.
Для управления ресурсами ОС не обязательна - есть циклические буферы, буферы читатель/писатель, флаги, наконец. Удобно оформить все это в некоторые библиотеки со стандартным интерфейсом и пользоваться (я так и делаю).
Анализ ОС меня - гимнастика для ума, мне любопытны подходы и филисофия создания именно ОСРВ - потому что существуют жесткие рамки, это заставляет изобретать новые идеи, например, несравниваемые приоритеты (Babaoglu,1990) или протоколы захвата/освобождения ресурсов.
Когда мне нужно было написать ОС - я это сделал (для Fujitsu), и могу рассматривать эти проблемы с позиции реализации (в сущности, на мой взгляд, все сводится к алгоритмам обработки динамических очередей).
Сейчас я реализую одну свою идею (несложную) насчет оптимизации времени обработки семафоров и выбираю алгоритм захвата ресурсов.
Поэтому я рассматриваю то, что может мне пригодиться или улучшить мое понимание проблемы - это, в общем-то, не широкие рамки.