Что такое реал-тайм?

во, годный анонимус зашел в такую убогую тему. тс зачетно вбросил.

потому-что для самого худшего случая 10к об.мин. для 4х тактного 4х цилиндрового двигателя, это всего навсего примерно 334 герца или 3мс. что для систем реального времени вообще не время регулирования. Учитывая что эбу шерстит готовыми таблицами, а краткосрочные и долгосрочные поправки аппроксимируются за довольно большое время. Входные данные, исключая мертвую точку цилиндров, являются медленно меняющимися.

И чем это противоречит тому, что линукс и РТ несовместимы?

Царь уже не торт.

Это не царь, потому и не торт.

линукс и РТ несовместимы

смотря с какой стороны смотреть - можно иметь Linux для задач не требующих RT и на выбор целый букет програмно-аппаратных решений для RT задач + IPC. RT в ядре Linux даже с патчами - это фуфло, но и его детерминизма часто бывает достаточно.

Правильно ли я понимаю, что это программирование основанное на потоках?

Нет. Совершенно не правильно.

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

Как скажешь, я тут диванный теоретик, все знания из универовских лекций десятилетней давности. А какими промежутками софт реального времени обычно оперирует?

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

Вау. Т.е. на мегагерцовых частотах это единицы - десятки тактов?

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

почитал я обсуждение этой темы и сделал вывод что RT — это Линукс с НЕвключённым cron :-) [ну или любая другая система с НЕвключённым cron :)].

чтобы убедиться — можно открыть Quake3 и увидить что количество кадров в секунду ни когда не опускается ниже 58~59. (и ни каких подгрузок и подзависаний).

Ты мастдайку осью назвал? Не смеши мои тапочки!

А для RT нужны специальные операционки.

Windows CE - риал-таймовая ОС.

с НЕвключённым cron

ээ. А при чём тут крон-то? В РТОС вполне могут быть какие-то ивенты, запускающиеся периодически. Вот даст ли им отработать планировщик — другой вопрос. Для этого существуют механизмы приоритетов (в т. ч. и для прерываний), очередей и прочей синхронизации.

Скорей уж, наоборот, можно говорить о том, что в РТОС крон есть обязательно — это планировщик, управление которому передается в жёстком цикле по аппаратному таймеру.

Все, я сейчас лопну от смеха.

Всем только легче станет.

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

А при чём тут крон-то?

потому что количество кадров в секунду упадёт когда он что-то делат там активно :)

В РТОС вполне могут быть какие-то ивенты, запускающиеся периодически.

а в Quake3 разве нет подрограмм, которые выполняются с периодичностью или\и по событию? :)

Для этого существуют механизмы приоритетов (в т. ч. и для прерываний), очередей и прочей синхронизации.

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

мне кажется в такой ситуации высокоприоритетная задача может слегка сосн^Wопоздать со своими рамками времени :-)

и кстати, да, вот мне интересно — что именно произойдёт когда высокоприоритетная задача в RT OS не уложится в свои рамки (например из-за того что ждала синхронизационный примитив, связанный с низкоприоритетной задачей)...

...начнётся ли какой-то внутренний психоз внутри RT OS? :-) если психозов не будет — то я вообще не вижу различий с обычным Linux\Windows :-)

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

...высокоприоритетная задача никого ждать не будет, прервет все что ниже нее

как-то это... ээээммм... грубо :-) по-варварски

И чем это противоречит тому, что линукс и РТ несовместимы?

причем тут вообще линукс? речь шла о многоядерности и поточности

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

Да, ты все правильно понял. Релтайм пишется на Erlang, Clojure, Scala, т.е. на языках, которые подразумевают нормальную модель многопоточности.

Релтайм пишется на Erlang, Clojure, Scala, т.е. на языках, которые подразумевают нормальную модель многопоточности.

Победа.

Все, я сейчас лопну от смеха.

Эдди, за что тебя люблю - ни**я не знаешь, но по любому делаешь выводы.

1. Windows CE умеет hard real time. В отличие от чистого линукса. На какие-либо другие хар-ки CE это не влияет никак.

2. На одном процессоре сполне себе могут жить много real time потоков, как одного, так и разного приоритета, при этом соблюдая гарантированное максимальное время реакции на события (для которых известна информация об их периодичности).

3. Xenomai - это хороший, годный hard real time. Который еще может на том же ядре гонять и обычные линукс-процессы.