Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Архив
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

реал тайм осы

 Ответить Ответить Страница  <1 2425262728 36>
Автор
Сообщение
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: реал тайм осы
    Опубликовано: 24 Ноябрь 2003 12:40
Первоначально опубликовано Draggan

Первоначально опубликовано evgen


Вот самые наивные, "детские" вопросы:

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

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

SY,
EK
Наверх
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 13:23
To: evgen
Знаете, довольно странная позиция. Ведь речь не идет о доказательствах достоверности тестов ДС. Не верите - не надо. Сознательно лишаете себя информации, априорно утверждая, что она не корректна, по тому что не полна.
Правда с Вашим мнением не согласны заказчики их исследований, разработчики ОС, многие прикладные специалисты, но ведь это ничего не доказывает - да?
Хотя о чем я? Все это я уже писал, а Вы похоже не обратили внимания. А как получить ответы на Ваши "детские" вопросы я уже писал. Если эти ответы Вас действительно интересуют.
Draggan
Kharkov, QNX Seminars
Наверх
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 13:31
Первоначально опубликовано 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 приоритета: статический (который ей предписал проектант), и динамический (который ей был изменён в результате наследования). Так вот ещё, смотрите: при большом числе приоритетов и их тонком взаимодействии, вы, как проектант, твёрдо уверены в заданной вами "раскладке" приоритетов, которая и обеспечивает предопределённое вами поведение. Но, в динамика, приоритеты "шевелятся" в результате наследования: вверх - вниз... Т.е. раскладка, на которую вы уповаете - не соответствует действительно наблюдающейся, и при большом уровне эффекты, вызываемые сдвигами приоритетов, становятся комбинаторными, и прогнозировать их многообразие становится невозможным.
Наверх
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 15:17
По поводу критериев. Зачем вообще все это нужно?
Лично мне нужно вот что: На основе каких критериев, соображений, функциональных особенностей и характеристик выбрать ОС для решения конкретной РВ задачи и построения конкретной СРВ?
Любая ОС имеет недостатки и достоинства, в том числе и QNX. Ну например: цена, QNX - дорогая комерческая система, комплект разработчика стоит солидные деньги, и хоть при серии хотя бы в 200 экземпляров конечного изделия затраты на лицензионное ПО оказываются меньше чем при исп. Винды, включая и комплект разработчика, заказчику это объяснить зачастую оказывается трудно.
Второе. QNX как ОС построенная по технологии клиент-сервер нуждается в защиет памяти своих сервисов-серверов. Соответственно время переключения контекстов у нее будет больше чем у системы общего назначения. Это плата за надежность и предсказуемость, но о ней надо помнить.
Каких соображений я могу исходить при выборе ОС для своей СРВ, и поможет ли мне в этом тот функциональный набор, о котором я уже писал?
Какие характеристики обекта управления или анализа мне нужны?
Для выбора ОС мне нужно знать, достаточно ли мне однопоточной модели, или нет.
Если нет, то какие это должны быть потоки:
жесткого реального времени,
мягко РВ,
не РВ?
Если все три, то сколько должно быть потоков ЖРВ дабы используя RMS (предположим, я его использую) дабы определиться сколько мне нужно уровней приоритетов.
Далее каковы критичные времена реакции моего объекта, дабы определить какие, латентности мне нужны от искомой ОС.

Так, где я не прав, и что я забыл?

Да, и я должен сразу исключить из рассмотрения те ОС, в которых:
- не решена проблема инверсии,
- не поддерживаются механизмы многопоточности и нет вытесняющей приоритетной многозадачности (или я не прав
и тогда при каких условиях я могу довольствоваться меньшим)
- латентность плохо предсказуема(!?)
Draggan
Kharkov, QNX Seminars
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 15:18
Первоначально опубликовано Olej


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


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

Первоначально опубликовано Olej


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


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

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


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

Вот ведь как получается: за что боролись, на то и напоролись ? А разработчики GOS - все равно дураки - делают динамические приоритеты и не заморачиваются с давно решеными проблемами.
SY,
EK
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 15:29
Первоначально опубликовано Draggan

To: evgen
Знаете, довольно странная позиция. Ведь речь не идет о доказательствах достоверности тестов ДС. Не верите - не надо. Сознательно лишаете себя информации, априорно утверждая, что она не корректна, по тому что не полна.
Правда с Вашим мнением не согласны заказчики их исследований, разработчики ОС, многие прикладные специалисты, но ведь это ничего не доказывает - да?
Хотя о чем я? Все это я уже писал, а Вы похоже не обратили внимания. А как получить ответы на Ваши "детские" вопросы я уже писал. Если эти ответы Вас действительно интересуют.

Еще раз - с "верить" - это в церковь или синагогу. Сравнительное исследование разных ОС - это научное исследование...или вы считаете, что ненаучное ? В научных    исследованиях есть многовековая традиция - в отчетах об исследованиях помещают описание экспериментов, экспериментальных установок и задаваемых параметров. Даже в самом распоганом сравнительном тестировании любых программ в любом компьютерном журнале указывается - на каком железе оно тестировалось.
SY,
EK
Наверх
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 16:11
To: evgen
Вы таки будете мне рассказывать про научные исследования. :)
Все правильно, я полностью согласен, обязаны и даже это делают :)
Только не для ВАС. А для заказчиков. А ВЫ - ПРОСТО ЛЮБОПЫТСТВУЮЩИЙ. А ДС не компьютерный журнал, они свои отчеты ПРОДАЮТ.
Вы таки меня удивляете. Вы хотите на шару получить то, за что другие платят деньги, но недовольны что, то что вам дают не полное, а частичное.
"Жадность губит флибустьера"(с)
Draggan
Kharkov, QNX Seminars
Наверх
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 16:40
Первоначально опубликовано evgen


Вы таки разберитесь со своими же требованиями...

С какими "своими" требованиями, папа... ?

Первоначально опубликовано evgen


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

Какие динамические приоритеты, динамические относительно к чему, какие давно решённые проблемы...?
Акститесь!

Вот вам свежие результаты прогона 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...
Наверх
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 17:56
evgen
Вы таки разберитесь со своими же требованиями к риалтайм осам - или таки фиксированнрые приоритеты и грамотное проектирование или динамические приоритеты и менее грамотное проектирование.

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


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 24 Ноябрь 2003 21:25
П поводу сообщения 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>

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz