реал тайм осы

Ну ты смотри...
Этот треклятый форум - полностью сожрал ответ :-(!
Ну что ж - попробуем ещё раз...

Первоначально опубликовано Владимир Е. Зюбин В стиле раунд-робин накладные расходы на организацию параллелизма примерно в 200 раз меньше, чем у QNX в однозадачном режиме...

Здесь что-то в семантике фразы - "в-разнос", я не соображу, к чему это... можно только предположить:

1. "В стиле раунд-робин накладные расходы на организацию параллелизма" - это что, в MS-DOS, что ли, для сравнения?
А вы "по-взрослому" делали "стиле раунд-робин организацию параллелизма"? т.е. с сохранением-восстановлением сегмента PSP? а сохраняли то где? у MS-DOS динамически запрашивали по Int21? :D Или стек PSP-сегментов закладывали на предмет вложенных переключений?

До и вообще, вы там что-то об "надёжности" и "предсказуемости" говорили? Ну-ка, ну-ка поподробнее...
Это что - в real mode и надёжно и предсказуемо??? :-o (даже если онозадачный режим, чего не бывает ;-), см. выше):

- когда любое приложение использует RAM где сочтёт нужным. Я в MS-DOS сам делал много приложений, которые используют RAM в обход цепочки MCB - сами себе выделяют, сами себе освобождают, сами себя переносят, "гуляют" по RAM, когда OS даже не подозревает об их существовании... Так можно делать приложения, переживающие перезагрузку - вам нравятся "баги" в вашем ПО, переживающие перезагрузку? ;-)

- когда каждый Int21 - нереентерабельный, непрерываемый ... что там ещё "не". Какой там раунд-робин, когда вы в Int21 завтрянете?

- а "организацию параллелизма" вы делали то с "тиканьем" от чего? Системного таймера на 20мсек.? Так если бы вы сделали с 30мин. переключением задач, то и все "300 раз" бы одолели...

Первоначально опубликовано Владимир Е. Зюбин "...расходы на организацию параллелизма примерно в 200 раз меньше, чем у QNX в однозадачном режиме..."

Ну нет, нет в QNX такого режима!...
Хотя я могу предположить, что вы имели в виду: multi-threading? Может и быстрее (но "по-взрослому"? см.выше ;-)) - так потому, как в protected mode, однако, контексту больше переключать... LDT там, GDT... об которых real mode - "ни сном ни духом"...

Но только в real mode, в конечном итоге - всё, что будет потом, после "организации параллелизма" - это только уповая на то, что "Бог не выдаст - свинья не съест" - как карта ляжет...
Фирма не даёт никаких гарантий!

P.S. Кстати, были такие real-mode multitask-еры, от сторонних производителей: C-Task мне вспоминается... Я так сильно предполагаю, что и по эффективности и по корректности они были существенно выше того, что вы можете сделать "в стиле раунд-робин"... Просто в силу того, что их производители занимались только этим (с этого жили), а вы вот: а).организуете параллелизм, б).автоматизируете АСУТП, в).как человек разумный - стоимости подсчитываете, г).статейки пописываете, д).в форуме вот время теряете ;-)... что ещё? Так вот C-Task - далеко не имел тех разительных характеристик об которых вы пишете.

Первоначально опубликовано Владимир Е. Зюбин Что там делается в многозадачном режиме вообще никто не знает в силу закрытости исходных кодов.

А что делается в однозадачном DOS в обработчиках Int2F, Int2A - вам совершенно однозначно понятно и предсказуемо?
Или у вас есть исходный код DOS?

И вообще - вера в панацею открытого кода - похвальная, но не больше, в обеспечение надёжности! Вы давно последний раз штудировали открытый код ядра Linux?

Первоначально опубликовано Владимир Е. Зюбин Конечно же нет. Мне это и не нужно. Мне и МС-ДОС не нужен...

Ну что ж...
Вполне достойный ответ ;-)...
И вполне приемлемое решение...
Т.е. - вы сами организуете весь требуемый API, и правильнее квалифицировать, что ваше ПО работает на голом оборудовании.

Вполне допустимо (и, может, и оптимально) - но ... только для задач относительно невысокой сложности, т.е. сложности - не в смысле объёта или решаемых задач, а в смысле: алгоритмической сложности, наличия сложных вычислительных процессов (ортогональные преобразования - БПФ, вэйвлеты, АР-фильтры etc.), асинхронных событий и обменов по каналам связи и т.д.

