[TMX 0]

Хочу обзор сделать, по существующим на рынке ОС для мк.

Не просто краткую аннотацию, такие уже есть,

например:

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

-. все остальные.

[AlexandrY 3]

Меня бы интересовали другие параметры.

Более жизненные так сказать.

 

По приоритетности:

1. Доставаемость исходников

2. Независимость от компилятора

3. Портируемость и документированность

4. Минимальное время реакции на конкретных примерах

5. Объем потребляемых ресурсов

6. Известность и широта применяемости.

 

А остальное дело наживное. И HAL и планировщик и примочки всякие пишем по своему усмотрению.

[TMX 0]

Меня бы интересовали другие параметры.

Более жизненные так сказать.

 

По приоритетности:

1. Доставаемость исходников

2. Независимость от компилятора

3. Портируемость и документированность

4. Минимальное время реакции на конкретных примерах

5. Объем потребляемых ресурсов

6. Известность и широта применяемости.

 

А остальное дело наживное. И HAL и планировщик и примочки всякие пишем по своему усмотрению.

<{POST_SNAPBACK}>

 

Ну я вроде объяснил, зачем я это собираюсь делать - идеи хочу новые посмотреть.

Если вы можете написать элементы, то зачем вам тогда приобретать ОС - пишите свою по своему усмотрению.

[xyzzy 0]

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

<{POST_SNAPBACK}>

 

Как насчет многопроцессорности? SMP, NSMP, NUMA, etc..

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

 

--zzyxy

[TMX 0]

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

<{POST_SNAPBACK}>

 

Как насчет многопроцессорности? SMP, NSMP, NUMA, etc..

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

 

--zzyxy

<{POST_SNAPBACK}>

 

Не, я в межпроцессорном взаимодействии не компетентен. А методы синхронизации и в однопроцессорных системах не оптимальны - например:

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

А многопроцессорные системы слишком сложны для моего мозга.

[RVlad 0]

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

 

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

[TMX 0]

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

<{POST_SNAPBACK}>

 

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

Предсказуемость, с моей точки зрения, это возможность расчета времени реакции на событие. Ну и как переключение контекста влияет на предсказуемость? В uCOS II, например переключение контекста очень быстрое, ну и что - она не предсказуема, поскольку м.б. инверсия приоритетов.

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

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

Насчет контроля сбоев ничего сказать не могу.

Мне кажется, что расчеты для многопроцессорных систем гораздо сложнее.

[RVlad 0]

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

- Если говорить в терминах определений 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 0]

Вы правы, я тоже стараюсь разбить систему на несколько задач с четкими интерфейсами и явно выделенными состояниями.

После этого уже не имеет принципиального значения, выполняются ли они на нескольких процессорах или на одном с разделением времени между задачами. А общие ресурсы могут быть и на многопроцессорной системе.

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

Для управления ресурсами ОС не обязательна - есть циклические буферы, буферы читатель/писатель, флаги, наконец. Удобно оформить все это в некоторые библиотеки со стандартным интерфейсом и пользоваться (я так и делаю).

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

Когда мне нужно было написать ОС - я это сделал (для Fujitsu), и могу рассматривать эти проблемы с позиции реализации (в сущности, на мой взгляд, все сводится к алгоритмам обработки динамических очередей).

Сейчас я реализую одну свою идею (несложную) насчет оптимизации времени обработки семафоров и выбираю алгоритм захвата ресурсов.

Поэтому я рассматриваю то, что может мне пригодиться или улучшить мое понимание проблемы - это, в общем-то, не широкие рамки.

[RVlad 0]

Мнея эта тема интересует в том числе и прагматической точки зрения.

В данный момент я работаю с разработкой приложения на WinCE. Говорить про недостатки я не буду ... не продуктивно. Но проблема состоит в следующем.Есть два треда - один занимает примерно 10-15% временной диаграммы процесора. Другой, для которого необходимо выдерживать жесткие врменные соотношения . может занимать либо 10, либо 20 либо 50% временной диаграммы(замеры делались на автономном прогоне). Так вот если в 1 и 2 случае все примерно неплохо -- т.е. 1тр + 2тр = сумм загрузка, в случае когда второй тред занимает 50% результат плачевный --

