реал тайм осы |
Ответить | Страница <1 2324252627 36> |
Автор | ||
Действительный член Присоединился: 14 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 267 |
Опубликовано: 23 Ноябрь 2003 19:31 |
|
Мне кажется, что это слишком сильное утверждение... или требует более детальных разъяснений. Но главное, из-за чего я решил ответить на этот постинг, вот он:
Это насколько верное, по моему мнению, утверждение, и настолько не очевидно при "первом подходе", что мне захотелось на нём специально остановиться и дополнить. Мне неоднократно приходилось быть руководителем проекта, или работать "играющим тренером" в команде разработчиков, а, поэтому, копаться и искать обоснования в чужих текстах. И у меня сложилось в результате отчётливое мнение: - есть классы задач, которые невозможно или крайне сложно (по крайней мере ещё и эффективно) реализовать в рамках равноприоритетных ветвей выполнения; - но таких случаев - исключительное меньшинство: единичные проценты... - а что "первым просится", когда начинают проект?: набухать по максимуму приоритета ветвям, которые функционально критические, потом ещё поболее тем, которые кажутся важны... и так далее; - я абсолютно солидарен с высказанным Sergey Sorokin предположением, что чем меньше приоритетов задействуют ветви выполнения - тем качественне уровень исполнения! - только тогда, когда 100-кратный анализ 2-х ветвей не приводит к положительному решению по их равноприоритетной реализации, используя синхронизации IPC - так вот только тогда можно начинать подумывать о разносе приоритетов уровней. - в классике параллелизмов (Дэйкстра, Хоар, мн.др.) предложено и аппробировано множество синхронизирующих примитивов: mutex, semaphore, condvar, rw-, spin-, sleepon- блокировки ... это только POSIX, да и то, наверное, не все (что вспомнил). Между разноприоритетными ветвями вы сразу же разрушаете логику работу всех тонких синхронизирующих механизмов, точнее, они просто не работают... Раздвигая приоритеты - вы принудительным силовым образом ломаете всю логику и возможности синхронизаций, поведение которых как-раз "прогнозируемо"! (обратите внимание, что в классической теории Дэйкстры - есть множество механизмов, но вообще нет какого-либо рассмотрения и даже упоминания приоритетности). - возвращаясь к своему опыту: использование программистом 5-7 и более приоритетных уровней (за исключением случаев, когда это может быть аргументированно доказано) - уже само по себе есть достаточным основанием, чтобы подумать о том, чтоб "гнать его в шею"... Но всё это, как ни странно, не противоречит требованиям большого числа уровней в RTOS: - во-первых, я везде оговаривался - есть особые случаи, а OS должна обслуживать все, пусть даже самые редкие и экзотические ситуации; - во-вторых, сами компоненты OS используют некоторое число приоритетных уровней (4-6-8). А приоритетные уровни, используемые прикладным проектом, желательно, чтобы не перекрывались (совпадали) с системными, во избежание их интерференции... P.S. последнее замечание о числе уровней, используемых самой OS - никак не противоречит сказанному выше, и не должно толковаться как указание на низкую квалификацию её разработчиков: всё сказанное выше относится главным образом к прикладному программированию. Системное программирование, оперирующее с собственно осуществлением самих диспетчирующих процессов и т.п. - существенно отличается по характеру, и может требовать большего расщепления приоритетных уровней. |
||
Действительный член Присоединился: 14 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 267 |
||
Вернусь к давней цитате:
Она не только удачна по форме, но и очень точная по содержанию. И вспомнилась в связи с моим недавним постингом об отсутствии критериев, в том числе (или даже в первую очередь) - и критериев компетентности принимающих решения (а не про "провайдеров" и "модемов" я писал, как некоторым по простоте душевной могло показаться ;-)). Здесь не один раз в обсуждении с гордостью произносился аргумент: "а у нас сделано на ..., и - работает, и - заказчик не нахвалится...". Я специально не цитирую на чём это сделано, вопрос в принципе... "Работает - не работает" - не может быть критерием! Ни на йоту не добавляющего в доказательство того, что то, что сделано - сделано и работает корректно (это известное и признанное уже всем миром утверждение: "тестирование ничего не может доказать", что послужило основанием для разработок ADA). Критерии оценки компетентности разработчиков должны гарантировать, что то что сделано - сделано корректно в максимально возможной на сегодня мере. А не того, что - "оно работает". И это - ещё одна составляющая realtim-овости СРВ, хоть и не техническая. Работать должно в принципе, во всех мыслимых ситуациях... Когда не игнорируется ни одно из требований и правил: если нарушенное требование может выстрелить - оно обязательно выстрелит... когда-то. А иначе: - Давайте погоняем реактор на запредельных мощностях, ведь это у нас "работало" 100 раз... И мы имеем полыхающий 4-й блок в Чернобыле. - Давайте организуем учения по упрощённой программе (с командующим стрельбами, но без командующего учениями), ведь мы это уже делали 10 раз... И придурки из ПВО заваливают российский ТУ-154 с более чем 70-тью пассажирами. - Давайте пройдём на высоте бреющего полёта... попонтуем ниже всяких норм и правил, ведь только вчера это делали... И прошлись. В Львовском Скныре - по мясу от человеческих тел. Ведь всё это, и то, что мы обсуждаем - всё это явления одного порядка. И ещё обратите на одно обстоятельство. Разработчику, который принимает решение (в том числе, и как менеджер, чем он не должен быть! в принципе - что $90 лучше, чем $7000) - ему, в случае краха его системы, особенно если она critical mission, скорее всего - не придётся лично нести ответственность за последствия. Во-первых, в результате достаточно серьёзных последствий, горящая праведным гневом общественность не удовлетвориться такой жертвой (стрелочника покарали!) - откупаться перед общественностью будут: директором станции, министром обороны, главкомом... Праведный гнев должен быть удовлетворён! Во-вторых, между конкретным проектантом и заказчиком стоит ещё один слой: фирма исполнитель. Ну и что, поканючит этот горе-проектант перед своим директором (хозяином), размазывая сопли по лицу: "... ты же требовал подешевше-подешевше, вот я и старался угодить...". И в самом худшем исходе - степенью личной ответственности станет "Уволить!". Жуть... Так вот ещё. При принятии решений не нужно, хотя бы подсознательно, закладываться на вот эти "смягчающие" обстоятельства! |
||
Профили участников
Послать частное письмо
Поиск публикаций участников
Посетить домашнюю страницу участника
Добавить в список приятелей
Действительный член Присоединился: 08 Сентябрь 2003 Категория: Russian Federation Online Status: Offline Публикации: 178 |
||
Я не знаю, каким вы там коллективом разработчиков руководили...С учетом того, что всячески открещиваетесь от, как вы говорите - "механизированных матрешек", кричите - не мое и категорически не понимаете, что система реального времени - это не только "мое" ПО под "моей" ос, а еще много еще чего другого - и механика, и электрика, и датчики, и контроллеры, и коллеги по работе... И у каждого свои грабли... "Работает" - это значит эксплуатируется как в штатных режимах, так и в "разумных" нештатных режимах, в том числе и посредством разных степеней защиты вне ПО управляющего компьютера - от элементарных плавких предохранителей и UPS-сов, до "механизированных матрешек"... Во всех приводимых случаях проблемы были не с ПО, а с разрухой в голове - в Чернобыле первым делом отключили защиту, в установке для облучения - убрали защиту и т.д. "Работать" штатно может, как правило, только одним способом , а вот работать нештатно, или если угодно "не работать" может многими разными способами, обработка этих ситуаций может занимать до половины или даже больше кода, но обсуждение этих проблем оказывается не так интересно, как [поскипано внутренним цензором] |
||
SY,
EK |
||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||
Простите, если сложилось такое мнение, но я и не говорю, что Вы говорили. :) Кстати, пользуясь случаем, хочу сказать, что с большим удовольствием прочел Вашу статью. Не скажу, что не возникло вопросов, но ведь это и хорошо. По поводу времени. Дабы уточнить. :) Предсказуемость в процитированном мной определении идет в смысле timely, то есть временная предсказуемость (и не предсказуемость). В статье есть соответсвующее уточнение. То что Olej так или иначе перечислял эти свойства я знаю. Я лишь хотел подчеркнуть, что несмотря на неслишком большую освещенность данного вопроса (не по Вашей вине). В мире этому вопросу уделялось много внимания и, возможно, не стоит заново изобретать велосипед. (Может тут я и перегибаю палку, дискуссия -то интерестная.) А насчет простого определения для сложного понятия... по моему это тоже важно. Есть развернутое определение POSIX стандарта, есть DIN44300, есть ряд других, но! Лично мне нравится определение Timmermanа краткостью, и несмотря на Ваши возражения, все таки точностью.(с поправкой, о которой я уже говорил predictable в смысле timely). К тому же Ваш текстовый редактор НЕ ВСЕГДА во время напечатает букву, когда вы нажмете на клавишу. А если система в этот момент, например свопирует? Вам придется подождать :). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Хочу отметить, что предыдущее определение давалось для СРВ, а не для ОСРВ. Помоему это просто придирки, непонятно чем вызванные :) ОСРВ обеспечивает работу СРВ в соответствии с этим определением :) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Это никак не связано с предсказуемостью или детерминированностью. Однозадачная система является >предсказуемой, многозадачная система с планировщиком time slicing является предсказуемой. Любая >программная система является предсказуемой покуда не использует для планирования своих действий >аппаратных датчиков случайных чисел. Другое дело, что анализ многозадачной системы в условиях отсутствия >подробной документации по ОС, и/или в условиях применения программ третьих производителей является очень >трудной задачей. Более того, предсказуемость поведения ОС еще не означает предсказуемости поведения какого >либо конкретного процесса, так как процесс делит ресурсы и сервисы ОС с другими процессами, активность >которых может зависеть от случайно сложившихся внешних факторов. В системах с вытесняющей многозадачностью >в общем случае только одна задача, имеющая наивысший по сравнению со всеми другими задачами приоритет, >может быть предсказуемой/ детерминированной (с точностью до возможных проблем с инверсией приоритетов). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Начнем с конца. :) ОСРВ должна решать проблему инверсии приоритетов. И конкретные ОСРВ эту проблему успешно решают. Проверено. Второе. Ведь о предсказуемости здесь идет речь в контексте ОСРВ! Так и давайте не говорить об однозадачных системах. В целом я с Вами согласен, что данный пункт слабо связан с предсказуемостью, хотя на мой взгяд, проблема лишь в том, что Вы рассматриваете его оторвано от контекста. Ну а то, что многопоточность и вытесняющее управление приоритетами является одной из основных черт ОСРВ, так вроде Вы и сами об этом писали. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Это так же не связано с предсказуемостью. Наилучшая общая предсказуемость (не скорость) у одноприоритетных >процессов с планировкой в стиле round-robin. Я бы советовал там, где можно, использовать не более 3 > приоритетов (задачи «жесткого реального времени», «мягкого реального времени» и «фоновые» задачи). Иначе >при большом количестве задач с приоритетами можно «перемудрить» и в результате какая нибудь нужная задача >будет «поражена в правах» >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Разрешите с Вами не согласиться. Здесь уже высказывалось мнение, что 32 уровня приоритета этого много, 64 - просто отвратительно, а в самый раз - 16. Я лично удивился. В целом трудно спорить, что наилучшей из реализованных на сегодняшний день, архитектурой ОСРВ является архитектура клиент-сервер. (Кстати, мне просто интерестно, какие системы реализованы по объектно ориентированной архитектуре?) А в такой системе при выделении сервисов в отдельные сервера со своими потоками их диспетчерезация тербует некоторого коллическтва приоритетов. Т.с. для служебных нужд. Далее нужно две группы приоритетов для приложений - высокие для реалтайм потоков и низкие для вспомогательных. И общее колличество зависит от конкретной задачи. Конечно для прозрачности, и, значит, эффективности системы чем меньше задействовано приоритетов тем лучше, но повторяю, все зависит от масштаба задачи. И наконец. В любезном моему сердцу QNXе 64 уровня приоритетов, в WindowsCE - 256, VxWorks - 256, ELDS - 99. Может это действительно я что-то не понимаю, а вместе со мной и большинство производителей систем, прочно позиционирующихся как embedded и realtime? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Я не знаю ни одной ОС, где бы эти механизмы не были прогнозируемыми. Возможно есть ОС где скажем выбор планировщиком >задачи для выполнения или порядок обработки очереди к семафору управляется датчиком случайных чисел, я просто про такие >не слышал. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Согласен. Но повторюсь - это список требований. Возможно явно указывать на этот параметр и лишнее, хотя это подчеркивает важность механизмов синхронизации именно в задачах РВ. И опять таки я хотел очертить некий круг тербований и избыточность, на мой взгляд, здесь не страшна. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Это нужно для планировщика задач вполне определенного типа. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Так, тут я Вас не понимаю. Если мы рассматриваем round robin то смотри пункт первый. Если мы говорим о современных ОСРВ то защита от инверсии приоритетов обязательна. Конечно механизм защиты является частью планировщика, но ведь планировщик - часть системы, следовательно требования к планировщику суть требования к системе. Или, повторюсь, я Вас не понял? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ну и по последнему пункту. Неохота переносить. Что такое латентность памяти, я тоже не совсем того... Разве что по аналогии. А насчет драйверов, то тут как посмотреть, особенно для систем, в которых они на уровне ядра... Обращаю Ваше внимание, латентности не только должны быть известны, но и предсказуемы (по времени, раз это не очевидно). Я полностью согласен со всеми вашими рассуждениями о способах вычисления максимума времени выполнения, но без соблюдения обсуждаемого условия, эти вычисления вообще становятся сомнительными?! Тогда о чем мы спорим? Да и обратите внимание в определении речь идет о требованиях к службам ОС, а не к пользовательскому приложению. И там нет ни слова о каких-либо цифрах, речь идет о предсказуемости, или нет? Соответственно эти требования не только выполнимы, но и выполняются на практике. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Да можно и не отталкиваться. Хотя, видите самому Olej-гу понравилось, хоть он и перечислял. А с определением, это конечно дело вкуса... С Уважением и наилучшими пожеланиями. Егор Горошко |
||
Draggan
Kharkov, QNX Seminars |
||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||
Вопросы действительно "детские". Первое: Если хотите получить на них ответы заказывайте тестирование зе деньги и получите полный отчет, а если Вы просто интересуетесь, получите общую информацию. Мне кажется это разумная политика фирмы много лет занимающейся тестированием программного обеспечения за деньги. По моему об этом уже говорилось но замечу еще раз: для такой фирмы убийственна всякая пристрастность. Какой тогда смысл покупать ее анализы? Второе: А чьим тогда вообще тестам можно в принципе доверять? Исследованию, проведеному отдельным человеком я бы не доверял. Такая работа может быть только коллективной. Третье: Исходники тестов Вам забесплатно не дадут никогда, и еще вопрос дадут ли за деньги. Это ведь коммерческий продукт, не забывайте. Да и вообще, уверен, что ДС предоставляют убедительные доказательства своих тестов. ДЛЯ ПОТЕНЦИАЛЬНЫХ ПОКУПАТЕЛЕЙ. Обратитесь к ним если этот вопрос вас реально интересует, не думаю, что они Вам не ответят, за столько лет система должна быть отработанной. Да и по ссылочке прошел, посмотрел. Кстати, не бойтесь спама. Я на ДС зарегистрировался давно И вы знаете, таки да, нет спама. :) Хоть и "for free". Черт его знает почему. Может по тому, что фирме уже достаточно много лет? Точно не знаю и Вам не скажу. В общем не нашел я внятного мнения, почему нельзя им доверять. Хотя ОБОСНОВАННОЕ мнение хотел бы услышать. Например, что другое независимое исследование показало результаты, серьезно отличающиеся от их. Или, что такие-то и такие-то их клиенты заявили о неправильсти оценок ДС. Или фирма производиль ОС оспорила результаты сравнительного анализа (например параметры не ОС не соответствуют полученым самими производителями.) Пока такого на истории ДС небыло. Хотя в своих оценках за всю свою историю они задевали разные фирмы. Вы бы не ругались а посмотрели архив их обзоров, особенно на теденции изменения оценок, насколько они соответствуют изменениям в самих тестируемых системах. Очень интерестно и полезно, хотя бы для общего развития. Да и мне не понятно, если у Ваших колег скромные успехи в QNX, то чем виновато QNX? Может у кого-то скромные успехи в OS/2 - разве это о чем-то говорит? |
||
Draggan
Kharkov, QNX Seminars |
||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||
Да еще хотел дополнить предыдущее сообщение для evgen. Нашел отчеты ДС сделанные еще в 1993 году. Не так это давно было но однодневкой, вы уж извините, их назвать нельзя.
|
||
Draggan
Kharkov, QNX Seminars |
||
Профили участников
Послать частное письмо
Поиск публикаций участников
Посетить домашнюю страницу участника
Добавить в список приятелей
Действительный член Присоединился: 27 Март 2003 Категория: Russian Federation Online Status: Offline Публикации: 240 |
||
To: Draggan >По поводу времени. Дабы уточнить. :) Предсказуемость в процитированном мной >определении идет >соответсвующее >>>>>>>>>>>>>>>>>>>>>>>>>> Главное что бы было понятно о чем идет речь. Если хотите - используйте термин предсказуемость в смысле «временнАя предсказуемость». Мне больше нравится "дететрминированность". >>>>>>>>>>>>>>>>>>>>>>>>>>>> Если Вы посмотрите какие нибудь общемировые конференции по этой теме, то увидите, что там до сих пор время от времени до хрипоты спорят как раз о том что такое «реальное время». >А насчет простого определения для сложного понятия... по моему это тоже важно. Есть >развернутое >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Вобщем то я наверное повторяюсь, но что бы показать, что это определение не точное попытаюсь пойти от противного. Раз мы определяем что такое система реального времени (СРВ), это означает что есть и другие системы (назовем их условно «системами нереального времени» (СНРВ)). Раз СРВ предсказуемо реагирует на непредсказуемые события, то СНРВ наверное реагирует непредсказуемо (опять же в смысле «временнОй непредсказуемости»). Поэтому для того что бы отличить СРВ от СНРВ нам нужно понять чем предсказуемая реакция отличается от непредсказуемой реакции. То есть возникает вопрос метрики (количественной оценки предсказуемости). Понятно что в общем случае время события описывается неким вероятностным распределением, но предположим что наша предсказуемость вырождена в дельта-функцию и скажем одна система реагирует через 1мсек после внешнего события, а вторая ровно через 10сек. Какая из этих систем является СРВ? Если вторую систему применить для управления климатом в теплице, будет она работать в реальном времени? Скорее всего будет. А если ее же применить для управления прокатным станом, будет она СРВ? Нет не будет (за это время клети 100 раз успеют разлететься на куски). То есть система управления, АБСОЛЮТНО предсказуемо (ровно через 10 секунд) реагирующая на внешнее событие, не является СРВ. Другими словами система управления может быть отнесена к СРВ на основе метрик ее предсказуемости, но при этом абсолютные значения метрик системы управления имеют смысл только в контексте значений метрик самого управляемого процесса. То есть система управления является СРВ если ее метрики предсказуемости адекватны скорости протекания управляемых технологических процессов (временнЫм метрикам техпроцесса).
>>>>>>>>>>>>>>>>>>>>>>>>>> А если, предположим, меня с точки зрения функциональных характеристик редактора вполне устраивает то время которое мне придется подождать? Тогда для меня буква будет печататься ВСЕГДА вовремя. То есть понятие СРВ имеет смысл только когда определено что такое ВОВРЕМЯ. В любимом Вами кратком определении об этом нет ни слова.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Я просто хотел подчеркнуть, что РВ в СРВ и РВ в ОСРВ имеют разный смысл. Система управления может функционировать в реальном времени без применения ОСРВ, без применения ОС вообще и даже без применения программируемых устройств как таковых. Свое понимание термина ОСРВ я уже в форуме приводил.
>ОСРВ эту проблему успешно >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>. Это полезная функция, однако оформив все необходимые алгоритмы в виде одной задачи или используя серверы глобальных ресурсов вместо семафоров, я вполне могу использовать ОС, где эта проблема не решена (проблема просто не возникает). То есть это условие не является обязательным условием мешающим применять ту или иную ОС в СУпрРВ. >Второе. Ведь о предсказуемости здесь идет речь в контексте ОСРВ! Так и давайте не >говорить об однозадачных >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>. Технологический процесс не знает сколько задач в ОСРВ им управляют и применяется ли в системе управления ОСРВ вообще. То есть рассуждения о предсказуемости в СУпрРВ никак не определяются тем, применяется в системе управления ОСРВ или нет. Нужно так же отметить что значимые для техпроцесса реакции системы управления на внешние события сами по себе так же являются внешними событиями (управляющие воздействия и т.п.).
>приоритета этого много, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Я не призываю разработчиков ОСРВ закладывать а их ОС только 3 приоритета. Я просто советую прикладным программистам не увлекаться большим количеством приоритетов. Это может создать проблемы, особенно когда в одном проекте задействовано несколько программистов.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Без критериев как намекал Olej (то есть без метрик) можно сказать что никаких требований и нет. Мне в свое время понравился мультик где несколько зверушек спорили о том сколько кокосовых орехов можно назвать кучей (см начало письма). Сергей Сорокин
|
||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||
По поводу колличества приоритетов. В принципе я согласен и с Olej и с Сергеем Сорокиным в том, что в прикладных приложениях надо придерживаться минимума приоритетов.
НО! Почему разработчики ОСРВ стремятся к такому колличеству уровней приоритетов? Ведь в QNX их еще совсем не много. Что по этому вопросу пишут на западе: Наилучшим способом управления потоками является deadline-driving, т.е. зависящий от критичного времени выполнения каждого из запросов. На сегодняшний день приоритетная многозадачность с вытеснением является наилучшей схемой, реализованной в комерческих ОСРВ Однако эта схема порождает вопрос: как мы можем знать, что система будет предсказуемо реагировать в любой ситуации? В 1971 году Liy и Layland предложили ответ на этот вопрос. Ими был разработан математический аппарат, называемый Rate Monotonic Scheduling (RMS). Этот математический аппарат позволяет формально описать условия для предсказуемой (детерминированной) системы. Теория эта применяется только для фиксированных приоритетов, хотя динамические приоритеты могли бы дать лучшие результаты, на сегодняшний день отсутствует математический аппарат для их описания. При использовании RMS необходимо устанавливать свой уровень приоритета для каждого РВ потока. Соответственно необходимо большое число уровней приоритетов. В связи с этим рекомендованным для ОСРВ колличеством уровней приоритетов является 128 доступных фиксированных уровней. Большая просьба, прокоментировать вот этот вопрос. |
||
Draggan
Kharkov, QNX Seminars |
||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||
To: Сергей Сорокин
Спасибо за подробный ответ. По поводу определения вынужден с Вами согласиться, но только в том, что оно слишком обшее :) хотя мне в нем нравиться, то что оно подчеркивает самую суть СРВ, и там собственно не хватает только чего то вроде "детерминированно ВОВРЕМЯ реагирует", может автор это и подразумевал, когда говорил predictable. По поводу споров тоже согласен. Спорят. Оно и правильно. И конечно прав Olej - необходимы критерии, по тому как одного функционального набора маловато и он очень спорный. Как Вы справедливо заметили ту же проблему инверсии можно решить совершенно другим способом. Хотя у меня есть вопрос, а надо ли? В чем может быть преимущество систем не решающих эту проблему для задач СРВ? Только давайте не рассматривать доступность, которая определяет применение ДОСа. Эта система тоже в свое время относилась к ОСРВ, но ведь технологии ушли вперед достаточно далеко, так давайте и обсуждать современное состояние проблемы. К тому же меня удивил Ваш переход от обсуждения минимального функционально состава ОСРВ к требованиям к СУпрРВ. Как Вы сами справедливо заметили, это совершенно разные вещи. И требования к ним разные. По поводу приоритетов полностью согласен, хотя интерестно, что Вы думаете по поводу RMS (см. мое предыдущее сообщение). А по поводу критериев. Я уже говорил, что я согласен. С другой стороны выработать критерии без функциональных требований тоже та еще задача. Можно в конце концов оказаться в замкнутом круге. Нет критериев - нет функциональности, нет функциональности - нет критериев. Мне кажется тут нужен комплексный подход. Нужно и то и другое. |
||
Draggan
Kharkov, QNX Seminars |
||
Новичок Присоединился: 05 Ноябрь 2003 Online Status: Offline Публикации: 4 |
||
Теорию RMS у нас мало кто знает не говоря уже о том, чтобы использовать. На русском языке практически нет инфы о ней, только вот в книжке http://www.abook.ru/browse.php?cmd=describe&id=2690 одна глава посвящена этому вопросу (если кто знает еще какой источник - поделитесь!). RMS предписывает выставлять каждому потоку свой приоритет. Вроде бы это означает, что RTOS следует иметь много уровней приоритетов. Но я сомневаюсь, что в реальности существуют системы с одной стороны достаточно простые, для того чтобы к ним была применима теория RMS, а с другой стороны достаточно сложные, для того чтобы скажем 64 уровней приоритетов им не хватило. |
||
Ответить | Страница <1 2324252627 36> |
Переход на форум | Права доступа на форуме Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |