Real-Time OS – религиозная война компьютерной индустрии или заметки на полях одной статьи.

Добротная статья

Evgeniy товаристч конечно грамотный, но не без biased.. ;)

// wbr

Особенно мне не понравилось: "..с популярной сегодня концепцией open source, которая de-facto подменяет качественную документацию и инструменты доступностью программных текстов." Не все так просто..

Вот уж действительно и научно и популярно - прямо для меня.

А на счет выпада в сторону open source - не по теме ... ну, да ладно.

Михаил.

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

По теме. Интересно. Жаль только, что Linux не микроядерный. ИМХО, разработчики достаточно квалифицированы и талантливы, чтобы написать микроядерную версию с сохранением уникальных и эффективных алгоритмов. И переносимость бы повысилась и устойчивость к ошибкам оборудования и отдельных программных компонент.

> Я специально не останавливался на различиях между ОС «мягкого» и «жесткого» реального времени по той простой причине, что различия эти носят чисто количественный характер и сводятся к различиям в скоростях реакции и времени восстановления системы. И, кстати, было бы более правильно называть их системами «медленного» и «быстрого» реального времени.

Ну что сказать?

Сейчас нет ни одной системы жесткого реального времени. А он посмотрел на реализации существующих РТОС и сказал, что жесткое отличается от мягкого только временами. :_)

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

> Но он говорит что задница у всех, поэтому получающаяся задница не задница а норма.

ну если лопухом подтираться, то да..

Мне эпиграф понравился:)

>Сейчас нет ни одной системы жесткого реального времени. А он посмотрел на реализации существующих РТОС и сказал, что жесткое отличается от мягкого только временами. :_)

Ваш вариант объяснения будет здесь интересен не только мне, уверен.

> Ваш вариант объяснения будет здесь интересен не только мне, уверен.

Приведи хотя бы одну систему жесткого реального времени.

Или ты не про это?

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

Система жесткого реального времени должна гарантировать. Вот основное отличие.

> Жаль только, что Linux не микроядерный. ИМХО, разработчики достаточно квалифицированы и талантливы, чтобы написать микроядерную версию с сохранением уникальных и эффективных алгоритмов.

Вот и пишут...HURD. Говорят, сам я не пробовал, что с последней версие можно даже реально работать в GNOME и соответственно с гномьими программами.

> Вот и пишут...HURD. Говорят, сам я не пробовал, что с последней версие можно даже реально работать в GNOME и соответственно с гномьими программами.

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

// wbr

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

Да но как правило опен соурс имеет также и богатую документацию. Ну например если сравнить документацию по MailerDaemon под вындоз и .... ТОННЫ доков по Sendmail и его настройке (хотя конечто тут Х.. с пальцем сравнивается... :-)).

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

>Приведи хотя бы одну систему жесткого реального времени.

Если бы я знал, я бы не спрашивал. А они вообще существуют, или чистая теория?

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

Тогда в чём отличие "мягких" от GPOS?

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

Т. е. "мягкие" - это GPOS в частном случае, когда известно, что они наверняка справятся? Тогда вообще такое деление (мягкое/жёсткое) не нужно.

>>Приведи хотя бы одну систему жесткого реального времени.

>Если бы я знал, я бы не спрашивал. А они вообще существуют, или чистая теория?

На интеле - навряд. а на нормальном железе существуют.

например есть разработки по теме у Analog Devices и у одного из их подрядчиков(кажись BittWare)

> Тогда в чём отличие "мягких" от GPOS?

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

> Т. е. "мягкие" - это GPOS в частном случае, когда известно, что они наверняка справятся? Тогда вообще такое деление (мягкое/жёсткое) не нужно.

Из вышеприведенного ответа следует, что не все GPOS могут быть мягкими RTOS. А жесткие - это совсем другая история.

> На интеле - навряд. а на нормальном железе существуют.

> например есть разработки по теме у Analog Devices и у одного из их подрядчиков(кажись BittWare)

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

Разработка RTOS с жестким реальным временем должна проводиться без оглядки на всяике стандарты. Типа POSIX'ов и иже с ними. Система должна затачиваться для конкретной платформы. И она в любом случае будет иметь огромное количество ограничений, не позволяющих использовать ее впесто GPOS.

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

> Тогда в чём отличие "мягких" от GPOS?

