OSDev

Добрый день всем. Вопрос у меня скорее академический и может даже лучше тему в Разное запихать.
Сидел читал Reference manual на ядро Cortex-M4. В разделе Instruction set для каждой инструкции дается время выполнения. Все инструкции ветвления снабжены таким комментарием, что время исполнения зависит от времени перезагрузки конвейера, которое как я понял предсказать невозможно.Т
ак вот я и подумал, ведь конвейеры есть сейчас даже в мелких 8 разрядных пиках. То есть создание систем жесткого реального времени невозможно на современных процах? Только ПЛИС?

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

Ну и второй вопрос: а что значит "жёсткого реального времени"? На самом деле это не "точность до такта", а 100% гарантия, что за строго заданное время некое событие будет передано на обработку или ещё что в этом роде. Если, например, считать критерием время от появления запроса прерывания на некоторой линии до начала выполнения первой команды обработчика этого прерывания, то сделать систему жёсткого реального времени для большинства архитектур особой проблемы не представляет (вот на ПК это невозможно в силу извращённой архитектуры самого компьютера, хотя на процессоре архитектуры IA-32 это возможно -- надо лишь соблюдать некоторые ограничения, и в первую очередь никогда не использовать SMM).

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

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

В Reference Manual по Cortex-M4 пишут

Где P - дополнительные такты на выполнение инструкции. Тут вклинивается предсказатель переходов как я понимаю. Но на него наверное будет влиять то, что проц еще и прерывания обрабатывает, которые непредсказуемы... т.е. время перезагрузки можно посчитать только если у нас поведение всей системы полностью детерминировано.

Вот это действительно вопрос. Да, я читал определения, которые даются системам жесткого и мягкого РВ. И не понимаю принципиальной разницы. То ли она только в ответственности (система ЖРВ если не вовремя отработает - будет авария, смерти, денежные потери и т.п., а мягкого РВ - просто дискомфорт, гнев заказчика и т.п.) либо в допусках на время срабатывания? Тут многие наверняка работают в области автоматики. У меня например в ТЗ прописывается время реакции на то или иное событие и плюс допуск, погрешность. срабатывания, например +-1%. Так вот, если например не уложимся в этjn 1%, то все, кранты... а если уложимся - живем спокойно. Тогда где эта граница? При каких допусках систему считать ЖРВ, а при каких она уже становится мягкого РВ?
И да, я понимаю, что нельзя рассматривать софт в изоляции от всего остального. но все-таки это одна из важнейших частей системы.

Всё просто если время реакции(t) системы на событие определяется определяется как:
1) t< const то это система мягкого времени.
2) t= const то это система жесткого времени.

Если у вас от 1 до 3 временных слотов задержки то это ОС мягкого времени.
А если у вас всегда за один временной слот, то ОС ЖРВ.

Что касается контролёров компьютеров и прочего. Не важно как устроен их конвейер и какие задержки они выполняют. Важно что эта непредсказуемость была меньше ошибки допуска заданной в ТЗ. Если меньше то ОС ЖРВ. Если больше, то ОС становится не ОС ЖРВ. А если добавить слот задержки, то станет ОС МРВ.
Правда при добавление слотов задержки время реакции системы изменится и скорее всего выйдет за заданный допуск. Но если в условие допуск взять в 2 раза больше, то ОС будет соответствовать ТЗ.

К примеру я оттестировал компьютер и он вёл себя довольно предсказуемо. Ошибка была не велики порядка нескольких мкс. Больших выбросов не было, самый большой выброс 10 мкс. Тестировал неделю. Соответственно можно создать ОС ЖРВ с точностью до 1 мс. Да даже при отборе комбинаций можно до 10 мкс довести.

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



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

Тогда получается, что любая ОС общего назначения на достаточно быстром железе может называться системой МРВ. В большинстве случаев она будет успевать все (как pavia написал компьютер с выбросом 10 мкс), но иногда будет "тормозить".
И я что-то не совсем понял, что вы имеете в виду под "временным слотом задержки"?

Да это я что-то перемудрил с ответом. Думаю в ОС МРВ задержка должна быть квантованный. Слот задержки это квант времени(промежуток времени) отведённый на ожидание другой задачи. Но увы в определение такого нет.


С большой натяжкой. Если сертифицировать систему, т.е. провести расчёты и подтвердить их тестами, то можно и назвать. Стоит сказать о термине система. Система это набор программ их совокупность. Т.е система реального времени должна быть спроектированы, так что-бы программы не влияли друг на друга.

Виндоус спроектирована не как система реального времени. А как система с растяжимым временем. Что это значит?Это значит что если у нас есть 3 задачи. А Б и С
"А" должна выполняться 0.5 секунд и "Б" 0.25 секунд. "С" должна выполняться 0.25 секунды раз в секунду.
При этом задача "А" зависит от данных задачи "Б"

От "Б" в "А" пришло много данных. И "А" не успевает отработать за 0.5. Она блокирует задачу "Б" до тех пор пока не обработает уже принятые данные. "Б" перестаёт реагировать.

Так вот при этом страдает и задача "С". ОС не будет отдавать ей управление пока не отработает активная задача. В нашем случае вначале "А" затем "Б".
Значит что для задачи "С" не гарантируется время реакции.
В мягкой системе реального времени задача "С" всегда должна гарантированно получать управление допустим раз в секунду. На самом деле Виндоус старается хотя бы раз в 1-10 секунд передать управление работающим задачам. А активные задачи забирают не всё время процессора.

Но так как в ОС МРВ не говорится о том какой должна быть реакция системы 10 с 1 с 10 мс или 10 мкс. То Для разных задач виндоус можно отнести как к ОС РВ, так и к ОС не РВ.

Так давайте ей поднимем приоритет (Windows вроде как позволяет) и пусть она работает. Тогда даже если A заблокирует Б и будет вовсю перемалывать данные, С, по идее, должна будет отрабатывать по таймеру каждую секунду.
Согласен, что надо рассматривать систему в целом. Т.е. даже если ОС предоставляет возможность работы в режиме ЖРВ, можно спроектировать все так, что время отклика будет вообще непредсказуемо.

Так и есть. Поэтому и Windows Embedded позиционируется как ОСРВ (МРВ, естественно), и на Линухе лепят вещи, требующие МРВ.

Спасибо за пояснения, что-то в мозгу начинает вырисовываться. Особенно помогло вот это:

Интересно еще вот что. Пусть у нас в системе протекают 2 процесса А и Б. Причем Б периодический (например по таймеру), а А - запускается каким-то внешним событием, момент возникновения которого предугадать нельзя. Следовательно, я так понимаю, нам надо решить, что для нас важнее и соответственно дать приоритеты этим процессам? Я к тому, что для для процесса с более низким приоритетом будет наблюдаться непредсказуемое колебание времени обработки, которое надо будет оценить и проверить на допустимость.