real-time ??

вопрос на сколько мягкий :)

А ОС вообще связана с временем кроме как по средствам встроенного будильника ::) ?

50 mls (миллисекунд) - например.
Если в течении этого времени (50 mls- 100mls) не произойдет нужная реакция 
всей системы (ОС + прога, если нужно драйвер I/O) - то плохо.

Хотя не очень понимаю зачем нужны точные границы.

Это-же чисто теоретический вопрос: корректно заявление или нет. 
Ведь не об Ос идет речь, а о программировании задач с ограниченным
временным пределом реакции системы  под ОС - общего назначения.

Я по существу спрашиваю. Не прикалывайтесь пожалуйста.
У меня есть небольшой опыт в real-time, но я сомневаюсь.
Прошу просто помочь если знаете. 

"Мягкий риалтайм" - это что-то сродни "слегка беременна".

>"Мягкий риалтайм" - это что-то сродни "слегка беременна".

ты бы хоть копирайт (с) Irsi ставил.

Я перед тем как открыть эту тему прочитал почти всю
полемику по ссылке с темы на главной странице: "Real Time Linux".
Пожалуйста не начинайте снова.
Если можно ответьте просто на вопрос правомочно утверждение или нет.

Краткий ответ - ДА.

Пример - воспроизведение MPEG4

Если есть верхняя граница - то это уже жесткий риалтайм. И поддержка от ОС нужна соответствующая.

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

Например, в системе поливки ромашек минута -- вполне приличное время отклика на изменения влажности или температуры. Это и есть реал-тиме для ромашек. Если хочется крутить кино, то подойдет и интел-х86.

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

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

Вообще говоря: жестокий, шустрый реал-там на х86 невозможен, ввиду полной ублюдочности архитектуры: синхронные шины; динамическая память, которй нужно процессорное время на регенерацию; DMA для флоппи-диска; процессор, который не знает заранее, сколько он будет вычислять 2+3.

A ежели хочется че-то сильно РТ, можно начать с ti.com, atmel.com, www.analog.com/processors/processors/sharc/

Спасибо, что конкретно и по существу, всем спасибо и за ссылки то-же,
обязательно посмотрю.
Но 
из вышесказанного получилось 2 утверждения:
1. Краткий ответ - ДА. 
Пример - воспроизведение MPEG4
 - согласен, так как сам писал потоковый видеосервер.
2 Нет.
 - то-же согласен так как Linux/FreeBSD - ОС общего назначения и
нет у них таких системных API-интерфейсов, с помощью которых
можно заставить систему гарантировано отрабатывать в нужное время.
(не та архитектура ядра)

Вопрос был :
Корректно ли говорить о задачах real-time (то-же самое потоковое видео,
или скажем управление воротами или антеной) решаемых под управлением
не real-time ОС, например Linux
 - как о программировании задач в режиме реального времени  ?

(извините наверное не дописал)

Никто не говорит об управлением машиной(бортовой компьютер) или поездом.
Там все ясно: VxWortex, QNX, ...

может вообще нельзя говорить о задачах real-time,
начиная с определенной верхней временной границы для реакции системы ?

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

> ты бы хоть копирайт (с) Irsi ставил.

Irsi не автор этого выражения. Копирайт был бы неуместен.

Я вам не скажу за всю Одессу, но судя по всему, RTOS имеют довольно узкую и очень специфическую нишу. Я в ней не работал и всячески стараюсь избегать решений на их основе. Причин тому несколько.

Во-первых нафига козе баян? На сколько я понимаю, всякая ось позволяет шарить время железа на несколько задач. К примеру: слопать данные, сложить умножить подытожить, выдать сигналы управления, а ежели что не так поведать о себе миру. Былаб ось грамотная можно таких процессов напихать пока железо не треснет. Теперь вопрос: а оно тебе надо? Эту ось надо где-то купить/стащить, надо закупить железок тоже сильно не бесплатных, жрать элекричество все это добро будет мама не горюй.

Ну чтоб совсем конкретно. Была такая проблема: фотокатод испаряется в течении нескольких милисек., если какой-нибудь урод включит свет не сняв высокого. Если фотик один, то нечего и заморачиваться. Выкинул, новый воткнул и поехали. Но все мы человеки. Есть девайс где их 5 штук. Выкидывать дороговато будет, а в качестве раздолбая выступали почти все, включая и меня. Есть много способов сделать защиту:

1) затарить супер борду с PowerPC или где там этот ос работает, запхать ему 5 прерываний от измерителей тока, дальше все софтом. Прикинули и прослезились... от 5килобаков, или штукель/ФЭУ. Что соорзмеримо с ценой последнего... Деньги даже не проблема, проблема это время и сложность.

2) плис за 5 басов, процессор интель от атмела за трешку и рассыпухи на рупь. Три дня работы паяльником, максплюсом и вимом и вуаля! В плисе перещетка выхода, атмел все меряет -- там АЦП есть, и шлет все по RS в комп.

>Вопрос был : Корректно ли говорить о задачах real-time (то-же самое потоковое видео, или скажем управление воротами или антеной) решаемых под управлением не real-time ОС, например Linux - как о программировании задач в режиме реального времени ?

Разумеется:

Решение задачи подразумевает наличае методов решения данной задачи. Даже в OC не обеспечивающей гарантированное время отклика такие методы работают. Единственное что они не обеспечивают это _гарантию_ максимально допустимого время отклика, однако это не должно приводить к мгновенному и необратимому выходу системы (в широком смысле слова) из строя. Например при том же проигрывании видеопотока вы можете потерять часть кадров при воспроизведении (frame drop) но на общей работоспособности системы это не скажется.

> ты бы хоть копирайт (с) Irsi ставил.
Хер ему а не копирайт. Ни фраза ему не принадлежит, ни мысль. Я в отличии от онанимусов чужие мысли не перепощиваю :(.