реал тайм осы

Первоначально опубликовано Sergey Sorokin В МЭК есть стандарты по функциональной безопасности (я, по моему, в форуме их номера приводил). Там эти вопросы рассмотрены с системной точки зрения.

Номера можно найти, но что с ними дальше делать ?
Это такой тонкий намек - что неплохо было бы собрать в кучу все стандарты, имеющие отношение к СТА, или на худой конец - прямые ссылки на них...Скажем, в разделе "ссылки"...

SY,
EK

Первоначально опубликовано Draggan Одним из механизмов защиты от такой ситуации является технология Priority Ceiling Protocol. В соответствии с ней объекту синхронизации (семафору или мютексу не важно) присваивается некий приоритет, соответствущий самому высокому приоритету из списка потоков, к нему собирающихся обратиться. И когда не самый высокоприоритеный поток блокирует этот объект синхронизации его приоритет системой поднимается до значения, соответствующего приоритету обекта управления. Таким образом, поток, захвативший ресурс не может быть прерван внутри critical section более приоритетным потоком, нуждающимся в этом ресурсе.

Здесь видится несколько проблем.

1) Подход работает только для систем со статической приоритизацией.

2) На этапе разработки нужно всем ресурсам присвоить ceiling число соответствующее максимальному приоритету из всех потоков, которые к этому ресурсу только СОБИРАЮТСЯ обращаться. Соответственно при скажем удалении из одного из потоков обращения к какому нибудь ресурсу (и при добавлении обращения) надо проверить не нужно ли изменить ceiling число этого ресурса. При изменении приоритета потока нужно просмотреть и при необходимости изменить ceiling числа всех ресурсов к каким этот поток может обратиться. При сложных проектах отслеживание такого рода зависимостей может превратиться в настоящую головную боль. Можно конечно предусмотреть динамическую регистрацию вновь запущенных потоков у "своих" ресурсов, но головная боль остается, так как сами ресурсы (семафоры) могут быть динамическими и в общем случае могут образовываться после потоков, которые будут ими пользоваться.

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

Что касается взаимных блокировок на ресурсах включая описанный вами вариант взаимоперекрестного вложенного доступа к ресурсам, то можно предложить некий способ, позволяющий в необходимых случаях  в принципе избегать таких блокировок. Я бы назвал его транзакционным. Способ этот связан конечно с некоторыми накладными расходами, но вобщем то это уже для тех кто пишет диссертации на эту тему или пишет свои операционные системы. В печати я обсуждений транзакционых методов захвата ресурсов не встречал.

Первоначально опубликовано Draggan Ими был разработан математический аппарат, называемый Rate Monotonic Scheduling (RMS). Этот математический аппарат позволяет формально описать условия для предсказуемой (детерминированной) системы. Теория эта применяется только для фиксированных приоритетов, хотя динамические приоритеты могли бы дать лучшие результаты, на сегодняшний день отсутствует математический аппарат для их описания. При использовании RMS необходимо устанавливать свой уровень приоритета для каждого РВ потока. Соответственно необходимо большое число уровней приоритетов. В связи с этим рекомендованным для ОСРВ колличеством уровней приоритетов является 128 доступных фиксированных уровней.

Пролистал я эту статью. Действительно RMS рассматривается для весьма ограниченного класса задач. Потоки периодичны, длительности времени выполнения каждого протока известны и постоянны. Я не увидел никаких преимуществ RMS по сравнению с динамической планировкой "earliest-deadline-first". Реальные процессы могут быть не только непериодическими, но и вообще не стационарными. Возможны ситуации когда запрашиваются ресурсы превышающие 100% имеющихся. В этом случае нужно оттеснять задачи "мягкого" реального времени. То есть я бы для планировщика EDF предусмотрел бы для каждого потока 2 дедлайна со значениями штрафа за просрочку каждого (для потока ЖРВ штраф уже за первый дедлайн должен быть бесконечным). Моменты планировки могли бы быть те же, что и в классической вытесняющей многозадачности. Если дедлайнов много, для их постоянного движения по внутренней "оси времени" можно использовать алгоритмы инкрементных таймеров. Для работы с потоками "мягкого" реального времени понадобится информация о длительностях исполнения этих "мягких" потоков (желательна связь с профилировщиком или "хитрым" компилятором).  И т.п. Но это все опять может быть интересно наверное только тому кто диссертации пишет, а таких сейчас мало. Важнее научиться правильно применять доступные коммерческие ОС.

С Уважением,

Сергей Сорокин

 

 

 

 

