реал тайм осы

П.6. - очень часто пишут, что "RTOS должна обеспечивать наследование приоритетов" ... вот MS всё спорила, что в WinNT есть наследование приоритетов ;-)...

Этот пункт очень сильно связан с предыдущим...
Наследование приоритетов - это когда вызовы (в том числе и API, в том числе и API ядра!) выполняются под приоритетом вызывающего потока (процесса). Говорят, что "в макроядерной архитектуре это весьма трудно реализовать"... но дело то в том, что даже реализовав это - оно там бессмысленно:
- отношения приоритетов имеет смысл только в контексте кто и кого может прервать при исполнении. Но если API ядра выполняюися в блокирующем режиме - то какая разница, под каким приоритетом они это делают?!

В QNX - наследование приоритетов - органичная особенность, блюдущаяся на всез уровнях иерархий.

Следующий пункт - это вот тот сакраментальный N+1-й критерий, о котором я упоминал выше, и который появился гораздо позже остальных: "RTOS должна препятсвовать возникновению инверсии приоритетов". Это потрясающе интересная проблема, в общем виде она не решена, но я даже не стал её выносить в отдельный "П", т.к. - как можно вообще рассуждать об "инверсии приоритетов" в OS-ах, в которых нет наследования приоритетов!!!

P.S. Я не буду детально расписывать "инверсию приоритетов", но только скажу: а). этот эффект возникает только при рассмотрении 3-х и более параллельных веток выполнения (поток, процесс), потому его и "просмотрели", б). выявляется он крайне редко - для этого нужно стечение временных интервалов этих >=3-х процессов, в). поэтому оттестировать его (отсутствие ;-)) практически невозможно, г). но когда возникает - то элементарная логика выполнения нарушается (низкоприоритетный процесс выполняется, а высокоприоритетный - стоит и его ждёт), д). ... и вот тогда точно "рванёт"... ;-( (какой там закон Мэрфи?).

П.8. - "RTOS должна обеспечивать гибкие механизмы организации параллельных вычислительных ветвей и взаимодействия между ними" - обычно здесь понимают механизмы "лёгких" процессов - thread (хотя это как-раз совершенно не обязательно, в VxWorks, кажется, существуют только пользовательские потоки, но не процессы). Именно по этой причине использование MS-DOS в качестве среды выполнения реалтайм не может даже рассматриваться, а так часто встречающиеся в обсуждениях утверждения "... а вот мы слабали под MS-DOS что-то такое вполне в роде реалтайм" - не могут вызывать даже смеха, потому, что смех этот закончится слезами...

Это-то как раз, как будто, есть в универсальных OS... Но реализации? В Linux - thread создаются через clone(), т.е. как теже процессы (и даже имеют отличающиеся pid). В Windows - есть thread, но всё, что связано с их "собственными" областями данных (pthread_key_*() в POSIX) - всё смазано и с большими ограничениями.

А средства IPC (межпроцессного взаимодействия)? Весь их "джентльменский набор" строго формализован POSIX 1003b..., но во всех универсальных OS их то есть крайне ограниченное подмножество, то появляются "новые" и заведомо избыточные ("критическая секция" в Windows).

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

Иначе - о каком минимальном (или даже предсказуемом до порядков) времени реакции можно говорить, если требуемая для реакции страница памяти окажется выгруженной? Можно возразить: многие OS предусматривают возможность пометить страницу как "невыгружаемая". Предоставляют, но какие из них метить, если это апприорно неизвестно... все? тогда это и есть несвопирование.

На это возражают - во многих OS есть возможность запретить свопинт (вот выше про OS/2 это было сказано). Но "запретить" и "не использовать" это не одно и то же:
- как будет вести себя OS со штатно включенным свопингом, которая тестировалась и отлаживалась именно так в 99.999...% случаев - при отключении свопинга как опциональной возможности (которая и тестировалась то может всего 3 ;-) раза)?

P.S. Понятие "свопинг", кочующее с обсуждения в обсуждение, вообще а).ошибочное и б).вносит много заблуждений. В современных OS свопинга вообще-то нет, свопинг был в Win 3.1/3.11 - когда при нехватке RAM часть области задачи выгружалась на диск. В современных OS есть виртуализация страниц RAM на диск - похоже на свопинг, но и только, не более, чем "похоже": о какой выгрузке задачи можно говорить, когда любая задача после подготовки и перед началом выполнения даже ещё не загружалась в RAM, а только выполнено распределение несуществующей физической памяти задачи и сделано её отображение на дисковое пространство?