отличие linux от RT linux - несколько патчей.

А как же QNX?
На деле её не щупал, но по описаниювещь крутая...

> А как же QNX? На деле её не щупал, но по описаниювещь крутая...

Щупал и очень много. Правда, только, QNX4.

Это прежде всего встраиваемая система. Поэтому они сделали микроядро. А микроядро очень плохо стыкуется с риалтаймовостью. Поэтому риалтаймовость мягкая. Я бы даже сказал через чур. И вдобавок производительность страдает. На том же желез обычный linux ее рвет по производительности. Применимость: в системах, где важна скорость реакции и можно забить на производительность (но без гарантий) :(

>Приведи хотя бы одну систему жесткого реального времени.

DOOM III

> На интеле, вринципе, можно

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

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

Спасибо автору, замечательная статья, особено миф 6. Абсолютно с ним согласен. Многие меня задалбывали сборщиками мусора, а я им говорил что страничный механизм все решает, а они продолжали задабывать. Я уже и сам почти перестал в это верить. Но почитав статью я почуствовал некое облегчение, можно сказать веру в себя, свою логику. Спасибо автору.

Отличная статья. Это вообще почти антиреклама эСВэДэшникам, котроые заИпaли рекламировать эти мифы как сУпермеГа фичи.

P.S. Ненавижу эСВэДэшников

> Щупал и очень много. Правда, только, QNX4.

И как, жёстко или мягко? :)

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

По поводу третьего утверждения (т.н. "мифа") - это как раз про hard/soft realtime. По поводу "четвёртого мифа" - планировщики RTOS как раз тем и хороши, что не слишком интеллектуальны :) FIFO и Round Robin в основном :) Это в GPOS'es можно поизвращаться, чем, собственно, народ и занимается в линуксах.

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

В общем лично я бы не пытался увидеть противопоставление RTOS и GPOS, как автор :) Вопрос решается по-другому, для разработки софта для RT систем удобны и/или необходимы операционные системы реального времени. И никто тут, я думаю, никого обманывать не хочет :) В данном случае важнее результат, чем инструмент, с помощью которого он был достигнут. Удобнее тебе линукс ставить на осциллограф - ставь, если сможешь :) Можно говорят даже Winodws ставить. Этак NT 4.0 или что-то вроде того. Типа тоже реалтайм - статьи пишут даже научные по этому поводу :)

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

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

Народ, чё то вы гоните. Hard realtime система - это не система с временем реакции стремящимся к нулю. Это система с гарантированной реакцией в чётко установленный промежуток времени. Или же я ошибаюсь? Т.е. если для системы приемлемо откликаться в течении 3 секунд и это всех устраивает и она стопудово отреагирует не позже чем через 3 секунды, то и такую систему можно считать системой жёсткого реального времени. Ведь так?

> Удобнее тебе линукс ставить на осциллограф - ставь, если сможешь :) Можно говорят даже Winodws ставить. Этак NT 4.0 или что-то вроде того.

По слухам, фирма Agilent не последняя в этом деле. Читаем новость:

http://www.unitest.com/news/20oct2003a.html

Все новые осциллографы Infiniium серии 54830 поставляются с операционной системой Microsoft Windows XP Pro версии A.03.10 или выше и могут работать с ПО "My Infiniium". Существующие осциллографы Infiniium серии 54830 с операционной системой Microsoft Windows 98 версии A.02.30 или ранее могут быть обновлены с помощью комплекта для модернизации "Agilent N5383A Infiniium upgrade kit".

Конец цитаты

Из этой цитаты не вполне ясно, где гоняется эта винда. Но насколько я помню, кто-то из железячников рассказывал, что именно у осциллографа "внутре, где анализатор и думатель". :-)

--

SVK

> тот же qnx - система жесткого реального времени. имеет гарантированное время реакции на прерывания. в документации это ЧЕТКО прописано и есть цифры. и вообще в доках очень много различных цифр, которые прописывают максимальные времена реакций.

А ты присмотрись к документации. И особенно к условиям для которых эти времена описаны. Вся соль в учловиях. Эти условия просто сводят на нет всю их четкость. Нет жесткости у QNX. Даже по документации нет.

> Из этой цитаты не вполне ясно, где гоняется эта винда.

практически ясно. компьютер с АЦП + программа == осциллограф