реал тайм осы

Первоначально опубликовано Draggan Real-time systems: systems that respond in a predictable way to unpredictable external events.

И вот теперь, отталкиваясь от этого короткого замечания, которое во многом совпадает с тем, о чём шло обсуждение на последних 10 страницах темы ;-) - мы можем попытаться нарисовать, "в нулевом приближении", определение того, о чём так долго обсуждали...
А то здесьуже такой категоричный крик начался: "Даёшь определения!!!".
Даже не определение, потому как у меня лично идиосинкразия на любые определения: всё, для чего уже даны неподвергаемые сомнению определения "в последней инстанции" - это уже костно и мертво... - это первый признак. Итак, предварительный вариант... не определения, но описания, объяснения "что есть realtime":

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

Пусть будет так...
Как вы видите - в такой перефразировке временной параметр вообще почти не фигурирует, и выплыл побочно, в конце уточнения.
Теперь:

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

- какой-нибудь текстовый редактор MS Word под Windows - выпадает из этоо определения, т.к. все вы наблюдали неожиданные явления его "задумчивости", когда в Windows начинается свопинг, запускается новая задача, или - ну, это просто прелесть - форматируется дискета. Конечно, можно всё довести до абсурда, и сказать, что требуемый интервал релаксации у нас - 1 час. - тогда мы получим "полный реалтайм" ;-).

- система, которая загружена "под завязку", на 95% производительности процессора - тоже выпадают из определения (или - должна выпадать, и, если нужно - под это нужно трансформировать определение). Это - случай производительности, а не realtime, и решается он просто - сменой процессора. Разумно говорить об realtime только тогда, когда сумма потребных производительностей всех потенциально обслуживаемых ветвей - может загружать процессор до 70-95%, т.е. когда проблемы могут быть не в нехватке ресурсов для всех ветвей исполнения, а в невозможности их эффективной координации (об этом условии есть и в текстах Dedicated Systems и в материалах QSSL).

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

Эй, где там: OS/2, FreeBSD ... кто в очереди "крайний"?

Просто ... да непросто... Потому, как 2-е требование - оно не процедурное: требуется доказать отсутствие! Всегда стократ сложнее доказывать, что "ты не верблюд", чем доказывать, что "нечто - есть верблюд".

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

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

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

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

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

А если, простите, ваша "система/аппарат, которой управляют не критична ко времени реакции" - то она никоим боком не относится к realtime.
И тогда вам с вашей системой - в другое место ;-) ... т.е. в другой форум нужно.

Позвольте небольшое лирическое отступление...

Но я надеюсь, что это не будет "крутой off-topic", поскольку имеет касательство к теме обсуждения ... по аналоги. Кстати, когда в любой проблеме складывается клинчевая ситуация, то очень часто именно аналогии, и чем более отдалённые аналогии - тем лучше, подсказывают направление выхода. Итак:

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

А в форум я должен идти dialup-ом, чего давно не делал, имея неограниченный служебный доступ ... неограниченного качества ;-). А тут вдруг на dialup-е - модем верещит как резаный, пыжится... а коннекта нет... 1 раз из 10-ти что-то приконекчивается. При неизменных настройках, когда ранее всё было тики-тики.

Вот тут меня и настигло "соображение по аналогии".

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

В чём моя проблема? А в том, что сидит в фирме провайдера "системный администратор" (в выходной! - сидит ли, или уже "по-пиву" ушился?), и накрутил он там своими блудливыми ручками настройки "цисок", как ему представилось должным...

Вот составная часть этой системы: "системный администратор". Есть определения для того, что есть системный администратор? Безусловно - есть: и должностная инструкция, и чего от него ожидается, и каким требованиям он должен удовлетворять... Чего же нет, что сбоит в системе?

Нет критериев!

Кого набирают провайдеры в качестве системных алминистраторов (да пусть меня простят провайдеры, но я скажу: "все провайдеры")? Обобщённый образ системноо администратора:

- это такой юный недоумок, которого выперли за акдемическую неуспеваемость со 2-го курса - по нынешним меркам это даже считается критерием "непонятой гениальности";
- ... который убедил руководителя провайдера (который - да простят меня провайдеры ещё раз - в технических деталях лох-лохом) - в том, что он есть "крутой системный администратор";
- ... который, не обременён познаниями (т.е. точнее, пониманием: процессов, протоколов, RFC ...) и не считает это нужным (да и вправду, а зачем это нужно: администратор - это же не профессия, а средство передвижения ;-));
- ... который не написал в своей жизни ни строчки TCP/IP кода, хоть бы для иллюстрации и тестирования - а без этого, "помимо ручек" - невозможно понимание функционирования протокола;
- ... и вот крутит он своими блудливыми ручками сетевые настройки, "авось получится" - и только потому, что нет критериев качества того, что он там накрутит (потому, как прочий персонал провайдера - ещё менее понимает что происходит, как и было выше сказано).

Нет критериев!
Нет критериев оценки - хорошо или плохо составной элемент системы выполняет предполагаемые за ним функции.

Да и откуда им взяться?
В обществе (стране) относительно стационарном - существует стабильная система иерархий априорной оценки качества (профессионализма) специалиста: зав. кафедрой и профессор, или генеральный конструктор изделия "Х", или автор книги "Y" - это, наверное, хорошо, а - ученик 3-го класса церковно-приходской школы - это, наверное, похуже... (то, что эта система - относительна, и даёт сбои - не нужно мне указывать, я это знаю... , но: иногда!).

Но это - в стационарной среде...
А откуда взяться устойчивой иерархии оценок качества в стране, лежащей в руинах после проигранной мировой войны? Когда перед глазами только "фьють - фьють" мелькают и проносятся толпы мародёров и (они же) коммивояжёров ... "лучших в мире изделий от лучших в мире производителей". Система сертификации ... a-la Microsoft, ставшая столь модной?
Ах, сударь, увольте...
Система этих сертификаций - это, в лучшем случае, умение нажимать нужную кнопку, в нужном месте, в нужное время... Да и потом, всё то же: сертификат - это вовсе не критерий, а средство передвижения ;-).

Но, возвращаясь к нашим баранам, если говорить об realtim-овских качествах систем или их степени, то нужно:
- иметь перечень критериев, которым по принципу "необходимости и достаточности" должна удовлетворять система;
- иметь методики проверки "качества" выполнения каждого из этих критериев;
- ... и, если речь идёт об OS как системе, построить просто набор тестовых программ, которые могли бы оценить "качество" выполнения каждогоиз из этих критериев, в самых неожиданных условиях функционирования OS;
- ... и сравнивайте на здоровье!

Первоначально опубликовано Olej Нет виртуализации в QNX! Т.е. есть, как опциональная возможность для программ разработки (компилятор и т.д.) - "да", но и то, относительно только страниц памяти данных, но никогда - страниц кода! Разница - предполагаю - понятна? Так что пусть вас это не пугает...

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

Но так как виртуализация опциональна, то понятно что

1) Нормальный разработчик не будет ее применять там где это может вызвать проблемы (например быстрые процессы жесткого реального времени)

2) А там где применение виртуализации оправдано (например, массивные HMI программы), разработчик может сделать так что бы интенсивность дисковых операций была минимальной (такого рода проблемы решались еще под ДОС при написании программ с оверлеями).

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

С Уважением,

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

 

Первоначально опубликовано Olej Первоначально опубликовано Draggan Системы реального времени: Системы, которые предсказуемо реагируют на непредсказуемые события. (Real-time systems: systems that respond in a predictable way to unpredictable external events.) circumstances. Это достаточно близко к той позиции, которую и я здесь отстаивал: вообще отрешитесь от термина "время" - realtime не имеет в-прямую никакого отношения ко времени и скростным характеристика.

Я думаю Вы не случайно написали вслед этому дополненительное сообщение. Странно выглядит попытка определить термин "реальное время" без терминов относящихся просто ко "времени" (это слово составляет 50% от  термина "реальное время" :-)). Если бы для понимания термина понятие "время" было бы не нужно, то это слово в термине и не употреблялось бы (вместо "ОС Реального Времени" было бы что нибудь типа - "Реальная ОС" :-)).

Я в общем то и не вижу никакого смысла в термине "реальное время" как таковом.

В сфере АСУ ТП наиболее применимы три словосочетания, имеющие разные значения.

1) Процесс реального времени. То есть когда говорят, что что то происходит или делается в режиме реального времени (слово "режим" для краткости часто опускают).

2) Система реального времени

3) Операционная система реального времени

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

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

Любая успешно работающая АСУ ТП является СРВ.

С Уважением,

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