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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(круглый)

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

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

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

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

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

В точку.

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

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

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

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

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

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

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

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

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




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

можно от обратного - только то, что можно считать realtime: pSOS, QXN, vxWorks ... OS-9, в какой-то мере...


завалить всё можно, дело нехитрое ... но к детерминированности или нет поведения это не имеет никакого касательства.


а это? так это рыночные игрища ... с "вытесняюще конкурентов многозадачностью"

Теперь убираем ДОС-РТОС и запускаем вашу "задачу" нативно и получаем ровно то же что было с ДОС-РТОС - чтобы иметь детерминированность ни одну ф-ию ДОС-РТОС вы не можете вызывать. Поздравляю - с таким же успехом можно из /dev/random засунуть в память что-нибуть и назвать это РТОС.

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

Moderator: Т.к. никаких действий после оглашенного предупреждения я не увидел, то обещанные наказания исполнены. На будущее рекомендую предупреждения не игнорировать.

Это вообще условие желательное для любой системы под управлением контроллера/процессора.

Маркетинг это или нет, но есть , так сказать, просто операционные системы и операционные системы "реального времени". Основное отличие в принципах построения и требованиях предъявляемых к планировщику. Если у первых (та же Винда) трудно прогнозировать когда, после возникновения события, будет дана возможность его обработать. (Хотя и под управлением Win ухитряются строить системы real time), то у RTOS с определенной/заданной погрешностью это просчитать/измерить все же можно. И, с определенным допуском, получается повторяемый результат.


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

Никто не скажет что Windows 7 не среагирует в течении часа на какое либо одно событие. И это будет повторяемый и вполне детерминированный результат.
А значит для потока таких событий Winows 7 вполне система реального времени.
Ведь при определении реального времени всегда стараются политкорректно не говорить об абсолютном быстродействии.

На самом деле ИМХО большинство подразумевает быстродействие, и я полагаю что на современном этапе для RTOS с виртуализацией памяти это время 10 мкс, для RTOS без виртуализации это 1 мкс и меньше.
Т.е. если ось на может уложиться с переключением контекста железно в 10 мкс то рано или поздно пойдут слухи что она не RTOS.
Но прямых обвинений не будет, ведь трогать быстродействие в "профессиональных" оценках RTOS строго неприлично.

И тут тогда можно ссылаться на планировщик, структуру и т.д. , придумывать другие критерии чтобы добиться статуса RTOS.

RTOS это глубоко контекстно зависимый термин.

Виртуальная память может и не требовать дополнительных расходов - см FCSE на arm, при таком подходе инвалидация cache и tlb не требуется при переключении контекста.

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

Резюме: RTOS в "общепринятом" смысле не существует и не может существовать.
О чем еще AlexandrY в первом посте намекал, впрочем, он так и не ответил на вопрос ТС-а.

Предлагаю поразмышлять над следующим:
1. Сколько выполняется операция "ноп" на интеловских процессорах? База - http://www.intel.com/content/www/us/en/pro...er-manuals.html
2. Windows XP - real time система по POSIX.1?
3. QNX (VxWorks и т.д.) - real time системы по POSIX.1?
4. Наследование приоритетов (как и ceiling) избавляет от инверсии?
5. Спорадическая диспетчеризация нужна для избавления от инверсии приоритетов? А зачем тогда?

P.S. AlexandrY в ударе

Чтоб дурить эффективнее придуман термин "Soft real-time systems"




как Вы думаете, сколько и какие OS не впишутся в 10 мкс, если процессор работает на ~80MHz и кеши выключены ?



согласен, однако существуют реал тайм системы т.е. HW + SW ( OS + прикладная часть), которые удовлетворяют по реал тайму в конкретных узких областях применения, в определенном месте в определенное время.... как то выше изложил AlexandrY

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


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