вместо 15+50 = 65 процентов я могу получить и 75 и 85 процентов загрузки.

Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi??

Может что нибудь посоветуете??

[TMX 0]

Мнея эта тема интересует в том числе и прагматической точки зрения.

В данный момент я работаю с разработкой  приложения на WinCE.

Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi??

Может что нибудь посоветуете??

<{POST_SNAPBACK}>

 

К сожалению, под WinCE не работал - я занимаюсь более легкими ОС типа FreeRTOS, uCOS и т.п.

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

Если же у вас этого нет, то я не знаю.

[merk0 0]

***Мнея эта тема интересует в том числе и прагматической точки зрения.

В данный момент я работаю с разработкой приложения на WinCE.

Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi??***

 

С этой системой я не работал...но.

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

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

 

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

-. Приоритеты задач (стат, динам, несравниваемые и др.)

-. Особенности переключения задач (контекст, стеки и т.д.)

-. Реализация планировщика.

-. Реализация диспетчера.

-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.

-. Предотвращение инверсии приоритетов (есть, нет, методы)

-. Реализация искл. доступа к ресурсам.

-. Контроль задач (события, таймеры и др.)

-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)

-. Реализация HAL.

-. API - предоставляемые возможности.

-. Доп. средства (GUI, TCP/IP и т.д.)

-. Общая оценка.***

 

Вообще-то я занимался разработкой ртос. Но ваши вопросы как то уж очень широко поставлены.

Это называется курс лекций по теме - разработка и архитектура ртос...

Как все это обсуждать в форуме?

Или вы хотите сформулировать пособие по разработке ртос для всех желающих...а оно надо? добром не кончится если все желающие станут писать ртосы. По пособиям.

 

Скажу сразу, что вопросы ваши очень частные и по большому счету к архитектуре имеют далекое отношение.

Совсем не рассматриваются весьма важные вопросы - устойчивость системы, утилизация ресурсов при работе или убийстве тредов, распределение ресурсов, конструкция - монолитная, микроядерная, и все такое...

 

Мое мнение в результате опыта разработки

Хорошая ртос это

1. реализованная на C++

2. четкий и компактный HAL

3. Нечто вроде микроядра с релизацией подкачки компонент ядра и других компонент оси

4. Многозадачность вытесняющая, с динамическими приоритетами

5. Синхронная - листенеры(хуки) и асинхронная активация(события) кода

6. Разделение ресурсов методом вроде синхронизирующих механизмов java. Вообще вычислительная модель java - видится как минимальная но полная. То есть ее и надо посмотреть в первую очередь.

7. Хорошая защита системы от "лома". То есть разделение прав доступа задач и тредов к программным и физическим обьектам.

 

8. Проблемы устойсчивости - то есть упавшая задача не должна обрушить систему целиком. Вопросы утилизации ресурсов занятых упавшей задачей и все такое.

 

9. Реализация "стандартных" протоколов и драйверов, вроде компортов, тср/ip и проч

 

... разумеется тут писать можно много и долго..это я бессистемно написал первое что приходит в голову, ...по опыту работы.

 

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

 

Вообще архитектуру ртос надо анализировать и формулировать на уровне системного анализа и математики кое какой...а как там пишут ртос отдельные авторы... все равно что изучать архитектуру зданий по конструкции избушек в деревне.

[TMX 0]

Спасибо за развернутый топик.

Пожалуйста, прочтите это сообщение хотя бы до вопросов, оно многословное, просто потому, что поговорить не с кем.

Я в этой области не профессионал (разрабатываю ОС не за деньги), просто как-то попалась в руки книжка 1984г. издания Кейслер "Разработка ОС для малых ЭВМ", а я как раз изучал м/к Fujitsu и увидел, что параметры малых ЭВМ 70-х соответствуют одному камню, а воротили на них серьезные задачи. Ну я взял библиотеке книжки Шоу, Дейтела, скачал книжки Лябрусса, несколько исходников и написал на их основе ядро ОС, заточенное под F2MC, реализующее всего несколько функций: создание, запуск, приостановку и остановку задачи, захват и освобождение счетного семафора.