Первоначально опубликовано Sergey Sorokin Первоначально опубликовано Владимир Е. Зюбин 1. В стандартах я неплохо ориентируюсь, и еще раз Вам повторю стандарт на 500 стр. - это полная ахинея. Средний размер ГОСТа из состава ЕСПД примерно 1,5 (полторы) страницы формата А5. Я не вижу прямой связи между качеством стандарта и его объемом. Объем как правило определяется содержанием стандарта. Если документ описывает набор функций API (будь это стандарт Posix или "нестандарт" Win32) и число этих функций достигает нескольких тысяч, то документ физически не может быть маленьким. Описание Win32 - это то же несколько толстых книжек. Тем не менее, для того что бы пользоваться стандартом совсем не обязательно его весь изучать. К тому же довольно большая часть функций API операционных систем (даже в том же ДОС) сохраняется для обеспечения совместимости с предыдущими версиями ОС (и соответствующих стандартов), а на практике в новых разработках практически не используются.

Проблема fat-стандартов в том, что они непрактичны.
Людям нужно работать, а не изучать талмудистскую
литературу... Может из-за этого, в том же КНХ есть
проблемы с ПОЗИКС... (об этом косвенно говорится в
исследованиях дидикатед-системс)

Первоначально опубликовано Sergey Sorokin Первоначально опубликовано Владимир Е. Зюбин 1. Я Вам так скажу: не надо меня агитировать не применять диск-своппинг, я его не применяю, скажу больше, я даже ОЗУ не применяю, обхожусь кэшем первого уровня... Просто очевидно, что если есть диск-своппинг и он разрешен, то он будет использоваться и при трансляции и при работе... Согласитесь, что своппинговать гораздо лучше, чем вообще ничего не делать, зависнув от нехватки ресурсов... Я не знаю как организован свопинг в QNX. Но если предположить что у разработчиков QSSL с головой все в порядке, то не должно быть автоматического разрешения свопинга для всех приложений запущенных на каком либо узле. То есть, если при разработке приложения (желательно на уровне исходных текстов) свопинг не предусмотрен, то как бы на уровне ОС я этот свопинг не разрешал, он у меня для этого приложения работать не будет. С Уважением, Сергей Сорокин

С моей точки зрения, своппинг нужно разрешать...
если его не разрешить, а память требуется, то система
грохнется... В этом смысле неверно сводить проблему
к разрешению/неразрешению Д-С. Проблема гораздо шире -
это динамические операции с ОЗУ, и их влияние на
надежность... К слову, мы в своих системах динамические
операции с ОЗУ исключаем конструктивно...

Вот так. Как это не грустно слышать всем любителям
calloc, malloc, а равно, рекурсий и ООП.

Первоначально опубликовано Sergey Sorokin В данной трактовке эта часть определения действительно обретает смысл. Но ведь есть и другая часть определения "непредсказуемые внешние события". Раз "предсказуемо" - это ПРАВИЛЬНО и ВОВРЕМЯ, то непредсказуемо это что? 1) НЕПРАВИЛЬНО и НЕВОВРЕМЯ 2) ПРАВИЛЬНО но НЕВОВРЕМЯ 3) НЕПРАВИЛЬНО или НЕВОВРЕМЯ 4) ПРАВИЛЬНО но неизвестно когда и будет ли вообще 5) ПРАВИЛЬНО но не совсем точно известно когда и т.п. Не слишком ли много подразумеваний даже для специалистов? Не проще ли в ущерб может быть красивой игре слов, взять и раскрыть подразумеваемость. Тогда получится "Система реального времени - это система, ПРАВИЛЬНО и ВОВРЕМЯ реагирующая на внешние события." При этом остаются две подразумеваемости 1) Слово "событие" - уже в самом себе содержит возможность своей "случайности/непредсказуемости/недетерминированности_во_времени". В то же время это определение покрывает случаи когда внешние события, на которые должна реагировать система, - являются детерминированными. Для системы детерминированность естественно соотносится с разрешающей способностью системы по времени (скажем внешнее событие повторяющееся каждую секунду плюс/минус одна пикосекунда, будет для системы детерминированным так как система не может различать интервал в 1 пикосекунду) . 2) Подразумевается, что речь идет о событиях существенных для выполнения целевой функции системы, то есть о событиях для реагирования на которые ситема и создавалась. Но даже и в этом кратком определении есть логическая проблема, из-за которой я бы убрал из него слово "ПРАВИЛЬНО". То есть может быть ситуация, когда СРВ, то есть система управления чьи динамические свойства адекватны скорости протекания техпроцессов в управляемом объекте, будет управлять этим объектом НЕПРАВИЛЬНО. Зато определение получится еще короче. "Система реального времени - это система, ВОВРЕМЯ реагирующая на внешние события."   С Уважением, Сергей Сорокин