Первоначально опубликовано Владимир Е. Зюбин У нас никто нигде не гуляет. Все это хозяйство можно и в ПЗУ затолкать... ОЗУ нужно, конечно, но не так много как ПЗУ... сотня килобайтов - за глаза... (все от приложения зависит, понятно, но все же)

Естественно!!! ;-)
У нас тоже не гуляет...
И хорошо бы, если бы ни у кого не гуляло. ;-)

Но это можно утвеждать только если ваше ПО гарантировано не содержит ошибок!

Мне когда-то обратило на себя внимание, и с тех пор я его всегда помню, утверждение всё того же Э.Дейкстра: "... в природе нет и не было ни одной программы, вообще не содержащей ошибок. Вопрос только в том, с какой частотой и при каких обстоятельствах эти (содержащиеся!) ошибки - выявятся...". В этом смысле была и страшно поучительная книжка Моулер и Форсайт "Машинные методы математических вычислений" (кажется так), в которой они показывали - насколько сложно без ошибок (не "пыонерских" ошибок, а численных) написать, к примеру, решение элементарного квадратного уравнения (3-й класс церковно-приходской школы ;-)), и к каким "смешным" результатам решения приводят эти ошибки.

Отсюда уже недалеко до утверждения, которое, в общем, уже практически общепринятое, что тестирование, сколь угодно тщательное (до бесконечности! ;-)) - ни на шаг не приближает..., ни в малейшей мере не гарантирует ваше ПО от ошибок - оно может быть только "отрицательным подтверждением", в случае, когда оно их выявит.

Так вот - к чему это всё? При достаточном объёме примитивных действий (например, вызовов функций, т.е. это и есть API вашей прикладной программы) у вас комбинаторно накапливается количество вот этих "скрытых мин" в программе. При реализации на голом железе - все ошибки всех API - на вашей совести. Если же общеупотребимый API (а это может быть 90% потребности программы) предоставляется OS, и этот API на непротиворечивость многолетне обкатан стандартами (тем же POSIX или UNIX98), а реализация их в конкретной OS - многолетней эволюцией (для QNX, например - 22 года) - то в итоге частоту ошибок можно предполагать существенно меньше. На 90%, т.е. в 10 раз! - но это неверное утверждение, из-за кросс-эффектов элементов API суммарная вероятность растёт не линейно, а комбинаторно, и выявляться эти "закладки" будут на порядки чаще.

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин Конечно же нет. Мне это и не нужно. Мне и МС-ДОС не нужен... Ну что ж... Вполне достойный ответ ;-)... И вполне приемлемое решение... Т.е. - вы сами организуете весь требуемый API, и правильнее квалифицировать, что ваше ПО работает на голом оборудовании.

Да, "на голом"... класс Stand-Alone, если по-научному...

Первоначально опубликовано Olej Вполне допустимо (и, может, и оптимально) - но ... только для задач относительно невысокой сложности, т.е. сложности - не в смысле объёта или решаемых задач, а в смысле: алгоритмической сложности, наличия сложных вычислительных процессов (ортогональные преобразования - БПФ, вэйвлеты, АР-фильтры etc.), асинхронных событий и обменов по каналам связи и т.д.

Ну, особых ограничений относительно алгоритмической
сложности пока не выявлено... хотя повторюсь,
наша ниша - алгоритмы управления... никакой графики,
никаких БД... мы на это не претендуем... класс задач -
который пытается перекрыть МЭК 61131.3... узкие места
очевидны - протоколы по каналам связи, интеграция с
закрытыми решениями, но пока справляемся... в принципе,
если сильно прижимает отсутствие стандартных
драйверов... ничего не мешает под ОС какую-нибудь
перейти... под QNX ту же... предвзятость отсутствует...

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин У нас никто нигде не гуляет. Все это хозяйство можно и в ПЗУ затолкать... ОЗУ нужно, конечно, но не так много как ПЗУ... сотня килобайтов - за глаза... (все от приложения зависит, понятно, но все же) Естественно!!! ;-) У нас тоже не гуляет... И хорошо бы, если бы ни у кого не гуляло. ;-) Но это можно утвеждать только если ваше ПО гарантировано не содержит ошибок!

Что именно утверждать? я не понял...