При разработке ставил следующие требования:

1. Минимальное время запрещения прерывания системными задачами.

2. Минимальное использование ОЗУ

3. Возможность освобождения семафора из-под прерывания.

4. Минимальное время вызова задачи, висящей на семафоре при возникновении события.

5. Возможность round-robin.

6. Динамические приоритеты.

 

Результат:

1. Макс. время запрещения прерываний - 30 тактов (<2мкс на 16 МГц)

2. Использование ОЗУ - 52 байта на задачу + стек задачи.

3. есть, прерывание может возникнуть даже во время обработки системной очереди на выполнение, освободить семафор, т.е. взять задачу из очереди на ресурс и поставить в очередь на выполнение, при макс. приоритете новая задача запустится первой.

4. Макс. время запуска ок. 5мкс.

5,6 - есть.

Требует ок. 15% проц. времени при 25 задачах.

Отдельный системный стек.

 

Конечно, система не идеальна (строго говоря, и не ОСРВ, впрочем, как и uCOS)

1. Ограниченное количество задач (до 29) - просто в ядре м/к имеется 32 банка РОН (все равно расчитывалась на внутр. ОЗУ, а его объем в Fuji мал: обычно 2-4 кБ).

2. Нет контроля за инверсией приоритетов и взаимной блокировкой (и вообще не ясно, как это сделать малой кровью при динамических приоритетах).

3. Нет встроенных сервисов типа таймеров, очередей и т.д. (можно реализовать семафором и спец задачей на очереди) - просто руки не дошли.

4. Очередь семафоров сделана по принципу FIFO - чтобы занимала меньше времени на обработку.

 

В процессе работы появились некоторые вопросы:

1. Как запускать обработчики таймеров в системе с фиксированным количеством задач? Знаю несколько решений, однако не знаю, какое наилучшее.

2. Какой набор примитивов ядра достаточен?

 

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

 

Сейчас появилось много микроконтроллеров с ядром ARM7, поэтому я начал писать ОС, заточенную чисто под них.

Требования:

1. Минимальное время запрещения прерывания.

2. Минимальное использование памяти ОЗУ (должна работать с 20-ю задачами на ADuC 7020 - 8 кБ).

3. Жесткое реальное время - можно рассчитать время реакции (может быть и большИм, главное - предсказуемым).

 

Сразу воникли вопросы по архитектуре и реализации:

1. Основной вопрос по реализации: Как вызывать диспетчер? В Fuji я использовал для этого специальное отложенное программное прерывание с наименьшим приоритетом: т.е., например, в обработчике прерывания освобождался ресурс, задача из очереди на семафор ставилась в очередь на выполнение и выставлялся флаг отложенного прерывания. При выходе из обработчика система сразу заходила в обработчик этого отложенного прерывания т.е. диспетчер. Также флаг мог выставляться из-под прерывания 1 мс таймера с наивысшим приоритетом.

Как сделать это на ARM непонятно: использовать инстр. SWI? - она не отложенная, использовать программное выставление одной из линий прерывания - вообще ерунда какая-то.

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

 

2. Сейчас я реализовал следующий алгоритм приоритетов, считаю идею красивой: приоритеты могут иметь значение от -8.192 до +8.192, в порядке уменьшения. Отр. приоритеты - статические, положительные приоритеты - динамические, уменьшаются до -1 и останавливаются. 0 - отдельно, мин.приоритет вообще(статический). Т.о. в системе может быть полностью с динамич. или полностью стат. приоритетами, или и теми и др. (например, одни - для драйверов, другие - для задач пользователя). Какие недостатки? Следует ли повышать динам. приоритет задачи, если она стоит в очереди к ресурсу? Как лучше организовать увеличение динам. приоритета - при каждом запуске диспетчера или по таймеру? (сейчас сделано по таймеру, типа, для deadline monotonic analisys).

 

