Разгорелся очередной мини холивар по воду слова "реал тайм".

Я считаю, что это "детерминированное время отклика для каждого процесса в системе". Его можно посчитать.

Оппоненты, насколько я понял, это "непрерывное выполнение задач". Т.е. задача выполняется 10мс и будет выполнятся 10мс и ее никто не прервет.
Второе утверждение "задача будет выполнятся через определенные промежутки времени". Т.е сказали задаче выполнятся раз в секунду, она и будет выполнятся раз в секунду.

Сообщение отредактировал a9d - Feb 20 2012, 08:25

Да, вы правы.
Это и есть определение реалтайма.
Причем, не только посчитать, но и задать и гарантировать.
А насчет того, что "поцесс будет гарантированно выполняться 10мс", этого как раз гарантировать нельзя. Потому что многие системы имеют функции принудительного вызова диспетчера с целью ускорения реакции.
Например:

Отклика на что ? А если процесс отправил сообщение по сети и ждёт ответа - как предсказать (посчитать) время его "отклика" ?
Это весьма распространённое заблуждение, что механизм ОСРВ заложен, в основном, в планировщике, который обладает волшебным свойством "детерминированности отклика" ...
На самом деле, абсолютно все механизмы ОС должны быть перестроены таким образом, чтобы работать в режиме РВ. Одним планировщиком тут не обойтись.
Возьмём, к примеру, выделение/освобождение памяти, тот же malloc(). В обычной (не-ОСРВ) системе malloc() при каждом вызове ищет первый подходящий по размеру кусок виртуальной памяти (first fit), не особо задумываясь, как там будет дальше, если не находит, то начинает "тасовать" страницы, дефрагментировать и т. п. Таким образом, в процессе работы приложений память фрагментируется, находить нужный кусок каждый раз всё сложнее, и каждый последующий вызов malloc() занимает время, существенно большее предыдущего (экспоненциальная зависимость), а главное - время работы malloc() ничем не ограничено сверху. Ни о каком РВ при таком подходе не может быть и речи.
Другое дело ОСРВ - там malloc() использует специальные механизмы поиска (best fit), основанные на теории графов, и время его работы вполне ограничено сверху и более того, не сильно меняется от вызова к вызову.

Отклика на какое либо событие.
Событием может быть:
- системный таймер.
- прерывание.

Если в системе есть две задачи. У них соответственно приоритет 1 и 2.
То время отклика на событие задачи 1 будет переключение контекста.
У второй задачи будет их два:
-переключение контекста
-переключение контекста+время работы приоритетной задачи.

Если в менее приоритетной задаче требуется непрерывное выполнение куска кода. То ставится крит. секция.
При этом время пребывания в крит. секции должно быть учтено в высокоприоритетной задаче.

Также менее приоритетная задача не может повлиять на отклик высокоприоритетно. За исключением кри. секций.

При этом не забываем про прерывания. Они тоже могут повлиять на отклик. Поэтому их делают минимальными.

Сообщение отредактировал a9d - Feb 20 2012, 09:34

+Время выполнения прерываний

чем более РВ задача, тем меньше в ней malloc`ов.

бывают malloc-и с фиксированным временем

свои 5 копеек...
при всём том что сказали выше...
системы(имеется ввиду не ОС а именно "железные" системы) "реального времени" НЕ ЕСТЬ мк с РТОС ))

т.е. ваша задача в МК может гарантированно вызываться каждые 10 мс, но вот в целом МК может не обеспечивать данного понятия либо иметь гарантированный отклик значительно бОльший.

(круглый)

РТОС не гарантирует вызов каждые 10мс.
А гарантирует время отклика. МК с РТОС с этой задачей справляется.

Лучше спросите кто считал время такого "гарантированного" отклика в RTOS.
Принципиальная возможность посчитать не есть еще реальная возможность.
Ни в одной даже самой раскрутой RTOS не найдете формул расчета отклика. О чем бы это могло говорить?
Отклик меняется даже от опций компиляции. Как вы собираетесь его считать?
'реальное время' это маркетинговый термин.
Чаще означает, что дивайс действительно справляется со своей задачей.
Или что быстродействие микроконтроллера адекватно быстроте управляемых процессов.

А почему это его нельзя рассчитать?

Временем переключения контекста можно пренебречь и взять заведомо большим. Тогда влияние компилятора будет списано.
Время выполнение процесса, легко определить.
Учесть прерывания тоже довольно просто. Нужно знать только их максимальное возможно количество.

Да и о каком маркетинге идет речь??

В точку.

... знакомые споры разгорелись с новой силой через 2 года после завершения предыдущего тура

Ну ещё добавьте к этим определениям:

- в системах без вытеснения, однопоточных, не мультизадачных - нет смысла говорить о реалтаймовости: они все реалтайм ... в некотором смысле MS-DOS самый что ни есть реалтайм

- в системе, сверх сказанного должно быть гарантировано не возникновение инверсии приоритетов (для этого рассмотрите пример, но как минимум 3-х процессов);

- а для обеспечения пред.п. придумано не так уж много способов: а). наследование приоритетов на примитивах синхронизации или б). граничные приоритеты примитивов синхронизации + в). такие дисциплины диспетчеризации процессов как адаптивная и спорадическая...

А выполнение всех этих условий наблюдаем ох как в мало операционных систем!

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

А какие ОС "дурят" ?
Можно примеры с пруфиками?

Да уж.. Этот код который сможет выполнить любой превратит вашу ДОС-РТОС в тыкву




"А мужики то не знают" - ПО зачем-то сертифицируют на соответствие стандартам, например такому - ничего не гарантирующему
http://en.wikipedia.org/wiki/DO-178B