реал тайм осы

Первоначально опубликовано evgen Я пайпы стандарно пользую по нетбиосу. Таймауты и ошибки при потере связи там есть и я думаю что оно точно также будет работать и для случая netbios over ip, тем более что у других оно работает. Как оно там реализовано - мне без большой разницы.

"... при потере связи..." - это у вас толко в случае "нормальной" потери связи: завершение приложения, или выгрузке OSна обратной стороне. В этом случае ваш socket получит FIN сегмент. А read() (или read после select) возвратит вам 0.

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

Это всё прописано не в реализациях отдельных OS- а в RFCs TCP/IP!

Ну и при чем здесь компиляция?

Вы же мне просто предлагаете РУЧКАМИ каждое тревожное
место контролировать... что несомненно полезно,
но, увы, не надежно, не гарантирует отсутствие ошибок,
т.к. метод завязан на человеческий фактор.

Кстати, то, что у нас сделано структурно эквивалентно
предлагаемому Вами, только сконцентрировано в одном
месте, этот контроль деления на ноль не нужно специально
программировать, т.к. он выполнен КОНСТРУКТИВНО
(его невозможно избежать, даже если сильно захотеть ;-)...

Первоначально опубликовано VSerg Первоначально опубликовано Владимир Е. Зюбин Дмитрий Милосердов насчет последствий деления на ноль в UL: Ничего не будет- скажет что ошибка деления на ноль при компиляции. При чем здесь компиляция? Компиляция здесь при том, что прежде чем делить просто проверьте на что делите. код: if a<>0 to begin c:=b/a; end else    ...... обработка критической ситуации Избавит вас от любого отсыхания части ПО. У вас никогда и ничего не отсохнет. Это можно сделать в любом языке даже на IL/ :)

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

И я вот такую штуку слыхал, говорят,
в Кьюникс 5.хх введен своппинг. ;-)

Первоначально опубликовано Olej П.9. - этого пункта вы не найдёте ни в одном "академическом" перечислении (до таких ли конкретностей снисходить мужам от науки? ;-)) - это пункт "от меня": в RTOS ни при каких обстоятельствах не может быть механизма свопирования страниц на диск. И действительно нет: QNX, VxWorks, pSOS...

Первоначально опубликовано Владимир Е. Зюбин К сожалению, сайт, на который Вы ссылаетесь, сейчас в дауне...

Да, там что-то произошло, но это - практически впервые по-серьёзному (более чем на 2-3 часа) за 1-1.5 года. Но попозже - сходите обязательно: этот форум отмечен на конференции "QNX-2002" в С.-Петербурге QSSL (разработчик QNX) в 3-ке лучших некоммерческих информационных ресурсов по QNX в мире...

Кстати, скоро ... в 1-й половине ноября - в С.-Петербурге опять ежегодная конференция "QNX-2003".

Первоначально опубликовано Владимир Е. Зюбин Я это к тому, что палить по 1000++ зеленых на ОС - это круто, но для этого должны быть некоторые основания. Кьникс мы рассматривали, к сожалению, анализ показал, что его использование для нас экономически менее эффективно, чем ДОС.

А здесь есть какое-то явное противоречие масштабов... ;-) - поэтому требуется уточнить.

QNX действительно дорог начально - $7000-$14000 - но это developer-ская лицензия, т.е. ваше право поставлять коммерческие продукты на этой OS, так сказать ваше "въезжание" в сообщество разработчиков для QNX. Дальнейшие же "поэкземплярные" лицензионные платежи очень сильно зависят от тиражности изделия, и модульной комплектации OS, и составляет $80-$200 при малотиражности, и может падать до порядка на тиражах.

Кроме того, обратите внимание - может не все знают - что с ~2000г. предоставляется free полноценная версия QNX, на сегодня это QNX 6.2.1 NC (non-commercial), которая позволяет проверить и обкатать до уровня макета изделие без начальных затрат вообще.

Первоначально опубликовано Владимир Е. Зюбин Не стоит фетишизировать слова "реальное время"... тем более за ними ничего корректного с формальной точки зрения не стоит...

