|
|
реал тайм осы |
Есть и бОльшие неприятности ;-): - когда сервисов в цепочке вызовов становится >2, и когда сервисы обращаются друг-за-другом каскодно: передавая запрос "вниз", а потом возвращая результаты "вверх"... Считается, что это гораздо более отвратительная ситуация для наследования приоритетов (см. Р.Кёртен "Введение в QNX Neutrino-2", С.-Пб., 2003) - но это нужно смотреть и проверять. Вот эта, названная, книга - пожалуй, самое лучшее руководство для понимания микроядерной архитектуры с обменом сообщениями - для понимания, местами, лучше, чем родная документация QNX (да ещё и на русском языке ;-)). Но "проверять" - потому, что в программных кодах Кёртена, в очень немногих местах, как я выяснил при проверке - есть "лажи", которые не только не могут работать в принципе, но даже не компилируются. Пришлось переделывать... |
||||
 |
||||
|
(пишу урывками так как нет времени) Пусть произошло внешнее событие которого ждет единственная высокоприоритетная задача. Допустим задача вычисляет что то связанное с этим событием в течении 1,5 мсек (для простоты предположим что это константа, хотя конечно это как правило не так), а затем выдает наружу свою реакцию. Конечно после события задача не сразу получит управление, а через некоторое время связанное с латентностью драйвера, переключения контекстов и т.п (если реакция выдается так же через драйвер, то и эта латентность добавляется). Допустим все латентности добавляют максимум 5 мксек. Внешнее событие может произойти в «плохое» время, когда ядро, чей нибудь драйвер или приложение выполняют код с запрещенными прерываниями. Допустим, что даже написанные кривыми ручками драйвера или приложения никогда не запрещают прерывания более чем на 5 мксек. Во время вычисления (в течении 1500мксек) в зависимости от поведения внешнего мира могут приходить (а могут и не прийти) еще прерывания, которые конечно не приводят к вытеснению нашей задачи (она самая приоритетная), но отъедают время (допустим в худшем случае 10мксек). Таким образом система выдаст реакцию в интервале от 1505 до 1520 мксек после внешнего события. Видно что степень детерминизма (предсказуемости) очень высока (абсолютное значение временнОго разброса реакции 15мксек). Теперь пусть в системе есть еще одна задача с таким же высоким приоритетом. Если наше событие случается когда эта еще одна задача не выполняется, то все идет как и раньше. Если же вторая задача выполняется, то при «чистом» вытесняющем алгоритме наша задача не получит управление пока эта вторая задача не закончит выполнение. То есть предсказуемости никакой. Дай бог если эта вторая задача написана кем то из соседнего отдела, кто сможет хотя бы примерно сказать наибольшее время ее исполнения (для оценки наихудшего случая). Собственно это я и имел ввиду, что по настоящему быструю задачу жесткого реального времени желательно оформлять как единственную, которая имеет самый высокий приоритет. Пусть у нас не «чистое» вытеснение, а скажем среди задач с одним приоритетом крутится round-robin. В этом случае наша задача получит управление в худшем случае через 1 слайс (допустим slice=1мсек). Другим словами реакция произойдет в интервале от 1505 до 3520 мксек. То есть даже одна задача с таким же приоритетом ухудшает предсказуемость более чем в 100 раз (абсолютное значение разброса 2015 мксек вместо 15 мксек). Если на нашем приоритете может существовать 10 задач, то время реакции будет разбросано в интервале 1505-21520 мксек (так как наша задача вычисляет что то в течении 1,5 слайсов, то поработав 1мсек когда до нее дойдет очередь в первый раз, она отдаст управление и будет ждать еще 10 слайсов/мсек что бы закончить свою работу). Разумеется это анализ наихудшего случая (то есть по идее верятность появления реакции более чем через 21520 мксек равна нулю). Соответственно для задач жесткого реального времени где нужно уложиться в 30мсек наша программа вполне подходит. Но представим, что автор или какой нибудь рационализатор «улучшил» программу, в результате чего она стала выполняться 2010мксек вместо 1500 мксек. В итоге получим что и во время второго слайса наша программа не успеет досчитать, а худшее время реакции увеличится сразу на 10 мсек и появится ненулевая вероятность того что наша программа нарушит свой дедлайн (30 мсек) и что нибудь в результате взорвется. С Уважением, Сергей Сорокин
|
||||
|
||||
> Вопрос не только в метрике (т.е. количественном различии), может более того отличаться и качественный характер процесса (СРВ - СНРВ). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Я бы сказал что динамичесие метрики системы управления являются следствием ее внутренних процессов со всеми их качествами. То есть Вы все правильно говорите насчет инверсии приоритетов, но это относится к другому уровню рассмотрения (Вы переключились от СРВ к ОСРВ, хотя СРВ совсем не обязательно содержит в себе ОСРВ). Например если мы считаем автомобилем только то, на чем можно передвигаться, то с точки зрения системы "автомобиль-пользователь", пользователь скажем либо может двигаться на автомобиле, либо не может. С этой точки зрения все равно почему автомобиль потерял свои потребительские свойства - залили плохой бензин или сел аккмулятор. Так и с точки зрения техпроцесса не важно почему система управления не выдала ВОВРЕМЯ необходимое воздействие - из-за инверсии приоритетов, ошибки приложения или неисправности аппаратных средств. При проектировании системы должны учитываться любые возможности. События выходящие из системы управления как из черного ящика (какие бы качественно процессы там внутри не происходили) характеризуются их логической и временнОй адекватностью технологическому процессу. И с точки зрения управления технологическим процессом именно логическая и временнАя правильность генерируемых системой управления воздействий имеет значение. Вы же сами об этом чуть позже и пишете (о взгляде пользователя на систему и о том что ему все равно).
|
||||
|
||||
|
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Проблемы в том, что воздействия и реакции могут быть не только цифровыми, но и аналоговыми. Импульсные воздействия могут вызывать потнциальные реакции (и наоборот), воздействия могут приходить одновременно на несколько линий, аналоговое воздействие может вызывать дискретную реакцию (и наоборот) и т.п.
Мне в свою очередь кажется что при анализе софт реалтайм систем можно в определенных ситуациях применить теорию массового обслуживания (применяется в телекоммуникациях). Поток задач на исполнение это как бы поток сообщений и можно для разных параметров расчитать вероятность обслуживания сообщения (выполнения задачи) за определенный интервал времени. Насколько я помню при Пуассоновском характере запросов эта вероятность описывается распределением Релея (такая горбатая кривулька).
С Уважением, Сергей Сорокин
|
||||
|
||||
|
Наследование конечно не совсем адекватный термин, но лучшего пока не придумали. Мне кажется что синхронизирующие примитивы могли бы работать в следующем стиле. При получении запроса на ресурс от высокоприоритетной задачи, примитив первым делом ставит его в голову своей очереди. Затем если какая то менее приоритетная задача была вытеснена после блокировки этого реурса, то приоритет этой задачи поднимается до уровня только что полученного запроса. В результате управление получит "застрявшая" на ресурсе задача, но как только она из него выйдет, планировщик должен вернуть этой задаче старый (низкий) приоритет. В результате управление тут же получит высокоприоритетная задача ждущая на пороге. То есть адаптаця приоритета происходит на очень котроткое время что бы только "пропихнуть" низкоприоритетную задачу сквозь критическую секцию. То есть происходит не наследование (потому как строго говоря потомков не образуется), а врЕменная "передача флага" от высокоприоритетной задачи, "застрявшей" на ресурсе низкоприоритетной задаче. С Уважением Сергей Сорокин
|
||||
|
||||
|
Sergey Sorokin
Если Вы прочитаете свое последнее предложение, то сразу увидите противоречие в своем рассуждении. В этом предлжении Вы согласились со мной, что изолированную систему управления нельзя отнести ни к СРВ ни к СНРВ, пока она не будет рассмотрена вместе с объектом управления. В общем так и есть, особенно если исходить из вот этого определения Реальное время (программное обеспечение) (IEEE 610.12 - 1990): Относится к системе или режиму работы в котором вычисления проводятся в течении времени, определяемого внешним процессом, с целью управления или мониторинга внешнего процесса по результатам этих вычислений. Но и определение Тиммермана тоже верное, только оно для специалистов, поскольку многое подразумевает, а стандарт , он как говорил мой начальник "для военных - чтоб каждый сержант понял" когда заставлял меня переписывать руководство по эксплуатации :)) Ведь если систма абсолютно предсказуемо реагирует на событие через 10 сек, а надо через 10 мсек, то непонятно, о чем думает разработчик. В том-то и дело при условии предсказуемости не может в принципе возникнуть ситуация, о которой Вы говорите, когда временные метрики объекта управления и управляющей системы не совпадут. Ведь это противоречит здравому смыслу или похоже на саботаж. Теперь по поводу анализа многопоточной реал тайм системы. Еще до недавнего времени я бы с Вами согласился безоговорочно, но! Меня все таки очень заинтересовал вопрос, на который я раньше не обращал внимания, зачем разработчики ОС, позиционирующихся на рынке как real time и embedded стремятся к наращиванию колличества уровней приоритетов? 64 в QNX это еще ернда, но в других их ведь 256! А это уже противоречит всему опыту разработки и моему и всех моих знакомых, да и здесь была масса высказываний в том же духе. Неужели разработчики ОС такие дураки? Или это мы чего-то не знаем? Ну я уже писал, что ответом на этот вопрос является RMS технология прогнозирвания поведения РТ системы. (точнее диспетчеризации ее потоков). К сожалению пока я в ней не й до конца не разобрался, нет пока времени, но когда я увидел колличество цитирований и упоминаний в инете, причем в разных (а не в перепечатаной там и тут статье) источниках, когда я наткнулся на описание этого механизма в нескольких университетских курсах по ОСРВ, я пришел к мысли, что, по видимому, это работает, и разбираться с ним надо обязательно. |
||||
|
Draggan
Kharkov, QNX Seminars |
||||
|
||||
Я эту свою ... нить ;-) рассуждений, писал в несколько другом контексте... Не в том смысле, что не может быть СРВ программной системы, построенной в качестве единого монолитного процесса. Может, конечно. Либо имеющее несколько потоков, принудительно переключаемых по кругу - round-robin... либо и вообще без какой либо диспетчеризации: просто программно поочерёдно опрашивая N каналов, и при обнаружении сигнала в I-м канале - производить соответствующую реакцию. Но... 1. так построенная система - это синхронный программный опрос (даже при принудительном переключении потоков) - всесто ассинхронного уведомления о событии (прерывания). 2. раз нет ассинхронных возмущений (т.е. во внешнем мире они - ассинхронные, но они помещаются во входную очередь опроса, и опрашиваются синхронно!) - то нет характерных проблем риэлтайм... и нечего их разрешать. 3. поэтому я нескольно отодвинул в сторону рассмотрение так построенных систем, т.к. тема разговора была названа "ОС реального времени", а не "системы управления реального времени", т.е. в это рассмотрение просто не попадают синхронные системы... у них нет обсуждаемых проблем. 4. наконец, последнее. Если всё так хорошо в системах кругового (программного) опроса, то почему вообще везде и повсеместно их не применять, если в них нет тех проблем, которые такие противные в системах на базе ОСРВ??? Да в том же, чем программный опрос последовательного порта отличается от обслуживания его по прерыванию: скоростью реакции и загруженностью процессора! Если у вас N каналов - то и время обнаружения события с канала N вы обнаруживаете за в N раз больший интервал. А когда N (число событий - степеней свободы) = 1000? или 10000? Т.е. такие системы имеют право быть, но, очевидно, только для управления медленными, вялотекущими процессами... кстати, для многих именно АСУТП это - нормальное условие. Плюс к этому то, что помимо обслуживания N каналов реагирования эта система уже ничем больше заниматься не может! (Это если без специальных ухищрений, но тогда сразу же вылезают всё те же "ассинхронные" проблемы, что и в RTOS). |
||||
|
||||
|
Еще одно замечание по поводу определения. Напомню еще раз предмет спора:
Система реального времени - это система, предсказуемо реагирующая на непредсказуемые внешние события. (с уточнением, что в под предсказуемостью подразумевается временнАя предсказуемость) Сергей Сорокин пишет, что в СРВ реакция на событие должна быть обязательно, и не важно опоздала она или ее не было вообще. Значит под словами реакция СРВ имеет смысл понимать только "правильная реакция"! Если она опаздала, то смело можно считать, что ее небыло вовсе! Значит когда мы говорим "предсказуемо реагирует" - речь идет о реакции ПРАВИЛЬНОЙ и происшедшей ВОВРЕМЯ. |
||||
|
Draggan
Kharkov, QNX Seminars |
||||
|
||||
Что касается компортов... На компорты обычно вешается драйвер, у которого есть буфер. У самого компорта кстати тоже может быть буфер. Так что вполне можно асинхронно принять информацию и положить в буфер, а с буфер можно уже и round-robbin'ом опрашивать. А поскольку опрос наличия данных в буфере - достаточно быстрая операция, то для N компортов интервал обслуживания не будет существенно отличатся от интервала для одного порта. |
||||
|
SY,
EK |
||||
|
||||
Вопрос не в частностях, /dev/ser был выбран для образца как простейший случай... Вопрос в том, что система может: - ожидать и реагировать на ассинхронные события, и тогда имеет смысл обсуждений о применении RTOS, и GOS, или ещё чего... - и может буферизировать (разным, кстати, образом) входящие асинхронные события, а потом вкруговую обрабатывать их как синхронные, при этом система уже вряд ли может "отвлечься" на выполнение ещё како-го то задания, поэтому такие понятия, как многозадачность, параллелизмы и OS вообще (как механизм организации этих много-) - ей противопоказаны вообще, и рассматриваться она должна совсем отдельным классом: там свои проблемы, здесь - свои.
В общем случае, короткая или длинная процедура обслуживания канала - не есть принципиально важно, важно как синхронно он обслуживается. А последнюю фразу я просто не понял...: время синхронного обслуживания N каналов, даже если оно и очень невелико для одного канала, будет ровно в N раз больше, чем для 1-го. |
||||
|
||||
Ответить 
|
Страница <1 2829303132 36> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