3. Захват и освобождение ресурса сделаны по следующему принципу: сортировка очереди происходит при постановке ресурса в очередь, поскольку опыт показал, что возможность освобождения ресурса из-под прерывания очень удобна, поэтому там все должно быть уже отсортировано и время минимально. Для этого реализованный алгоритм сортировки подразумевает, что очередь может изменяться в момент сортировки: например, сработало прерывание и освободило этот ресурс. Или сработало прерывание, освоб. др. ресурс -> запустилась ожидающая его задача с более высоким приоритетом, и захватила рассматриваемый ресурс (или встала в сортируемую очередь к нему). Где можно почитать о подобных методах? Обычные алгоритмы сортировки подразумевают, что очередь статична.

 

4. Следует ли создавать для системных процессов и драйверов отдельную очередь на выполнение для уменьшения времени отклика?

 

5. Минимальный набор примитивов для микроядра? (в т.ч. посмотрю Java)

 

6. Алгоритм запуска системных обработчиков, если задачи исполняются из ПЗУ? т.е. новую задачу создавать нельзя. Пример: обработчик таймера - досчитывает в прерывании, выкидывается на выполнение, а куда? Большинство решений предполагает системный процесс с макс. приоритетом, который стоит на семафоре к очереди ф-ий обр. вызовов: как только появляется новая ф-я он ее вызывает и выполняет. Недостаток - кол-во параллельно выполняемых ф-ий равно кол-ву зарезервированных сист. процессов. Невозможно менять приоритет обработчика таймера (всегда макс.). Хотя было бы удобно, чтобы обработчик таймера наследовал приоритет запустившего процесса.

В некоторых системах, насколько я знаю в WinCE, СМХ есть HLL - hardware link layer - фактически, в ф-ии обработки прерывания разрешаются прерывания, при этом нет повторной входимости и т.п.

В PORTOS идея в том, что существует очередь т.н. приоритетных функций, наследующих приоритет, которая является чем-то вроде отдельной вытесняющей не round-robin ОС на системном обработчике (склоняюсь к этому решению). Может посоветуете что-нибудь получше?

 

7. В литературе обычно рассматриваются протоколы захвата/освобождения ресурсов для единственного ресурса. Какие использовать в других случаях, например, управления памятью?

 

8. В своих статьях специалисты ф. GreenHill пишут, что в их ОС прерывания в системных процессах не запрещаются никогда. Как это реализовано?

 

Мое мнение в результате опыта разработки

Хорошая ртос это

1. реализованная на C++

2. четкий и компактный HAL

3. Нечто вроде микроядра с релизацией подкачки компонент ядра и других компонент оси

4. Многозадачность вытесняющая, с динамическими приоритетами

5. Синхронная - листенеры(хуки) и асинхронная активация(события) кода

6. Разделение ресурсов методом вроде синхронизирующих механизмов java. Вообще вычислительная модель java - видится как минимальная но полная. То есть ее и надо посмотреть в первую очередь.

7. Хорошая защита системы от "лома". То есть разделение прав доступа задач и тредов к программным и физическим обьектам.

 

8. Проблемы устойсчивости - то есть упавшая задача не должна обрушить систему целиком. Вопросы утилизации ресурсов занятых упавшей задачей и все такое.

 

9. Реализация "стандартных" протоколов и драйверов, вроде компортов, тср/ip и проч

 

<{POST_SNAPBACK}>

 

ответы по пунктам для микроконтроллеров:

1. Часто среды разработки для микроконтроллеров не поддерживают С++.

2. согласен, осталось выбрать соотв. набор функций.

3. Вещь полезная, но в случае м/к лучше организовать бутлоадер с выходом в сетевой протокол и грузить все ОС и приложения в сборе - при работе из ПЗУ все равно динамически подгружать/выгружать толком не получится.

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

5. Само собой.

6. Спасибо за наводку - посмотрю.

7. Механизмы контроля памяти без MMU требуют больших накладных расходов и специализированных средств разработки приложений. Вопрос важный, но я пока не знаю, как его красиво решить. Сейчас я сосредоточился на примитивах для ядра.

8. Это вытекает из предыдущего пункта.

9. важно, но не главное для архитектуры.

 

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

А часто и нет. Мне часто достаточно идею понять.

 

Вообще архитектуру ртос надо анализировать и формулировать на уровне системного анализа и математики кое какой...а как там пишут ртос отдельные авторы... все равно что изучать архитектуру зданий по конструкции избушек в деревне.

Если провести эту аналогию дальше, то я пытаюсь строить коттедж, а не аквапарк ;-)

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

Изучение избушек полезно:

во-перых, можно изучать традиции зодчества в данном регионе - можно по теор. правилам спроектировать очень неудобное здание.

во-вторых, можно посмотреть реализацию некоторых идей, встречаются очень красивые решения.

в-третьих, называть Integrity или eCOS или PORTOS избушками некорректно.

в-четвертых, все избушки в основе имеют какой-то план.

в-пятых, если избушка была неудобна - пристройки сразу бросаются в глаза.

в-шестых, прогулки на свежем воздухе вообще полезны :-)

[merk0 0]

Поскольку у вас вопросов много..я отвечу пока только на один. Возможно он изменит ваши взгляды на систему.

 

...У вас какой-то сложный взгляд на мир вычислений.

Предлагаю модель - проще не придумаешь

1. Есть треды как независимые единицы исполнения.

2. Есть разделяемые тредами обьекты - например какие- то данные. Такие данные защищаются явными или скрытыми механизмами разделения доступа. Они защищают только от проникновения тредов и больше ни от чего.

3. Есть События - этакие "письма" пересылаемые внутри системы между обьектами. События могут быть адресными и широковещательными или групповыми.

4. Есть Источники Событий - то, что может посылать события.

5. Треды могут вставать в ожидание событий. Треды также могут быть источниками событий. Треды дождавшиеся События, активизируются только решедулером.

 

Все!

Модель системы готова.

 

Это примерно модель java.

Все остальные модели являются ее клонами или раширениями. Разумеется когда мы говорим о многозадачности.

 

Далее, то что вы называете - таймерами, если я правильно вас понял - это просто Источники Событий некого рода.

То что вы называете прерываниями - тоже источники событий.

 

Чтобы написать( как вы спрашиваете ) ядро без запрета прерываний - нужно просто прерывания оформить в стиле источников событий. То есть физический источник события просто вкидывает Событие в некий буфер, и обозначает ассоциированную процедуру обработки или тред ожидающий события как Активный. А решедулер, затем запускает эти помеченные как активные, обьекты(треды). Это самыми общими словами. ТО есть запрет прерываний тут происходит только на этапе вбрасывания события в буфер и выборки его тредом из буфера. Чтобы источник событий и приемник - не столкнулись.

 

Иного способа написать ядро без запретов прерываний - нет.

 

Ваше требование - юзать обьекты ядра из прерываний - тут же делают невозможным написать ядро без запрета прерываний.

 

И вы повторяете эту распространенную ошибку.

Приведет она вот к чему.

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

Вот такие дела.

 

Итак - казалось вы хотели быстрой реакции.. а получили - никакую реакцию и пропуски событий.

[TMX 0]

Это примерно модель java.

Все остальные модели являются ее клонами или раширениями. Разумеется когда мы говорим о многозадачности.

Я наоборот считал, что мое представление одно из простейших. Сложности возникают при реализации.

Насчет модели описанной вами модели java - все нормально, пока нет необходимости обеспечить гарантированное время отклика. Дело в том, что в прикладных задачах, над которыми я работаю, очень размытая граница между драйверами и пользовательскими процессами, скорее даже полноценных пользовательских процессов почти нет. Поэтому у меня сложилась модель ОС для управления работой драйверов, по-моему, она не противоречит модели java.

 

Ваше требование - юзать обьекты ядра из прерываний - тут же делают невозможным написать ядро без запрета прерываний.

Просто при построении модели я хотел сделать предсказуемое время реакции пользовательского уровня ОС на хардварное событие. Варианты формирования и обработки событий на более высоких уровнях требуют дополнительных расходов ресурсов.

 

Итак - казалось вы хотели быстрой реакции.. а получили - никакую реакцию и пропуски событий.

<{POST_SNAPBACK}>

Во-первых, приоритет прерываний выше приоритета пользовательских процессов и ядра, т.е. при разрешенных прерываниях они всегда вытесняют текущий процесс за известное время.

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