QNX opensource! Опции

[Nixon]

Сегодня QSSL открыла исходные коды QNX 6 (правда под собственной лицензией, но все равно для всех).
Более подробно -> www.qssl.com

[vshemm]

Так, давайте разделим понятия "скорость", "детерминированность" и "реалтаймовость". Первые два - характеристики ОС, в то время как третье - интегральная характеристика и зависит от задачи. Так же не совсем верно, что RTOS обычно медленнее GPOS, скорее микроядерные всреднем медленнее монолитных, а это совсем другое.

По надежности - тоже спорный вопрос. Все ОС требуют немалой доработки напильником в случае, если они применяются в критичных по надежности задачах. И никто не использует их "из коробки", разве что производитель сам заточил ОС под определенную задачу. Другими словами, то, что в Канаде АЭС управляются QNX'ом, не значит, что его будут вслепую внедрять на АЭС за ее пределами. А вот рассматривать как кандидата - да. Трудоемкость доработки - вопрос отдельный

По шедулеру. Для однопроцессорного варианта - все нормально, масштабирование отличное, т.е. O(1). Для SMP - тут явно сыровато. И проблема даже не в том, что шедулер зависит от количества нитей (это важнее для всяких серверов с огромным количевством запросов), а в том, что он может исполняться только на одном процессоре. Т.е. другие процессоры будут блокироваться на нем. Более того, все говорит о том, что и с микроядром тоже самое, как только один процессор вошел в него, все остальные будут ждать. Учитывая, что каждый чих происходит через микроядро, оно может стать узким местом. Честно говоря, еще не въехал в Ваши тесты, но у меня ощущение, что тестируется что то другое

Далее. Шедулирование происходит не только в момент системного тика (тут речь уже не только о QNX, а вообще об ОС в целом). Есть еще много мест: принудительный вызов шедулера в коде, блокировка на мьютексах/семафорах и т.п., различные сигналы, в т.ч. и из обработчика прерываний. И это хорошо, т.к. повышает скорость срабатывания логики. А вот небольшой системный тик не нужен вообще (достаточно возможности его менять в некоторых пределах), т.к. при этом повышается (и очень сильно) оверхед. И правда, общение с внешним миром происходит либо асинхронно по ивентам, либо по циклограммам, тут принудительное шедулирование не нужно, можно обойтись своими силами. А вот для организации "параллельного" выполнения задач - да. На сцене появляется квант времени (time slice), т.к. классический алгоритм FIFO никогда не допустит вытеснения более приоритетной задачи менее приоритетной (в RR тоже есть time slice, но мы рассмотрим "супер быстрый" алгоритм, где даже самая низкоприоритеная нить получает время). И зачем тут малый квант? Более того, обычно чем выше приоритет у нити, тем ее квант больше. В линуксе он меняется гдето от 5мс до 800мс. Кстати, в нем же недавно появилась опция TICKLESS - холостых тиков вообще нет (по задумке). Очень интересная опция, жаль пока нет времени разобраться

P.S. Оффтоп, конечно, но что поделать

[prog_sun]

http://www.dedicated-systems.com/encyc/pub...time_definition

There are _several_ definitions of real-time, most of them contradictory. Unfortunately the topic is controversial, and there doesn't seem to be 100% agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies mailto:gillies@ee.ubc.ca ), is the following:

"A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred."

2. POSIX Standard 1003.1 defines "real-time" for operating systems as:
"Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time"

там есть еще другие определения. А мне вот это понравилось

4. One will also see references to "real-time" systems when what is meant is just "fast". It might be worth pointing out that "real-time" is not necessarily synonymous with "fast"; that is, it is not the latency of the response per se that is at issue (it could be of the order of seconds), but the fact that a bounded latency sufficient to solve the problem at hand is guaranteed by the system. In particular, frequently, algorithms that guarantee bounded latency responses are less efficient overall than algorithms that don't.

и вот это

5. One will also occasionally see discussions of "soft" vs. "hard" real-time systems. In many of these discussions, "hard" real-time means the type of real-time system discussed above, and "soft" real-time means systems which have reduced constraints on "lateness" but still must operate very quickly and repeatably. However, the definition is controversial, as some mean by "hard" and "soft" the degree of time constraints. For instance, a real-time process attempting to recognize images may have only a few hundred microseconds in which to resolve each image, but a process that attempts to position a servo-motor may have tens of milli-seconds in which to process its data.

там еще много чего интересного.