реал тайм осы |
Ответить | Страница <1 2425262728 36> |
Автор | ||||
Профили участников
Послать частное письмо
Поиск публикаций участников
Посетить домашнюю страницу участника
Добавить в список приятелей
Действительный член Присоединился: 08 Сентябрь 2003 Категория: Russian Federation Online Status: Offline Публикации: 178 |
Опубликовано: 24 Ноябрь 2003 12:40 |
|||
Я высказал свое личное мнение. Ни на один из "детских" вопросов я ответа не получил. По моему скромному мнению - если уж ребята взялись все тестировать и не указывают на какой машине и с какими параметрами, то разговаривать дальше не о чем. Если мне будет дана на рецензию научная статья или диссертация с аналогичным содержанием, то отзыв будет точно таким же, независимо от того, сколько лет человек знаком редактору или насколько он дорог диссертационному совету. Разве что из уважения к сединам - не упомяну про неспособность справится с HDD. |
||||
SY,
EK |
||||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||||
To: evgen
Знаете, довольно странная позиция. Ведь речь не идет о доказательствах достоверности тестов ДС. Не верите - не надо. Сознательно лишаете себя информации, априорно утверждая, что она не корректна, по тому что не полна. Правда с Вашим мнением не согласны заказчики их исследований, разработчики ОС, многие прикладные специалисты, но ведь это ничего не доказывает - да? Хотя о чем я? Все это я уже писал, а Вы похоже не обратили внимания. А как получить ответы на Ваши "детские" вопросы я уже писал. Если эти ответы Вас действительно интересуют. |
||||
Draggan
Kharkov, QNX Seminars |
||||
Действительный член Присоединился: 14 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 267 |
||||
Вопрос не только в метрике (т.е. количественном различии), может более того отличаться и качественный характер процесса (СРВ - СНРВ). Уж тогда позвольте мне отвлечь вас надолго, но мне, для этого предмета, необходимо скопировать сюда часть, из накопившихся набросков... а это многовато. Давайте вернёмся к той же пресловутой инверсии приоритетов. Она возникает в силу разных механизмов (что усложняет ситуацию), анализирующие её рассматривают на этих различных механизмах, и поэтому возникают даже разночтения в самом названии... вплоть до того, что считать, а что нет инверсией. Но ИП - это потребительское качество (точнее антикачество), которое видит потребитель, а за счёт каких внутренних (различных) механизмов оно возникло - ему всё-равно... Инверсия приоритетов – это ситуация, в которой, в результате взаимных синхронизаций, управление получает не та ветвь исполнения, которая должна была бы получить из соображений приоритетности, а другая, с более низким приоритетом. Для определённости рассматриваем только одну из возможностей: Положим, в системе присутствуют 3 потока управления: Т1, Т2, Т3, причём их приоритеты: T1 < T2 < T3. Положим, потоки активируются (стартуют или «пробуждаются» по некоторым событиям) во временной последовательности так: T1 - T2 - T3. Если теперь T1 - захватывает некоторый монопольный ресурс, который требуется так же и T3, и не успевает освободить его до активации Т2, то происходит: - T1 не выполняется, потому, что он вытеснен T2 (в виду приоритетности); - T3 не выполняется, потому, что ожидает ресурс, захваченный T1; - T2 - выполняется ... вплоть до бесконечно долго! Но T2, в описываемой ситуации – не является самым высокоприоритетным потоком, подлежащим немедленному исполнению! Всё, приехали, если T3 - реакция на citical mission событие, то оно не только не обработается в гарантированное время, но и вообще гарантировано не обработается. Ситуация возникновения инверсии приоритетов не только экстремальная (аварийная) с точки зрения последствий для функционирования системы, она ещё крайне тяжела для диагностики, локализации и отладки. Дело в том, что факт возникновения или не возникновения инверсии зависит от взаимной временной расстановки точек активизации Т1, Т2, Т3. Стоит Т2 стартовать «чуть попозже», когда Т1 уже освободит захваченный ресурс – и приложение благополучно проходит эту точку. Стоит Т2 стартовать «чуть раньше», когда Т1 ещё не захватил ресурс – и тот же результат (но с совершенно другой расстановкой последовательности прохождения потоками критического участка!). В результате, при тестировании реального приложения, инверсия приоритетов может фиксироваться в 1-м случае из 1 миллиона тестовых прогонов, … или из 1 миллиарда. Это та ситуация, которая способствует тому, что даже проявившись, случай с инверсией приоритетов будет списан на артефакты («грязная посуда») и даже не будет зафиксирован в протоколах тестирования… Со всеми вытекающими последствиями. Иногда, такую ситуацию с потоками Т1, Т2, Т3 – относят к «неправильно спроектированной архитектуре приложения», но такой подход – это желание отмахнуться от проблемы, а не разрешить её. Посмотрим на ту же ситуацию (то же приложение), но с потребительской точки зрения, как на изделие: Ситуация: проектируется СУ каким-нибудь... паровым катком (с потенциально взрывоопасными наклонностями). При этом программная система строится из 2-х потоков/процессов: - T3 - критическая реакция на перегрев этого парового котла. Для повышения динамики этой задачи, она использует собственный alocator памяти для многих промежуточных структур данных в большой, предварительно резервированной буферной области. Естественно (время критично!): размещать то он размещает, а вот удаления и уборки памяти в буферной области он не делает, не до того. Выполняется этот поток на критически высоком приоритете 60 (используются численные значения из OS QNX, где приоритет потока может быть 1…63). - T1 - программа (поток, процесс, задача) сборки мусора в буферной области и удаление размещённых Т3 структур данных – «сборка мусора». Этот поток может работать по принципу: «когда нечем боьше заняться», далеко на заднем плане – поэтому запускается этот поток с приоритетом 5. Естественно, на очень короткий интервал времени Т1 обязан монопольно блокировать структуру буфера, во избежание её вообще разрушения. Ничего особенно крамольного. Нормально спроектированное приложение, проектировщики добротно поработали… Даже если блокирование буфера Т1 приходится точно на редко возникающее событие активации Т3, то ничего критического не может произойти: интервал времени, в течении которого Т3 полностью «перекраивает» структуру буфера – на несколько порядков меньше критического времени срабатывания Т3, Т3 выжидает эту «досадную» блокировку, и добросовестно выполняет свою работу. Всё осмыслено и оттестировано миллион раз. Изделие передаётся в опытную эксплуатацию… Начальник стенда опытной эксплуатации … тоже «не пальцем деланный» - он, попутно со соими обязанностями, написал на каком-то BASIC расчётную программу… просчёта будущей неимоверной экономической эффективности предстоящего серийного выпуска изделия. И гоняет её тоскливыми ночами на стенде. А у него там вычисляется константа PI с 135-ю значащими цифрами: ну, считает он экономические эффекты «вкруговую» ;-), и твёрдо убеждён, что излишняя точность никому ещё не навредила… какой спрос с человека, пишущего на BASIC. То, что он гоняет свои расчёты с консоли работающей установки его, естественно, нисколько не смущает: во-первых, от разработчиков он слышал о приоритете 60 для критической ветви; во-вторых, он проделывает это уже в 1000-ную ночь на протяжении 12-ти часов еженощно… Естественно также, что его задача T2 запускается под приоритетом by default 10 (хотя бы потому, что про команду nice ему просто не от кого было слышать). Но в 1001-ю ночь (почти Шахеризада) ему не везёт - запуск на выполнение Т2 приходится на тот 1мсек интервал, когда Т1 блокирует memory allocator для Т3… T1 – заблокирована вычислением PI, и тут возникает критический перегрев, задача T3 пытается активироваться… но не тут-то было. И на вычислении 72-го знака в записи константы PI наш паровой каток взлетает в воздух вместе с незадачливым расчётчиком! Вот это всё, что произошло в системе СНРВ (возвращаемся к вашей терминологии), и чего могло бы не произойти в системе СРВ (а могло бы и произойти). Как вы видите - различия качественные: - не СНРВ система, допустив ИП, позволила реакции замедлиться не "долго или не очень" (в 2, 3, 5... раз), а (принципиально важно!) на столько, сколько было угодно внешней задаче Т2, вплоть до вечности, если бы ей заблагорассудилось зациклиться. И это - всё в воле простейшей вычислительной задачи, которая и не занает то ничего об диспетчировании, синхронизациях и т.д. Тут уже определённо не до вероятностных распределений, см.ниже.
А вот здесь я с вами никак не могу согласиться. ... система управления, АБСОЛЮТНО предсказуемо (ровно через 10 секунд) реагирующая на внешнее событие, является СРВ. Эта система по своим показателям производительности является абсолютно неадекватной метрикам объекта управления - да. Но она является так же абсолютно прогнозируемой и в качественном характере и во временных реакциях, я есть во всех смыслах СРВ. Но - не для этого объекта управления.
1. алгоритм управления, оформленный в виде единой задачи - в принципе не может обслуживать ассинхронный поток событий, поэтому к ней вообще неприменима терминология и проблемы СРВ (обработчики прерываний - не в счёт, т.к. при этом разрушается критерий однозадачности, обработчики - эту уже параллельные ветки, и все проблемы начинаются сначала). 2. возникновение инверсии приоритетов первоначально и было изучено в среде клиент-серверных OS, и там же наиболее активно обсуждается... так что и там есть те же проблемы. Только инверсия у них возникает на других механизмах (см. выше). Но от этого она менее инверсией не становится.
В дополнение к тому же... Обратите внимание. 1. всё та же досадная инверсия приоритетов - никогда не возникнет в однопприоритетной системе ("нет приоритетов - нет проблемы";-)). Т.е. - чем больше задействовано приоритетных уровней в программной системе - тем больше у вас вероятность нарваться на эти или подобные грабли... 2. в RTOS, тех из них, которые устраняют возникновение инверсии (по крайней мере для большинства ситуаций) - делается это обеспечением наследования приоритетов. Т.е. каждая ветвь имеет 2 приоритета: статический (который ей предписал проектант), и динамический (который ей был изменён в результате наследования). Так вот ещё, смотрите: при большом числе приоритетов и их тонком взаимодействии, вы, как проектант, твёрдо уверены в заданной вами "раскладке" приоритетов, которая и обеспечивает предопределённое вами поведение. Но, в динамика, приоритеты "шевелятся" в результате наследования: вверх - вниз... Т.е. раскладка, на которую вы уповаете - не соответствует действительно наблюдающейся, и при большом уровне эффекты, вызываемые сдвигами приоритетов, становятся комбинаторными, и прогнозировать их многообразие становится невозможным. |
||||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||||
По поводу критериев. Зачем вообще все это нужно?
Лично мне нужно вот что: На основе каких критериев, соображений, функциональных особенностей и характеристик выбрать ОС для решения конкретной РВ задачи и построения конкретной СРВ? Любая ОС имеет недостатки и достоинства, в том числе и QNX. Ну например: цена, QNX - дорогая комерческая система, комплект разработчика стоит солидные деньги, и хоть при серии хотя бы в 200 экземпляров конечного изделия затраты на лицензионное ПО оказываются меньше чем при исп. Винды, включая и комплект разработчика, заказчику это объяснить зачастую оказывается трудно. Второе. QNX как ОС построенная по технологии клиент-сервер нуждается в защиет памяти своих сервисов-серверов. Соответственно время переключения контекстов у нее будет больше чем у системы общего назначения. Это плата за надежность и предсказуемость, но о ней надо помнить. Каких соображений я могу исходить при выборе ОС для своей СРВ, и поможет ли мне в этом тот функциональный набор, о котором я уже писал? Какие характеристики обекта управления или анализа мне нужны? Для выбора ОС мне нужно знать, достаточно ли мне однопоточной модели, или нет. Если нет, то какие это должны быть потоки: жесткого реального времени, мягко РВ, не РВ? Если все три, то сколько должно быть потоков ЖРВ дабы используя RMS (предположим, я его использую) дабы определиться сколько мне нужно уровней приоритетов. Далее каковы критичные времена реакции моего объекта, дабы определить какие, латентности мне нужны от искомой ОС. Так, где я не прав, и что я забыл? Да, и я должен сразу исключить из рассмотрения те ОС, в которых: - не решена проблема инверсии, - не поддерживаются механизмы многопоточности и нет вытесняющей приоритетной многозадачности (или я не прав и тогда при каких условиях я могу довольствоваться меньшим) - латентность плохо предсказуема(!?) |
||||
Draggan
Kharkov, QNX Seminars |
||||
Профили участников
Послать частное письмо
Поиск публикаций участников
Посетить домашнюю страницу участника
Добавить в список приятелей
Действительный член Присоединился: 08 Сентябрь 2003 Категория: Russian Federation Online Status: Offline Публикации: 178 |
||||
...Нет слов (c) Computer World о сертификации NT для работы на атомных станциях
Вы таки разберитесь со своими же требованиями к риалтайм осам - или таки фиксированнрые приоритеты и грамотное проектирование или динамические приоритеты и менее грамотное проектирование. Вот ведь как получается: за что боролись, на то и напоролись ? А разработчики GOS - все равно дураки - делают динамические приоритеты и не заморачиваются с давно решеными проблемами. |
||||
SY,
EK |
||||
Профили участников
Послать частное письмо
Поиск публикаций участников
Посетить домашнюю страницу участника
Добавить в список приятелей
Действительный член Присоединился: 08 Сентябрь 2003 Категория: Russian Federation Online Status: Offline Публикации: 178 |
||||
Еще раз - с "верить" - это в церковь или синагогу. Сравнительное исследование разных ОС - это научное исследование...или вы считаете, что ненаучное ? В научных исследованиях есть многовековая традиция - в отчетах об исследованиях помещают описание экспериментов, экспериментальных установок и задаваемых параметров. Даже в самом распоганом сравнительном тестировании любых программ в любом компьютерном журнале указывается - на каком железе оно тестировалось. |
||||
SY,
EK |
||||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||||
To: evgen
Вы таки будете мне рассказывать про научные исследования. :) Все правильно, я полностью согласен, обязаны и даже это делают :) Только не для ВАС. А для заказчиков. А ВЫ - ПРОСТО ЛЮБОПЫТСТВУЮЩИЙ. А ДС не компьютерный журнал, они свои отчеты ПРОДАЮТ. Вы таки меня удивляете. Вы хотите на шару получить то, за что другие платят деньги, но недовольны что, то что вам дают не полное, а частичное. "Жадность губит флибустьера"(с) |
||||
Draggan
Kharkov, QNX Seminars |
||||
Действительный член Присоединился: 14 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 267 |
||||
С какими "своими" требованиями, папа... ?
Какие динамические приоритеты, динамические относительно к чему, какие давно решённые проблемы...? Акститесь! Вот вам свежие результаты прогона 3-х поточной задачи, практически той, что описана выше (0 - соответствует Т1, 1 - Т2, 2 - Т3), для разных классов OS выполнялись аналогичные задачи, вывод прямо с экрана (для evgen, как твёрдого убежденца, что результаты Athlon и Celeron будут принципиально отличаться, указан и тип процессора): win2k 4sp, CPU Athlon XP 2100: - без блокирования: inverse test, Win32 API, vers.1.03 repeating number = 50000000 210222222222111111111000000000 - с блокированием на мютексе: inverse test, Win32 API, vers.1.03 repeating number = 50000000, lock on mutex 101111111110000000002222222222 - классическая инвераия... самая приоритетная задача оттестнена в самый хвост... на сколь угодно длительное время! WinXP, CPU Athlon XP 1700 - без блокирования: inverse test, Win32 API, vers.1.03 repeating number = 50000000 210222222222111111111000000000 - с блокированием на мютексе: inverse test, Win32 API, vers.1.03 repeating number = 50000000, lock on mutex 101111111110000000002222222222 - то же самое... инверсия! RedHat Linux, kernal 2.4.18, Celeron 667 - без блокирования: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on mutex 222222222211111111110000000000 - с блокированием на мютексе: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on mutex 111111111100000000002222222222 - с блокированием на семафоре: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on semaphore 111111111100000000002222222222 - инверсия... Blin Linux, kernal 2.4.41, Celeron 533 - без блокирования: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on mutex 222222222211111111110000000000 - с блокированием на мютексе: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on mutex 111111111100000000002222222222 - с блокированием на семафоре: inverse test, Linux API, vers.1.05L repeating number = 1000000, lock on semaphore 111111111100000000002222222222 - инверсия... А вот вам RTOS QNX 6.2.1 MMX 233 (те же результаты - Celeron 533): - без блокирования: inverse test, QNX API, vers.1.04 repeating number = 100000, debug level = 0 222222222211111111110000000000 - с блокированием на мютексе (примитив ядра! в QNX): inverse test, QNX API, vers.1.04 repeating number = 100000, debug level = 0, lock on mutex 000000000012222222222111111111 - нет инверсии, устраняется динамическим наследованием приоритетов... "задерживающий" поток 0 пропускается вперёд, освобождая место высокоприоритетному потоку 2. - с блокированием на семафоре (семафор в QNX не является примитовом микроядра): inverse test, QNX API, vers.1.04 repeating number = 100000, debug level = 0, lock on semaphore 111111111100000000002222222222 - классическая инверсия... объект блокирования не принадлежит микроядру и инверсия им не отслеживается. Вот вам и разработчики GOS... |
||||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||||
evgen
Вы таки разберитесь со своими же требованиями к риалтайм осам - или таки фиксированнрые приоритеты и грамотное проектирование или динамические приоритеты и менее грамотное проектирование. Вот ведь как получается: за что боролись, на то и напоролись ? А разработчики GOS - все равно дураки - делают динамические приоритеты и не заморачиваются с давно решеными проблемами. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Чет Вы кудато не туда... Требование о жестких приоритетах обусловлено использованием RMS. А из теории следует, что применение динамических приоритетов более предпочтительно. И потом, почему при динамических приоритетах менее грамотное проектирование?! Грамотность от этого не зависит, она зависит от проектировщика! И почему разработчики GOS - дураки. Кстати не во всех GOS приоритеты динамические. К вашему сведению не все ОСРВ имеют только фиксированные приоритеты, тот же QNX например. А как с этим обстоит в OS/2? Я как-то не помню, да глянуть негде, а Вы вроде должны знать. Напишите, любопытно. |
||||
Draggan
Kharkov, QNX Seminars |
||||
Участник Присоединился: 31 Октябрь 2003 Категория: Ukraine Online Status: Offline Публикации: 52 |
||||
П поводу сообщения Olej
Кто нибудь в курсе других, кроме наследования приоритетов механизмов защиты от инверсии? Например Priority Ceiling Protocol? И еще, если кто интересуется RMS, то даю ссылку на оригинал: C.L. Liu and J.W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment,” J. ACM, Vol. 20, No. 1, Jan. 1973, pp. 46-61. В инете можно найти здесь, но нужно регистрироваться. http://portal.acm.org/citation.cfm?id=321743&coll=portal&dl=ACM&CFID=14410645&CFTOKEN=19035626 |
||||
Draggan
Kharkov, QNX Seminars |
||||
Ответить | Страница <1 2425262728 36> |
Переход на форум | Права доступа на форуме Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |