реал тайм осы

Первоначально опубликовано Draggan Первоначально опубликовано evgen Вот самые наивные, "детские" вопросы: Вопросы действительно "детские". Первое: Если хотите получить на них ответы заказывайте тестирование зе деньги и получите полный отчет, а если Вы просто интересуетесь, получите общую информацию.

Я высказал свое личное мнение. Ни на один из "детских" вопросов я ответа не получил. По моему скромному мнению - если уж ребята взялись все тестировать и не указывают на какой машине и с какими параметрами, то разговаривать дальше не о чем. Если мне будет дана на рецензию научная статья или диссертация с аналогичным содержанием, то отзыв будет точно таким же, независимо от того, сколько лет человек знаком редактору или насколько он дорог диссертационному совету. Разве что из уважения к сединам - не упомяну про неспособность справится с HDD.

Первоначально опубликовано Sergey Sorokin Вобщем то я наверное повторяюсь, но что бы показать, что это определение не точное попытаюсь пойти от противного. Раз мы определяем что такое система реального времени (СРВ), это означает что есть и другие системы (назовем их условно «системами нереального времени» (СНРВ)). Раз СРВ предсказуемо реагирует на непредсказуемые события, то СНРВ наверное реагирует непредсказуемо (опять же в смысле «временнОй непредсказуемости»). Поэтому для того что бы отличить СРВ от СНРВ нам нужно понять чем предсказуемая реакция отличается от непредсказуемой реакции. То есть возникает вопрос метрики (количественной оценки предсказуемости).

Вопрос не только в метрике (т.е. количественном различии), может более того отличаться и качественный характер процесса (СРВ - СНРВ).

Уж тогда позвольте мне отвлечь вас надолго, но мне, для этого предмета, необходимо скопировать сюда часть, из накопившихся набросков... а это многовато.

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

Но ИП - это потребительское качество (точнее антикачество), которое видит потребитель, а за счёт каких внутренних (различных) механизмов оно возникло - ему всё-равно...

Инверсия приоритетов – это ситуация, в которой, в результате взаимных синхронизаций, управление получает не та ветвь исполнения, которая должна была бы получить из соображений приоритетности, а другая, с более низким приоритетом.

Для определённости рассматриваем только одну из возможностей:

Положим, в системе присутствуют 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, вплоть до вечности, если бы ей заблагорассудилось зациклиться. И это - всё в воле простейшей вычислительной задачи, которая и не занает то ничего об диспетчировании, синхронизациях и т.д.

Тут уже определённо не до вероятностных распределений, см.ниже.

Первоначально опубликовано Sergey Sorokin Понятно что в общем случае время события описывается неким вероятностным распределением, но предположим что наша предсказуемость вырождена в дельта-функцию и скажем одна система реагирует через 1мсек после внешнего события, а вторая ровно через 10сек. Какая из этих систем является СРВ? Если вторую систему применить для управления климатом в теплице, будет она работать в реальном времени? Скорее всего будет. А если ее же применить для управления прокатным станом, будет она СРВ? Нет не будет (за это время клети 100 раз успеют разлететься на куски). То есть система управления, АБСОЛЮТНО предсказуемо (ровно через 10 секунд) реагирующая на внешнее событие, не является СРВ. Другими словами система управления может быть отнесена к СРВ на основе метрик ее предсказуемости, но при этом абсолютные значения метрик системы управления имеют смысл только в контексте значений метрик самого управляемого процесса. То есть система управления является СРВ если ее метрики предсказуемости адекватны скорости протекания управляемых технологических процессов (временнЫм метрикам техпроцесса).

А вот здесь я с вами никак не могу согласиться.
... система управления, АБСОЛЮТНО предсказуемо (ровно через 10 секунд) реагирующая на внешнее событие, является СРВ. Эта система по своим показателям производительности является абсолютно неадекватной метрикам объекта управления - да. Но она является так же
абсолютно прогнозируемой и в качественном характере и во временных реакциях, я есть во всех смыслах СРВ. Но - не для этого объекта управления.

Первоначально опубликовано Sergey Sorokin Это полезная функция, однако оформив все необходимые алгоритмы в виде одной задачи или используя серверы глобальных ресурсов вместо семафоров, я вполне могу использовать ОС, где эта проблема не решена (проблема просто не возникает). То есть это условие не является обязательным условием мешающим применять ту или иную ОС в СУпрРВ.

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

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

