реал тайм осы

Первоначально опубликовано evgen Ну давайте опять... что такое "критические системы управления" и что такое "realtime OS" и чем " универсальные OS" не "realtime OS" ? Тем более, если все это на платформе x86 ?

Critical mission application - достаточно установившийся терминологический термин. Борт авиационной системы, система управления огнём танка, телекоммуникации международной космической станции... - это я назвал малую часть проектов, в которых реально использовались RTOS.

Что такое realtime OS - вы там сами ниже пишете... Но это ("гарантированная реакция... etc") - цель, а для достижения цели есть ряд (по-моему их 5, N скажем) критериев, которым должна удовлетворять OS чтоб иметь право на приставку RT. Вот 1-е N-1 критериев (достаточно большое число уровней приоритетов, ...) - мало интересны: они достаточно очевидны и их не так сложно учесть в проектировании новых или ревизии старых OS. А вот последний - N-й - критерий, он и добавился на несклько лет позже к остальному джентльменскому набору - отнюдь не тривиальный (потому долго и "просмотрели") и совсем не прост в решении: OS должна препятствовать возникновению эффекта "инверсии приоритетов". Вот ему не удовлетворяет практически ни одна из универсальных OS: ни OS/2, ни большинство "родовых" UNIX, ни Windows XX (именно с появлением "инверсии приоритетов" MS и пришлось придумывать "мягкий реалтайм" - не первой свежести осетрину ;-)).

Мое понимание таково, что если речь одет о гарантированном и быстром времени реакции, то это надо делать отдельным внешним контроллером (DSP, PIC, AVR или тот же x86) Все остальное - от лукавого.

А вот моё понимание - принципиально отличается!
Особенно если вы включили в перечень процессоров - x86, т.е. различие становится совсем прозрачным:

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

- моё видение состоит в том, что я приведенной выше аргументации - не верю, и миллион раз наблюдал обратное, но, к сожалению, уже после завершения и при сдаче проекта. Почему? Потому, что API realtime OS реализует механизмы, "строительные камни", которые всё равно нужно заново изобретать в "ручной" реализации - но! в OS, в POSIX 1003b реализации - эти элементарные составляющие механизмы отрабатывались даже не годами, а десятилетиями... Дальше понятно?

До какого-то времени (ешё 3-5 лет назад) задача использования универсальных процессорных модулей под управлением RTOS была безальтернативной в пользу специализированных контроллеров - определялось это стоимостными разрывами. На сегодня этого разрыва уже почти нет.

Посмотрите опубликованные прогнозы Сименс (законодатель специализированных решений!) своего развития на ближайшие 3 года: "изменить соотношение контроллер-универсальный процессор с 70%/30% к ~40%/60%" - я пересказал по памяти, но смысл исказил не сильно...

Я вот использую и как-то не сильно замечаю таких эффектов...

Во-первых, вот это "замечал" - очень сильно зависит от конкретного класса задач, над которыми идёт работа.
А во-вторых, ... а "зависания" OS вы не замечали? особенно при отработке задач с multithread, активными IPC etc.?

мое IMHO - OS/2. Есть коллеги, которые осваивают QNX. Но уж больно скромные успехи у них.

1. OS/2 - никогда и ни одним словом не позиционировалась как realtime: в IBM - серьёзный народ, это же не авнтюристы из MS...
2. по поводу успехов...
В QNX (за 22-года! - чуть больше возрасту, чем MS-DOS) делалось и сделалось уймища успешных проектов.
Число внедрений (проданных лицензий?) превышает 400000!
А если у кого-то с успехами туго... так может на "ручки" нужно посмотреть? ;-)

Н-да...

to moderator - обсуждение становится определённо тупиковым... ;-), и не из-за бескомпромисности опонентов, а из-за элементарной технической примитивности форума.

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

Первоначально опубликовано evgen Насколько я в танке ;-) там вопрос решается просто - все трижды дублируется и решается двумя из трех. Кстати - наблюдение за пациентом тоже Critical mission application и тем не менее туда [некие уроды] ставят виндоус

1. там всё не так просто... можно и 100 раз "в лоб" резервировать - с тем же результатом...
2. а на предмет использования Windows везде, где ему не надлежит... так на то есть много исторических причин, об этом можно отдельно...
Не так давно я работал с новинкой - макетным экземпляром для ПВО - только начинается(!) производство и экспорт(!) - Win16 + Borland 3.1 :-( ...

Первоначально опубликовано evgen Какие строительные камни мне надо изобретать ? пайпы-очереди-семафоры-нитки-приоритеты есть. Что еще нужно от OS ?

Мы говорим об разных вещах...

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

2. а если вы говорите о том, что у вас в OS/2 всё есть ... "пайпы - очереди - семафоры - нитки - приоритеты" ... то это к чему?

Тема форума называется "OS реального времени" (или как-то так). Вы хотите меня, или кого ещё убедить в том, что OS/2 - это реальное время? Не делайте мне так смешно! Это просто малосерьёзное времяпрепровождение...

[QUOTE=evgen]
Есть проблема со свопингом - но при желании своппинг запрещается. Максимальный "уход в себя" - порядка 100микросекунд на p2-350 на незагруженном процессоре и для задач с нормальным проритетом
[QUOTE=Olej]
Эти 100мкс. - ну просто ничего не значат: ни хорошего, ни плохого... Ну у QNX даже на гораздо слабее процессоре <30мкс. - но и это ничего не значит...
Возьмите любой (не realtime) UNIX - Linux, Free/NetBSD ... любой - вы думаете у них будет хуже тех же ваших 100мкс.? - я думаю, что будет лучше! Но никто же из них не претендует на применения в realtime application?
Как только реально встанет вопрос об требованиях чего-то приближающегося к realtime - тут же у вас выплывут вот те N (5?) критериев, которым ваша универсальная OS ... не удовлетворяет...
Только лучше это уяснять ДО начала проекта, а не ВО ВРЕМЯ его внедрения в эксплуатацию.

Первоначально опубликовано evgen Я говорю только о том, что если есть требование "чтоб не бабахнуло" или если бабахнет - то несильно, то это должно обеспечиваться на как можно более хардварном уровне - даже на уровне пусть будет два жучка, но третий пусть будет предохранителем. Если требуется гарантированная реакция за микросекунды - то пусть ее обеспечивает спецконтроллер ибо в писюке такого не обеспечить. [QUOTE] Это есть 1-й краеугольный камень, с которым я катигорически не согласен, и не буду никогда... и об котором мне приходится ругаться чуть ли не ежедневно на протяжении лет (или десятков лет? ;-)): не будет! Это рудиментарное представление, идущее от житейского опыта проектирования времён релейных исполнительных элементов ;-)... [QUOTE=evgen] Ну берем умную книжку и читаем чего должно быть в риалтайм осе [QUOTE] А вот тут-то и загвоздка! Нет таких "умных" книжек! Всё (!) что вы найдёте об realtime/не-realtime - это будет информация, укладывающаяся в 2 категории: 1. "академическая", обсуждающая вот те N требований для того, чтобы OS можно было отнести к realtime. Всё это, часто, очень аргументировано и т.д. - но не имеет ни малейшего соприкосновения с реально существующеми OS! Авторы часто просто не видели OS более поздней, чем MS-DOS! 2. "тестовая" - это объёмные отчёты и таблицы (часто фирменного, читай: "рекламного" свойства), что "наша OS переключает контекст в 100мкс."... Ну и что? Что в вашем контексте означает "переключать контекст" ;-) (в этом никто не сознается!)? И что такое 100мкс. - это хорошо или плохо? [QUOTE=evgen] Да я собственно никого в свою веру и не пытаюсь обратить. Будем считать, что нижеприведенный список никакого отножения к реальному времени не имеет: -Управление шаговым двигателем через LPT порты с тактовой частотой 2кГц (причем ограничение по частоте - от самого двигателя) - Общение с дивайсами DS1820/1822 с интерфейсом 1-Wire через тот же самый LPT (опрос датчиков температуры в фоне) - управление неким высокоскоростным двухкоординатным дивайсом с реализацией ранееупомянутого Брозенхейма с фиксированной скоростью перемещения через посредство пары LPT портов и с задержками, кратными времени одного inp()   Было сделано по бедности и временно из остатков ide-контроллеров с портами и работает до сих пор. Про работу с DSP и прочими дивайсами я даже и говорить не буду - там реалтаймовые эффекты не так сильно проявляются, хотя реальной пользы от них намного больше, чем при прямой работе через порты [Olej] А этот список и не имеет ни малейшего отношения к realtime. Это может быть список: - хорошо выполненных работ; - работы с аппаратными средствами; - очень быстро (производительно) работающих приложений; - ... Но при чём здесь realtime?! [QUOTE=evgen] PS: я не собираюсь затевать какие-либо религиозные войны и не настаиваю что OS/2 - риалтайм ос. Просто по факту под ней работают весьма и весьма риалтайм системы.

Здесь даже нет предмета для религиозных войн! Религиозные войны можно устраивать, напр., по вопросу "Windows vs UNIX" (как и делают придурки с www.rsdn.ru)...
А здесь настолько всё очевидно... OS общего применения (OS/2, Windows, MS-DOS, MacOS, Linux, FreeBSD, Sun Solaris... - нужное подчеркнуть ;-)) - наскольно непригодны для того, чтоб обеспечивать (гарантированно, а не "если повезло") реальное время, что и говорить не об чем...

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

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

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

Очень интересный пункт - об одном ём можно книжку написать ;-).

POSIX 1003b (стандарт POSIX в части realrime возможностей, я на него буду много ссылаться) определяет 4 дисциплины диспетчеризации: FIFI, RR (round-robin), adaptive, sporsdic.

Разработчикам OS общего применения часто даже не приходит на ум иметь одновременно несколько дисциплин диспетчеризации - они ищут "лучшую"...
- в Linux - чистая round-robin (на уровне, фактически, процессов! - мы ещё к этому вернёмся);
- в Windows... это отдельная песня: в 3.1/3.11 было то, что MS "изобрели" как "кооперативная многозадачность" - у всех остальных нормальных людей это FIFO. В 95/NT/... - это "вытесняющая многозадачность", т.е. то, что у остальных RR, но у них ещё идёт "изобретательство" по изменению (снижению) приоритета выполняющегося процесса - т.е. это типичая adaptive. О том, на уровне чего (процессов или потока) идёт диспетчеризация в Win32 судить трудно ("тайны мадридского двора") - везде в документации: "... процесс ..." - но они пишут документацию так небрежно, что могут и не различить эти понятия.