|
|
Действительно ли вам нужна ОС реального времени? |
Устал - пойди отдохни... ... а то и вправду бы не переутомился...
"Нафиг" - это вы об себе? Так чего же соваться этому нефигу в разговор тех, для кого это имеет значение ... (идём читаем титул темы).
Ага ... кулачковые механизмы, ... на паровом приводе... |
|||||||||||||||||
 |
|||||||||||||||||
Да, проблема во многом обязана своему названию - realtime OS - ничего хуже терминологически вообще придумать нельзя было... - ... оно сразу уводит разговор во временную область, откуда потихоньку сползает на скоростные характеристики: "...а у нас реакция на IRQ - 100мкс!" - а 100мкс. - это хорошо или плохо? - даже общее определение об "...гарантированной реакции в гарантированное время..." - мало что говорит, и как-то все сразу обращают внимание на 2-е "гарантированное", галопом пробегая 1-е... - я так предполагаю, что нужно говорит именно об "надёжной" и "живучей" OS и воздержаться от термина realtime (или употреблять термин, но предполагая за ним именно этот контекст). Т.е. акцент то - на 1-м "гарантировано"! Кто рассматривал гистограммы временных реакций Windows при очень больших (>1000000) числах испытаний, должны были замечать характерный ид этих графиков (практически не зависимо от того, какой параметр): лотно "утрамбованные" значения вблизи горизонтальной оси (скажем ~1мс.) с отдельными единичными выпаданиями ... на порядок, два и больше. Т.е. там, где "почти всегда" наблюдается 1мс. - очень изредка, но вываливается ... 100мс. (т.е. разговор не о том, что 1 или 1.5 и что лучше). Реакция, поступившая с такой задержкой - это реакция? Может она и не нужна уже к такому времени. Но есть и ещё более жёсткая ситуация - это и есть то 1-е "гарантировано": всегда ли возникает ожидаемая реакция вообще? Нет ли вероятности 10**-9 ... что в этом случае возникнет вот та "инверсия приоритетов", и та ветка, которая должна вызвать реакцию - вообще не получит управления? Или ... "программа выполнила недопустимую операцию ... пип ... пип ... пип ... Обратитесь к разработчику!" Но обращаться то к разработчику то - поздно!!! Вот о чём речь - хотя здесь вообще нет речи о каких либо временных характеристиках вообще. Позвольте мне маленький плагиат: ссылку, которую dmi_a давал в другом месте (другом форуме), но уж очень: а).интересно и б).к месту: http://www.91.ru/Education/Books/Os/21.htm Здесь, если попытаться разобраться с вашими утверждениями, а не просто злословить в форуме ;-), просто необходимо одно отступление в сторону: Говорить о требованиях realtime (называть их та или нет) можно только применительно к программным системам, уровня структурной сложности выше какого-то порога. Примерять требования realtime к системе, состоящей из одного выполняющегося потока, который время от времени прерывается обработчиком прерывания - нонсенс!!! Довольно большая часть примеров в обсуждениях форма относительно RTOS берутся именно из этой области: "... а у меня прерывание обрабатывается в 6 мкс. ... А у меня - в 4.5!!! - ура...". Программные системы - сложные системы. "Сложные" здесь сказано не в том смысле, что "...как же трудно нам было эту систему разрабатывать...". И не в том, в котором мы обращаемся к своему руководству, мотивируя - сколько нужно заплатить за изготовление такой сложной вещи ;-)... Имеется в виду системная сложность... есть такое строгое понятие. Не количественное, а качественное - это тот порог сложности, когда в системе, состоящей из большого числа компонент, каждый из которых элементарно прост и обладает набором простейших свойств - возникают свойства системы, никак не вытекающие из свойств компонент - следствие "самоорганизации". На этот счёт есть очень интересный сборник: "Принципы самоорганизации", М.:"Мир", год 1978-1979 - материалы 1-й международной конференции по самоорганизации сложных систем. В этом смысле - программная система выше какого-то уровня может быть "сложная"... Об этом где-то (к сожалению не вспомню) говорил академик Ершов, в 2-х словах (в моём вольном пересказе): "... существуют естественные сложные системы: биологические, экономические - но они настолько сложны, что у нас нет методологии для их изучения. Все искусственные системы, с которыми сталкивалось человечество до сих пор - простые: их свойства детерминированы, предсказуемы и являются прямым следствием свойств составляющих частей. В этом смысле автомобиль, самолёт - простые системы. Компьютерные системы - первые искусственные системы, которые "сложные" - они достаточно сложны, чтобы попадать под эту квалификацию, но они достаточно просты по сравнению с естественными сложными системами, для того, что бы на их поведении мы могли изучать принципы самоорганизации...". Так вот, всё, что мы неудачно квалифицировали как realtime - имеет смысл только применительно к достаточно сложным проектам, когда мы уже не можем детерминировано предсказать, как поведёт себя система во всех своих 30млрд. возможных состояниях... Если система достаточно проста - мы можем проследить все её состояния и детерминированные переходы, и гарантированно исключить возможность deadlock-ов при любых переходов. Но при некоторой сложности, в виду, более того, комбинаторного роста числа состояний как функций сложности - мы этого сделать уже не сможем. И вот только возникает необходимость некоторого набора общих правил, при соблюдении которых система будет застрахована от deadlock-ов не для конкретных переходов, а при любых возможных ситуациях в системе. Вот тогда и возникают: - наличие достаточного числа приоритетных уровней; - различные процедуры диспетчирования; - требование наследования приоритетов; - требование отсутствия инверсии приоритетов; ... Т.е. для относительно простых систем, когда вы проектируете "механизированную матрёшку" (типичной матрёшкой последних лет являются мобильне телефоны) - бессмысленно даже пытаться прилагать вот те требования, которые известны как realtime...
Вы знаете, вот здесь, в том, что "лучше быть здоровым и богатым, чем бедным и больным"(с) - я абсолютно согласен ;-)... |
|||||||||||||||||
|
|||||||||||||||||
У вас других аргументов, кроме перехода на личности уже не осталось ? Про пассивную защиту, механические ограничители и плавкие предохранители вы тоже ничего не знаете... |
|||||||||||||||||
|
SY,
EK |
|||||||||||||||||
|
|||||||||||||||||
|
Кто рассматривал гистограммы временных реакций Windows при очень Ссылочку плиииз. на методику испытаний. Очевидно ж, что можно совершенно по разному строить эти гистограммы - и не обязательно в виндоуз. |
|||||||||||||||||
|
SY,
EK |
|||||||||||||||||
|
|||||||||||||||||
|
Все искусственные системы, с которыми сталкивалось
человечество до сих пор - простые: их свойства детерминированы, предсказуемы и являются прямым следствием свойств составляющих частей. даже обыкновенный клапан - электромагнитный или пневмо - и тот имеет разброс времени срабатывания, посему даже для простейшей системы детерминируемость и предсказуемость примерно такая же, как у электрона в атоме, и примерно так же попытки чего-то там измерить получше влияют на свойства самой системы. |
|||||||||||||||||
|
SY,
EK |
|||||||||||||||||
|
|||||||||||||||||
Я уже говорил: на параноидальные крики "аргументы!", "ссылочки"... и т.д. - хочу - дам, хочу - не дам ;-). Сами ищите... Дорогуша, у вас болезненное ощущение, что вам кто-то что-то должен... может в раннем детстве чего-то не додали? У меня нет ни времени, ни желания - заниматься выяснением с вами "кто дурнее"... если я время теряю в форуме, то совершенно не для этого, у меня другие планы. Потому что пишутся все эти ... "аргументы?" - отнюдь не из испепеляющей жажды знаний ;-) ;-). Есть у вас конструктивные мнения - покажите, нет - .... ну, понятно куда, да? А то чуть что - в крик: "на личности, ... на личности" - не нужна мне ваша личность, нафиг не интересна... Есть что по существу, позитивно добавить - милости просим, нет..., "устал" - так не путайся под ногами, пока на голову не наступили... Чего там из кустов огрызаться: и то не так, и это не в жилу... Ваши предложения? Ваши мнения? Излагайте... P.S. "Я своему слову хозяин: хочу - дал, хочу - обратно взял"(с). P.P.S. Это последний мой ответ в форуме на реплики, которые мне кажутся не конструктивными - прошу не обессудить, если чьи-то постинги, даже адресованные в диалоге непосредственно мне - я буду просто игнорировать... |
|||||||||||||||||
|
|||||||||||||||||
Если "трезво посмотреть на окружающую вас действительность" - то выясниться, что "время реакции", да и "время вообще" - очень слабо относится к критерию realtime... У вас могут быть весьма сложные системы, но принципиально "последовательностного" свойства, вот например: - если у вас система АСУТП последовательным опросом анализирует состояние 15000 вентилей, заслонок, датчиков... после чего по определённому алгоритму анализируя эту карту управляет несколькими из 20000 исполнительных механизмов... а потом всё по-новой и так много раз - то здесь у вас никоим образом не будут возникать проблемы из области realtime, и обсуждать их там - чистая спекуляция. Так работали первые АСУ управления пуска-останова турбин АСУ (не знаю, как там сделано сейчас). - совсем недавно я занимался адаптацией в QNX программного проекта NFIS. Это public совместный проект USA Национального Агенства Стандартизации и ФБР, по обработке дактилоскопических отпечатков - 13 лет исследований и создания кода под Linux. Несколько сот тысяч (!) строк кода, сложнейшие алгоритмы 2-х мерных DSP... В реальных приложенийх - всё критично по времени: 0.5 сек. на обработку - приемлемо, 3-5 ... уже на пределе целесообразности. Но ... всё это не имеет к realtime минимального касательства - это фильтр, пусть и очень сложный: на входе сигнал, который нужно трансформировать в выходной сигнал... Так вот, возвращаясь... Когда говорится об "гарантированностях" в realtime, то забота, главным образом, состоит не в том, что некоторый процесс не успеет "включиться"... Проблема состоит в том, что при N исполняющихся процессых/потоках, вот тому критическому I-му процессу - просто не дадут включиться другие N-1 - либо на протяжении критического интервала, либо вообще... Вот где проблема realtime, а не в реакции на единичное внешнее событие: "быстро" или "не очень"! Это то как-раз совсем не сложно обеспечить, как вы и пишете. И охарактеризовать конкретной "цифирью". А какой количественной оценкой вы будете регламентировать частоту/вероятность возникновения всё той же инверсии приоритетов (не единственного, но одного из механизмов вот того блокирования критического процесса)? И как измерять, при вероятностях 10**-9, 10**-12...?
А он и будет таким, если его трепать в контексте того обсуждения, которое потребовало уже 3-х веток :D :D :D : http://forum.cta.ru/forum_posts.asp?TID=168&PN=1 http://forum.cta.ru/forum_posts.asp?TID=122&PN=1 http://forum.cta.ru/forum_posts.asp?TID=167&PN=1 Он ещё будет и спекулятивным! Зачем нужно было разным людям создавать одинаковые темы в 3-х экземплярах? Интересные совпадения? Я могу только предполагать: 1. автора просто "прёт" похвастаться на примере частной решённой задачи, мол "какой я умный...". Так - это обращение ко всем - в подобных случаях пишите мне мэйлом, поприсите... я любому желающему в форуме напишу: "какой мол пацан Вася Пупкин - умный". Мне не жалко. 2. показать, что задачу, похожую на realtime, или как он её понимает - вот он решил в OS общего применения: OS/2, FreeBSD ... кто больше? Что "задачу решил", как говорит М.Жванецкий, - "верю"... Или хотите сказать, что realtime задачи можно решать в принципе в любой OS? Как говорит тот же автор: "не верю - отныне и во веки веков, аминь!". Вот так и превращаются обсуждения реальных проблем, существующих в архитектурах для realtime в обсуждение... чего? Вот того, что вы и называли... |
|||||||||||||||||
|
|||||||||||||||||
У меня нет возражений. Давайте воздерживаться.
Я уже читал эту статью. Она доступна с официального сайта www.osp.ru. Хорошая статья, коих в ОС, немало. Правда, связи статьи с текущим разговором я так и не ощущаю...
1. Давайте все-таки от реал-тайма отходить... раз уж договорились... 2. У нас системы имеют порядка 10^30 (1 с 30 нулями) состояний... ни число состояний, ни число входов/выходов не характеризуют сложность системы. 3. К сожалению, и детерминированность/недетерминированность тоже не есть показатель сложности...
Вопрос по теме, как там у нас с дед-локами в QNX? Все еще возможны? Просто, у нас дед-локи конструктивно исключены... и приоритетов нет... и диспечеризация чрезвычайно простая... об инверсии приоритетов тоже никто не заботится... по понятным причинам... В этом смысле не совсем понятна актуальность борьбы с тем, чего у нас в принципе нет...
Давайте все-таки либо определять термин РТ, либо, как Вы уже вроде б согласились, его не употреблять...
Давайте на РТ не циклиться. А то опять выясняется, что Вы говорите РТ, а Вас никто не понимает, потому как у каждого в голове свои тараканы насчет РТ... ведь для многих РТ - это действительно быстродействие и больше ничего.
Я Вам скажу зачем эта информация об ОС нужна "простым смертным": эта информация нужна для того, чтобы при решении задачи принять правильное решение.
Увы, никакие архитектурные решения QNX ничего не гарантируют... "as is" - это все гарантии QNX :-) а те же исследования тех же самых дидикайтед-системс, ссылку на которые Вы приводили, - не более, чем эксперименты с "черным ящиком"... Не помню, говорил я это уже или нет, но пользователя (в данном случае - разработчика системы) интересует одно: будет ли его конкретный алгоритм иметь требуемые динамические характеристики или нет. Увы, но априорно ответить на этот вопрос для QNX невозможно. Эта проблема, к слову, рассмотрена в статье "Распределение вычислительных ресурсов в средах с мультипоточной реализацией гипер-автомата", к сожалению, ссылку на текст, смогу дать только в январе, после собственно конференции SICPRO'04...
Вполне возможно, что Вы и правы... а может как и в нашем случае с ДОС, таких проблем там просто нет. Кстати, вполне может быть... ведь те же дед-локи - это прямое следствие QNX-решения API... ну, через обмен сообщениями...
К какому реал-тайму? К тому, про который мы решили не говорить, что ль? Я лично про него и не говорю, а говорю только об обеспечении ВРС на ВС. Четко и ясно.
Ну так и давайте, - прекратим лирику и будем изъясняться в строгих технических терминах. |
|||||||||||||||||
|
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК http://reflex-language.narod.ru/ |
|||||||||||||||||
|
|||||||||||||||||
С вопросами веры - вам надо на другой сайт ходит. Обидно вам что вам на слово никто не верит - ну а что вы еще хотите, когда допускаете тучу ляпов - хотя бы FFT обзываете DSP и на простейшие вопросы отвечаете - вам надо - сами и ищите |
|||||||||||||||||
|
SY,
EK |
|||||||||||||||||
|
|||||||||||||||||
Да на здоровье... Только тогда нужно указ какой-то, в рамках форума... "с сей даты термин realtime в обсуждениях отменить и использовать..." - что испльзовать? Так хоть неудачный есть, но термин... Так что пусть пока он остаётся, пока вы лучше не предложите, но только с полным отрывом от скоростных характеристик.
О каких дед-локах вы говорите? Вы, наверное, имеете в виду, предупреждение никогда не использовать встречные клиент-серверные отношения между подсистемами (приложениями) в QNX? Но это относится только к сфере принципиально неверного проектирования приложений, но при чём здесь архитектура OS?
"У нас нет" - это только в том случае, если только у вас нет: - ассинхроных параллелизмов, при необходимости синхронизации и взаимодействия между ними; - распределения, захватов и блокирований в ожидании критических ресурсов; ... т.е. для решения какой-то частной проблемы - может и нет, в общем случае - не верю! |
|||||||||||||||||
|
|||||||||||||||||
Ответить 
|
Страница <1234 12> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
