реал тайм осы

Меня до сих пор поражает как тогда боролись за каждый байт (64кбайта ОЗУ в то время было почти роскошью). Даже шестибуквенные имена файлов на диске умудрялись запихивать в 4 байта с помощью специального кодирования RADIX50.

Что касается основной темы дискуссии, то я хотел бы высказать несколько соображений.

1) Когда говорят, что идет управление процессом в реальном времени, то это означает, что быстродействие системы управления адекватно скорости протекания управляемого процесса. Это определяется не только вычислительными средствами и операционной системой, но и коммуникационной инфраструктурой, а так же датчиками и исполнительными устройствами. То есть, если применен датчик или исполнительный механизм, чья инерционность не позволяет управлять процессом с нужной скоростью, то никакая ОСРВ не поможет.

2) Допустим с коммуникацией и низовой автоматикой все нормально. Есть ли процессы, для которых производительности коммерческих ОС достаточно? Да есть. И такие системы успешно работают. Необходимая скорость реакции в таких системах может измеряться минутами. На том же Windows NT можно получить предсказуемое время отклика в районе 50-100мс, а с определенными настройками до 10мс. Если залезть в код ядра (как это делает тот же venturcom), то можно добиться еще лучших результатов. Опять же нужно учитывать, что скажем та же предназначенная для встраиваемых систем Windows CE это ОС, которая  целиком написана другим коллективом программистов и основное, что ее объединяет с "большими" Виндами - это Win API (и то из 7000 тысяч оригинальных функций поддерживается только около 1500)

3) Подходят ли офисные ОС для управления действительно  быстрыми процессами, требующими детерминированного времени реакции на внешние события? Как правило нет. Здесь как раз оправдано применение специализированных ОСРВ. В то же время требования современных мультимедийных приложений (потоковое видео, звук и т.п.) подталкивают коммерческие ОС к улучшению их динамических характеристик.

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

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

С Уважением,

Сергей Сорокин