А отсюда следует ещё одно тонкое требование к realtime OS - в такой системе не должен использоваться механизм COW (copy on write) при создании копий областей RAM. В частности - при ветвлении процессов на манер UNIX-овского fork()! А этот механизм в универсальных OS отменить нельзя.

Первоначально опубликовано evgen Почему это нельзя ? Очень даже можно. В однозадачном случае дос обеспечит навыисшую скорость реакции, поскольку никаких накладных расходов и переключений контекста(если не рассматривать большую разницу в производительности real 32bit protected mode). Более того - можно и внутри досовской задачи организовать "псевдомногозадачный режим в стиле DOS" Другое дело - чего это стоит, как это отлаживать и что делать с записью на диск, сетевизмами и т.д. и т.п. Вы будете смеятся, но этот "псевдомногозадачный режим в стиле DOS" используется и некоторых уникс-приложениях, в частности - в хорошомаштабируемом прокси-сервере squid [QUOTE]. Здесь я сознательно пошутил - сформулировал утверждение провокационно... и результат не заставил себя ждать, и именно тот, которого я ожидал. Всё было бы так как вы говорили, если бы в природе вообще существовали однозадачные вычислительные процессы. Но их - не бывает! На это же купились парни из MS, которые к тому времени мирно писали свои BASIC-и в ангаре, когда их на своё горе вытащила оттуда IBM. Они тоже так думали к MS-DOS 2. А к MS-DOS 3 им стало понятно, что и при выполнении одной пользовательской задачи - им нужен параллелизм: для спулинга печати, поначалу... Они добавили мультиплексор Int2F ... и понеслась... И ещё, к развеиванию иллюзий однозадачности у автоматчиков (а она - ой как есть!) - если у вас есть хоть одно (!) ассинхронное событие внешнего мира - прерывание: у вас уже есть классическая многозадачность! И хорошо, если она обслуживается такими же классическими API OS, и очень плохо - если "самопалками" от непонимания, что перед нами таже общая проблема ("вот кинжал: он хорош для того, у кого он есть, и плох - для того, у кого его нет"(с) ;-)). А вот на предмет: "псевдомногозадачный режим в стиле DOS" - акститесь! Я столько руками переделал этих TSR, зубы на этом проел... много могу порасказать - о том, например, что почти все эксплуатируемые TSR были сделаны некорректно, а потом говорят "виснет, виснет"... Переключение в TSR корректно только в том случае, когда вы сохраняете контекст задачи - в DOS это PSP - первый сектор задачи, да и это ещё не всё... Теперь представьте: для переключения на выполнение 3-х команд в TSR ... начинаем сохранять 256 байт (куда? может на диск ;-)? или в область памяти - так её ещё выделить нужно, динамически, и лучше по принципу стека - этот TSR может другой прервать!?)... а выполнив - вернуть братно. Ещё будем об realtime и предсказуемости поведения говорить в этом случае? Первоначально опубликовано evgen дык вроде как родили ж posix thread'ы в ли/униксах ? Нет, это только "дык"... ;-). Как раз thread - одно из самых слабых и POSIX несовместимых мест в Linux (это не я сказал - а разработчики Linux, и обещали в будущих релизах поменять). Да и Linux - это 1990г. (это я дни рождения считаю)... QNX - 1981г. (чуть постарше MS-DOS будет ;-)), первые BellLabs & Bercley UNIX-ы - "от 1968" ;-) - было откуда в POSIX черпать, правда? [QUOTE=evgen] Критические секции тоже есть и используются. Чем оно избыточное - непонятно.

А потому, что:
- в POSIX его нет - не нужно, и так всего хватает;
- где мютексы есть - так критическую секцию создать труда не составляет, кто понимает...

Так и просится фраза из известного анекдота: "дык Страдивари, это он для лохов скрипки делал, а для конкретных пацанов - барабаны...".

Первоначально опубликовано evgen дык вроде как родили ж posix thread'ы в ли/униксах ?

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

POSIX - это и есть обобщение всех UNIX наработок под одним стандартом, и, в свою очередь - стандарт того, что должно быть в каждом UNIX, и кого можно относить к UNIX.

А написал я это всё для справки: детальнее, чем плохи thread в Linux, и в каком направлении они их собираются изменить - можно посмотреть здесь:
http://www.shelek.com/club/viewart.php?id=82
Кроме того, при некотором размышлении (хоть там нет об том ни слова), оттуда можно понять и почему плохи thread Windows (для SMP выполнения).