Соглсен. Убедили. По русски так наверно звучит лучьше :-)
Я, в общем, по здравому размышлению пришел к тем же выводам. Однако использовать эту идею все-же можно.
На мой взгляд наиболее точно идее реалтайма соответсвует комбинация из двух определений:
1. Ваше :-) из статьи Системы реального времени:
СРВ это системы в которых важна не только правильность вычислений и логических решений но и время их выполнения. (моя вольная трактовка :-))
2. Определение IEEE - что СРВ предназначены для контроля некоего внешнего процесса, при этом время выполнение операций и логических решений определяется временными характеристиками этого процесса.

То есть, самым важным для разработчика СРВ является задача не пропустить deadline. А предсказуемость всех элементов СРВ ( прикладных программ, ОСРВ, целевой системы) как раз и является тем необходимым свойством, которое позволяет разработчику быть уверенным в надежности и вообще работоспособности его системы.
То есть предсказуемость это необходимое свойство ОСРВ систем, отличающее их от систем общего назначения.
А уже свойство предсказуемости диктует функциональные требования к ОСРВ системе. При этом в принципе систма может быть и не многозадачной. Те же дедикейтед системз приводят архитектуру MS-DOS как пример построения ОСРВ лет десять назад (в исторической ретроспективе). Однако для современных ОСРВ систем многозадачность - есть естественное положение вещей. То есть при наличии многозадачности уж однозадачность реализовать не сложно. А вот в многозадачной/многопоточной системе реализовать свойство ПРЕДСКАЗУЕМОСТИ уже проблема и Вы совершенно справедливо это заметили здесь на форуме.
Из этих же требований исходит и специфика реализации объектов синхронизации в ОСРВ. Они не только должны быть в системе как таковые, но и их поведение должно быть соответствующим (скажем предсказуемые и высокие времена отработки своих функций).
Плюс к этому обязательная защита от инверсии приоритетов, вынесенная как отдельное требование.
Ну и конечно латенции во всех своих видах, от переключения потоков до обработки прерываний. Сюда также относятся не слишком важные для GPOS требования по стрес-тестам (например обработка двух прерываний первое с низким приоритетом, а второе с высоким, пришедших с небольшим временным разрывом в указанном порядке).
Так что именно предсказуемость (временная) поведения системы и является, в общем-то, основным критерием ОСРВ(!) системы. Если некая GPOS по критерию предсказуемости отвечает требованиям объекта то - прекрастно, она вполне может использоваться как ОСРВ.
Но, таже инверсия приоритетов может оказаться непреодолимым препятствием.

Первоначально опубликовано Владимир Е. Зюбин Проблема fat-стандартов в том, что они непрактичны. Людям нужно работать, а не изучать талмудистскую литературу... Может из-за этого, в том же КНХ есть проблемы с ПОЗИКС... (об этом косвенно говорится в исследованиях дидикатед-системс) ]

Ничего не могу сказать про проблемы КНХ, но мне трудно представить человека, который сразу начнет работать в области программирования ничего не изучая. Скажем начать программировать на С, не прочтя ни строчки из толстых книжек про то как это делать. Некоторые стандарты fat просто потому, что они не могут быть другими. Хотя возможно Вы знаете как описать несколько тысяч вызовов API ОС на 10 страницах. 

Первоначально опубликовано Владимир Е. Зюбин С моей точки зрения, своппинг нужно разрешать... если его не разрешить, а память требуется, то система грохнется... В этом смысле неверно сводить проблему к разрешению/неразрешению Д-С. Проблема гораздо шире - это динамические операции с ОЗУ, и их влияние на надежность... К слову, мы в своих системах динамические операции с ОЗУ исключаем конструктивно... Вот так. Как это не грустно слышать всем любителям calloc, malloc, а равно, рекурсий и ООП.

Я не очень понял в чем Вы видите проблему. Во многих приложениях память распредляется статически при запуске, а во время выполнения динамически вообще не аллокируется. Если же какой либо программе от системы динамически требуется память, а у системы памяти больше нет, то система возврашает этой программе в ответ на ее запрос кукиш с маслом. Что с этим кукишем делать - проблемы разработчика программы, не вижу здесь фатализма с точки зрения "грохания системы".

С Уважением,

Сергей Сорокин