Фетишизировать ничего не стоит, по жизни даже вообще, не только по OS - это безупречно верно... ;-).

А вот то, что за словами "реальное время" - ничего не стоит - это преувеличение. Худо то, что то немногое, что реально "стоит" - оно засорено и закамуфлировано массой наносной информации, циркулирующей в этой сфере.

Вот то основное определение, которое повсеместно используется "давать гарантированную реакцию в гарантированное время..." - оно и вправду плохо формальное, а поэтому под него суют всё, что попало ("мягкий" ;-) реалтайм... - скоро появится "жидкий" реалтайм, на манер "жидкий кал"...). Но для его наполнения нужно выполнить некий комплекс обязательных требований, которые уже гораздо более формальные - я часть из них, как мог, попытался описать выше...

Обратите внимание: всё, что realtime - обросло вокруг легендами:
- почему-то многими считается, что realtime - это "быстро"... хотя realtime OS при прочих равных условиях, как правило, несколько (или заметно) медленнее, чем OS общего применения. И это понятно - все внутренние переключения контекстов там должны делаться тщательнее и корректнее.
- realtime - это термин из области надёжности (безотказности, живучести), а уж никак не скоростных характеристик: выполните операцию 1000000 раз и усредните: в универсальной OS у вас, с большой вероятностью, среднее значение времени выполнения будет ниже, но дисперсия тестов - значительно больше.
- и ещё, из области realtime... многие изготовители RTOS оперируют (беспокоятся) коэффициентами готовности 5 9-ток: 99.999% ... - это означает 5 мин. в максимуие простоя на 1 год непрерывной работы. Всем нужну ли и интересны такие масштабы цифр? Многие ли из обсуждаемых систем предназначены, должны и т.д. эксплуатироваться в режиме "год горячего времени"? И можно ли всерьёз говорить о потенциальной даже возможности работы в таких режимах общих OS: MS-DOS, Windows, OS/2...

А как аргумент того, что для realtime есть определённая ниша и это не чисто коммерческий трюк - говорит, по-моему, то, что RTOS как отдельный "класс" появились "параллельно" весьма давно ... RT-11 та-же - 70-е годы.

Первоначально опубликовано Владимир Е. Зюбин Есть некая конкретная задача, да решайте ее хоть на Виндовз, хоть на ДОС... если выполнены все требования ТЗ, то в чем могут быть проблемы?! 8-) А если задача выполнена не за 1000++ баксов, а за 40, то это ПЛЮС, а не минус.

Естественно...
Только вот то "плохо формализованное условие" - оно начинает работать (сказываться) при некоторой сложности ПО. Я бы сказал: именно сложности в смысле числа N параллельных ветвей развития процесса (multitasking, вне зависимости того, чем эти task выражаются: обработчики IRQ, process, thread...). Взаимодействие таких ветвей - это основное место нарушения realtime. RTOS (да и любая OS) - это такое-же ПО, которое вы пишите, из которго вы, как пользователь, можете использовать API. Альтернативы: либо мы все элементарные операции (чтение с диска, напр.) сами прописываем, либо используем то, что уже прописано в API.

Если вам знакома классическая работа Э.Дэйкстры "Взаимодействие последовательных процессов" - то вы должны знать, насколько там тонкие материи, и неочевидные при первом проходе, да и втором тоже... (а если вы не знакомы с этой работой - она в русскоязычном переводе публиковалась аж в ~1975г. - искренне советую: вы просто получите удовольствие от блеска ума). Так вот, в multitasking ничего принципиально нового со времён работ Э.Дейкстры не было придумано со 2-й половины 70-х - и всё это время ушло на реализации, и вытягивание тонких мест.
Возвращаясь к RTOS - вы с этой OS получаете API механизмы, совместимые с POSIX 1003b (realtime) - выверенные как в логических противоречиях, так и в реализациях за пару-тройку десятилетий. С соответствующими вероятностями deadlock-ов и других прелестей в "ручном" коде и в API.