ну, да, это и есть главное требование к рилтайму (из названия следует). Там ещё планировщик такой же - приложение должно успеть к дедлайну. Либо вызвать эксепшн "опускайте аварийные стержни в реактор".

(Reply to this) (Thread)

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

(Reply to this) (Parent)

Ну, не совсем корректное утверждение.

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

И, соответственно, всё не так геморройно как кажэтся.

(Reply to this) (Thread)

Вас могут уснуть (вытеснить) на любое время безо всякого Вашэго участия

Это мы по второму кругу начинаем. Совсем без причины никакая мала-мала вменяемая ос выгружать программу не будет. Если железо исправно и достаточно для выполнения задач - то причина это как правило другие программы, запущенные на том же железе. А не иметь физического контроля над железом и _всеми_ выполняющимися программами и приэтом требовать реалтаймовости - это на мой взгляд нонсенс.

(Reply to this) (Parent) (Thread)

> не иметь физического контроля над железом и _всеми_ выполняющимися программами и приэтом требовать реалтаймовости - это на мой взгляд нонсенс

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

(Reply to this) (Parent)

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

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

Вот как раз хороший пример одной из фич, которыми RT-OS отличаются от не RT

(Reply to this) (Parent) (Thread)

Ну,если совсем уж на диск - сейчас мало кто такого не умеет.

(Reply to this) (Parent)

Да хоть по десятому.

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

Что ещё веселее: в современных условиях дажэ реалтаймовая задача почти всегда выгружэна нафиг. Поскольку объём реалтаймовых задач дажэ в хардреалтайм системе обычно гораздо меньшэ, чем объём всей остальной шняги по общению с внешним миром.

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


Могу привести пример радио-АТСки (базовой станцыи DECT на несколько сотен абонентов). У неё есть реалтаймовая часть (софт, по счастью), которая отрабатывает DECTовские сообщения, делит канал между абонентами, маршрутизирует звук и сообщения ISDN. И есть нихера не реалтаймовая часть, которая отвечает оператору, ведёт базу данных пользователей и их идэнтификаторов, перекладывает логи в архив и создаёт бэкапы. Вот вторая по объёму кода заметно большэ, чем первая. Но несмотря на это благодаря реалтаймовым патчам на одну известную ОС они замечательно ужываются на одной практически писюковой плате, с совсем писюковым процэссором и стандартной периферией (ну, кроме АЦП/ЦАП и гетеродина в DECTовских платах).

(Reply to this) (Parent) (Thread)

Если вы, скажем, в "нихера не реалтаймовой части" запустите dd, то реалтаймовой части резко поплохеет, кажется даже на RTlinux. Но вы, естественно, в рабочем режиме этого делать не будете. Мой пойнт был именно в этом: обеспечение гарантированной реакции отдельной программы в агрессивной софтверной среде редко бывает условием задачи. Как правило нагрузку внешней среды можно ограниить какими-то разумными рамками.

(Reply to this) (Parent) (Thread)

Нет, не поплохеет. Ну, разве что dd напущен на какой-то странный девайс, разработичики драйверов которого не знали про требования к realtime. Но в настоящем RTlinux таких драйверов нет.

(Reply to this) (Parent)

> "выполнено", "ошибка" и "не успела я"

"нет, не допустим". Не успеть - не должно и по построению не может. Когда я это делал, это означало что никакого IO в тех системных вызовах кроме inp/outp и неблокирующей работой с очередями общения с "мягким" миром не было.

(Reply to this) (Thread)

Даже самые большие буфера в озу рано или поздно кончатся.

(Reply to this) (Parent) (Thread)

в моём случае это проходило по разряду "выдернули из розетки"

по-хорошему можно протянуть до гуя и даже диска, но это не на ширпотребных OS

(Reply to this) (Parent)

Да, и это надо понимать. И что-то с этим делать. Ничего страшного (не должно случаться).

Во многих случаях, например, критичный обмен приходит прямо в realtime-часть, и уходит прямо в realtime-часть. Все остальные bells&wistles могут подождать часок-другой-третий, пока мастер не приедет.

(Reply to this) (Parent)

вообще, возможно, переполнение буфера и игнорировалось, я уже не помню точно.

(Reply to this) (Parent)

Под такие ОС и ПО надо писать соответственно, иначе смысл теряется. В старые времена там отказывались порой, например, от таких прелестей архитектуры популярных микропроцессоров как прерываний и т.п.: "разделением времени" занимались сами приложения, состоящие из малюсеньких кусочков, передающих управление ядру самостоятельно.

К персоналкам, за которыми люди сидят, это не должно иметь особого отношения: скорее уж к тем, кто пишет программы для микроконтроллеров. Ну или сетевого оборудования, например, мобильных телефонов (без Явы всякой) и т.п. Про VxWorks, если из Википедии, можно почитать.

Для современных персоналок написанное Вами было бы неплохо применить, но ясно, сколько проблем будет с привычными программами, так что можно только вздыхать и жалеть, что по этому пути не пошли. RTLinux или Windows CE же, по идее, очень грубо,— попытки сэкономить на образовании, чтобы не слишком люди переучивались для разработки специфического ПО.

(Reply to this) (Thread)

RTLinux или Windows CE же, по идее, очень грубо,— попытки сэкономить на образовании, чтобы не слишком люди переучивались для разработки специфического ПО.

Еще на софте - codebase у них очень большой - жалко терять.

(Reply to this) (Parent) (Thread)

Да. Если не для примера писать, то причин важных вообще много может быть.

(Reply to this) (Parent)

касаемо "выдернуть из розетки" и прочих катаклизмов

Реалтаймовые обещания выполняются при соблюдении некоторых допущений. Это как "не выдёргивать из розетки" и "не стрелять из пулемёта в системник" ещё и "память в буфере не закончится". Обобщение этих требований в одну группу может показаться смешным, но они совпадают в одном - при работе системы такого не происходит, а если произойдёт - то мы сделаем так чтобы не происходило.

(Reply to this) (Thread)

При достаточно длинном списке условий такого рода любая ОС становится реалтаймовой.

(Reply to this) (Parent) (Thread)

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

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

В общем, параллельное архитектуры рулят...

(Reply to this) (Parent) (Thread)

Реалтайм на голом железе - это, как бы, совсем другой вопрос.

(Reply to this) (Parent)

Виндам этого ох как не хватает. Едва ли не каждодневно случается чертыхаться, взывая к ним: «Оставьте, ради всего святого, эту задачу! Я передумал её делать (или вообще по ошибке запустил)! Ослобоните интерфейс!».

(Reply to this)

> в реалтаймовых три - "выполнено", "ошибка" и "не успела я"

В реалтаймовой RSX-11M (ОСРВ), которую упоминал kouzdra@lj, отсутствовал такой код возврата системного вызова как "не успела".
И в принципе некоторые её системные вызовы могли никогда не возвращать управление (например, EXIT$S), или не возвращать управление неопределённо долгое (не зависящее от операционной системы) время (например, QIOW$ или WTSE$).

Реалтаймовая ОС - та, которая позволяет использующему её программисту(ам) создавать системы реального времени (с гарантированным временем отклика на внешние события). RSX-11M позволяла, но сама по себе не гарантировала это.

(Reply to this)