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

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

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

Мягкие таймеры, для задач, когда отклонение на квант работы одного треда не играет роли - например что-то выводить на экранчик периодически юзеру...активируются из системного треда - опросчика таймеров. Он себе крутится пока очередь таймеров не пуста и спит, когда пуста.

Вообще вариантов реализации таймеров и их разновидностей много.

Это я сказал как оно реализовано в ядре. Для пользователя же, это может быть оформлено, как специальный источник событий. Если пользователь хочет просто получать евент или мессагу в очередь мессаг треда, он попросит EventSource кидать событие в очередь, если захочет написать хук - сделает соотв Listener, и прицепит его к данному EventSource. В первом случае он будет реагировать на event асинхронно, во втором - синхронно.

[TMX]

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

я об этом методе говорил в своем обширном топике - это когда обработчик таймера переходит на т.н. уровень HLL (hardware link layer). Меня не устраивает.

Мягкие таймеры, для задач, когда отклонение на квант работы одного треда не играет роли - например что-то выводить на экранчик периодически юзеру...активируются из системного треда - опросчика таймеров. Он себе крутится пока очередь таймеров не пуста и спит, когда пуста.

Основной вопрос - как управлять приоритетом этого треда? Хотелось бы чтобы его текущий приоритет был равен приоритету запустившего таймер процесса. Конечно можно делать отдельный тред на каждый таймер, но это потребует отдельного контекста, что нежелательно при небольшом объеме ОЗУ.
Возможно я слишком многого хочу, но было бы удобно запускать таймер следующей ф-ей:
timer_start (int ms, void(*callback)(void)), где callback - указатель на ф-ю обратного вызова.
Запускать этот указатель из под прерывания проблем не составляет - у меня есть библиотека и не для ОС (просто вызываешь ф-ю по указателю из обработчика и все).
А вот в треде возникают проблемы о которых я уже писал.

Это я сказал как оно реализовано в ядре. Для пользователя же, это может быть оформлено, как специальный источник событий. Если пользователь хочет просто получать евент или мессагу в очередь мессаг  треда, он попросит EventSource кидать событие в очередь, если захочет написать хук - сделает соотв Listener, и прицепит его к данному EventSource. В первом случае он будет реагировать на event асинхронно, во втором - синхронно.

про listener можно поподробнее? Это то что я назвал callback?