Первоначально опубликовано Olej Мне когда-то обратило на себя внимание, и с тех пор я его всегда помню, утверждение всё того же Э.Дейкстра: "... в природе нет и не было ни одной программы, вообще не содержащей ошибок. Вопрос только в том, с какой частотой и при каких обстоятельствах эти (содержащиеся!) ошибки - выявятся...". В этом смысле была и страшно поучительная книжка Моулер и Форсайт "Машинные методы математических вычислений" (кажется так), в которой они показывали - насколько сложно без ошибок (не "пыонерских" ошибок, а численных) написать, к примеру, решение элементарного квадратного уравнения (3-й класс церковно-приходской школы ;-)), и к каким "смешным" результатам решения приводят эти ошибки.

Ну, эти проблемы в любой системе стоят... Что на Си, что
на АДе, что на Паскале... перепутал "закорюку"... "плюс"
с "минусом" и все... для транслятора ошибки нет, а
объект пошел вразнос...

Первоначально опубликовано Olej Отсюда уже недалеко до утверждения, которое, в общем, уже практически общепринятое, что тестирование, сколь угодно тщательное (до бесконечности! ;-)) - ни на шаг не приближает..., ни в малейшей мере не гарантирует ваше ПО от ошибок - оно может быть только "отрицательным подтверждением", в случае, когда оно их выявит. Так вот - к чему это всё? При достаточном объёме примитивных действий (например, вызовов функций, т.е. это и есть API вашей прикладной программы) у вас комбинаторно накапливается количество вот этих "скрытых мин" в программе. При реализации на голом железе - все ошибки всех API - на вашей совести. Если же общеупотребимый API (а это может быть 90% потребности программы) предоставляется OS, и этот API на непротиворечивость многолетне обкатан стандартами (тем же POSIX или UNIX98), а реализация их в конкретной OS - многолетней эволюцией (для QNX, например - 22 года) - то в итоге частоту ошибок можно предполагать существенно меньше. На 90%, т.е. в 10 раз! - но это неверное утверждение, из-за кросс-эффектов элементов API суммарная вероятность растёт не линейно, а комбинаторно, и выявляться эти "закладки" будут на порядки чаще.

Да для объекта не важно на чьей совести поломка...
а с точки зрения юриспруденции, QNX всегда прав, даже
если содержит ошибку... ;-)

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

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

Нет - это бред какой-то!

to ГОСПОДА МОДЕРАТОРЫ:
- ну нельзя, нельзя! вести разговор в форуме, который не позволяет редактировать ранее введенный ответ! а из-за одной пропущенной где-то закарлючки - сжирает весь ответ (минут на 15 работы - если при этом ещё и ДУМАТЬ привык ;-)), и демонстрирует чистую цитату длиной в 0.5 метра...

На любом "пыонэрском" форуме для флейма - стоит типовой движок, какой-нибудь "мамбо 4.0.14 -р1 форум minimalist BB 1.5M ..." - ну попросите у пыонэров!

Позвольте, Е. Зюбин, я вам (да и всем - позвольте?) по фразам отвечать буду - я боюсь этого форума!

[QUOTE=Владимир Е. Зюбин]
Что именно утверждать? я не понял...
[/QUOTE=]
Значит я плохо изложил ;-)...
А утверждал я именно то, что только если вы можете сказать, что "... в нашем ПО, которое мы N-лет назад сдали заказчику, и столько же сопровождаем - гарантировано не содержится ошибок..." - так вот, если только вы можете так сказать - тогда вы можете быть гарантированы от того, что в результате стечения исходных данных, сигналов и т.д. ваше приложение не попишет "мусором" ту область памяти, в частности, где у вас записаны константы управляющего процесса, или вектора IRQ... ("загуляет").
Но, с другой стороны, если вы можете сказать ту фразу (выше) - то я вам не поверю, что совпадает и с упоминаршимся выше утверждением Э.Дейкстры.

Первоначально опубликовано Владимир Е. Зюбин Да для объекта не важно на чьей совести поломка... а с точки зрения юриспруденции, QNX всегда прав, даже если содержит ошибку... ;-)

Без комментариев... ;-).
И юридическая сторона меня в контексте разговора не занимает.
Я только хотел сказать, что QSSL API (т.е. это POSIX API по большей части) - будет содержать на порядки меньше скрытых ошибок, чет эквивалент того же API "ручного исполнения".

Не говоря уже об том, что в некоторых случаях вы получаете API высокого уровня - тот же STL (Standard Template Library), который стандартный, а на ручную реализацию некоторого эквивалента (в конкретном случае - динамических структур) - вам понадобится несколько сот строк кода... И на 3 порядка больше число скрытых ошибок!