Первоначально опубликовано Sergey Sorokin Я не призываю разработчиков ОСРВ закладывать а их ОС только 3 приоритета. Я просто советую прикладным программистам не увлекаться большим количеством приоритетов. Это может создать проблемы, особенно когда в одном проекте задействовано несколько программистов.

В дополнение к тому же... Обратите внимание.

1. всё та же досадная инверсия приоритетов - никогда не возникнет в однопприоритетной системе ("нет приоритетов - нет проблемы";-)). Т.е. - чем больше задействовано приоритетных уровней в программной системе - тем больше у вас вероятность нарваться на эти или подобные грабли...

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

Первоначально опубликовано Olej - T3 - критическая реакция на перегрев этого парового котла. Для повышения динамики этой задачи, она использует собственный alocator памяти для многих промежуточных структур данных в большой, предварительно резервированной буферной области. Естественно (время критично!): размещать то он размещает, а вот удаления и уборки памяти в буферной области он не делает, не до того.

...Нет слов (c) Computer World о сертификации NT для работы на атомных станциях

Первоначально опубликовано Olej 2. возникновение инверсии приоритетов первоначально и было изучено в среде клиент-серверных OS, и там же наиболее активно обсуждается... так что и там есть те же проблемы. Только инверсия у них возникает на других механизмах (см. выше). Но от этого она менее инверсией не становится. В дополнение к тому же... Обратите внимание. [...] 2. в RTOS, тех из них, которые устраняют возникновение инверсии (по крайней мере для большинства ситуаций) - делается это обеспечением наследования приоритетов. Т.е. каждая ветвь имеет 2 приоритета: статический (который ей предписал проектант), и динамический (который ей был изменён в результате наследования). Так вот ещё, смотрите: при большом числе приоритетов и их тонком взаимодействии, вы, как проектант, твёрдо уверены в заданной вами "раскладке" приоритетов, которая и обеспечивает предопределённое вами поведение. Но, в динамика, приоритеты "шевелятся" в результате наследования: вверх - вниз... Т.е. раскладка, на которую вы уповаете - не соответствует действительно наблюдающейся, и при большом уровне эффекты, вызываемые сдвигами приоритетов, становятся комбинаторными, и прогнозировать их многообразие становится невозможным.

Вы таки разберитесь со своими же требованиями к риалтайм осам - или таки фиксированнрые приоритеты и грамотное проектирование или динамические приоритеты и менее грамотное проектирование.

Вот ведь как получается: за что боролись, на то и напоролись ? А разработчики GOS - все равно дураки - делают динамические приоритеты и не заморачиваются с давно решеными проблемами.

To: evgen
Вы таки будете мне рассказывать про научные исследования. :)
Все правильно, я полностью согласен, обязаны и даже это делают :)
Только не для ВАС. А для заказчиков. А ВЫ - ПРОСТО ЛЮБОПЫТСТВУЮЩИЙ. А ДС не компьютерный журнал, они свои отчеты ПРОДАЮТ.
Вы таки меня удивляете. Вы хотите на шару получить то, за что другие платят деньги, но недовольны что, то что вам дают не полное, а частичное.
"Жадность губит флибустьера"(с)

evgen
Вы таки разберитесь со своими же требованиями к риалтайм осам - или таки фиксированнрые приоритеты и грамотное проектирование или динамические приоритеты и менее грамотное проектирование.

Вот ведь как получается: за что боролись, на то и напоролись ? А разработчики GOS - все равно дураки - делают динамические приоритеты и не заморачиваются с давно решеными проблемами.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Чет Вы кудато не туда... Требование о жестких приоритетах обусловлено использованием RMS. А из теории следует, что применение динамических приоритетов более предпочтительно. И потом, почему при динамических приоритетах менее грамотное проектирование?! Грамотность от этого не зависит, она зависит от проектировщика!
И почему разработчики GOS - дураки. Кстати не во всех GOS приоритеты динамические.
К вашему сведению не все ОСРВ имеют только фиксированные приоритеты, тот же QNX например.
А как с этим обстоит в OS/2? Я как-то не помню, да глянуть негде, а Вы вроде должны знать. Напишите, любопытно.