Почему не каждая ОС в режиме реального времени?

Ответ 1

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

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

Да, возможно создавать гибриды, такие как Windows или даже потоки реального времени Linux. Но где-то вы обычно платите штраф, потому что в конечном итоге существует только конечный набор доступных ресурсов (ЦП, пропускная способность IO, что угодно), а потребительские ОС и RTOS'ы оптимизируются по различным критериям. Некоторые из подходов RT Linux имеют дело с этим явно, имея разделы. В каждом разделе оптимизированы различные допущения и разные критерии оптимальности.

Какие функции торгуются? Я не могу предложить точный список - больше того, что ОС OS общего назначения имеет тенденцию иметь миллион драйверов и быть в состоянии идти в ногу с оттоком новых устройств; RTOS, как правило, сосредоточены на гораздо меньшем наборе, для которого своевременность может быть либо хорошо понята, либо явно предотвращена от вмешательства в другие действия. Вероятно, у вас не будет одинакового выбора драйверов на обычной ОСРВ, поскольку, как правило, не разумно их реализовать.

Пропускная способность Помните "в реальном времени"!= "реальный". Когда система работает в режиме реального времени, это означает, что время завершения деятельности является частью их правильности. В некоторых случаях это означает, что обработка многих операций очень быстро (высокая пропускная способность); в других он может обрабатываться в относительно медленный, но чрезвычайно предсказуемый период. Структуры в RTOS могут иметь высокую пропускную способность, но, как правило, не могут обеспечить пропускную способность эквивалентной ОСРВ, поскольку методы, используемые для достижения этой пропускной способности (кэширование, причудливые интерактивные подходы к планированию, "честная" очередь и блокировка) против предсказуемости любой отдельной задачи.

Ответ 2

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

И, вероятно, для среднего пользователя, вероятно, не будет слишком большого выигрыша.

Ответ 3

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

До тех пор, пока не появится рынок для перекрытия между быстрой разработкой приложений и в режиме реального времени, вы вряд ли увидите, что поставщик ОС разделяет ресурсы между ними. Быстрое развитие и критическая безопасность просто не идут вместе.

Когда Blackberry Playbook перейдет в QNX, мы впервые увидим дружественную среду разработки (библиотеки, а также инструменты) для RTOS.

Ответ 4

В основном та же причина, что и "почему не все пишут webapps в C?". Это намного быстрее, но намного сложнее. RTOS на большой системе становится громоздкой, потому что большая часть управления предоставляется программисту приложений.