Основная мысль тут (как я понял): рост затрат на организацию согласованной работы коллектива.
Проблема в том, что затраты растут нелинейно, экспоненциально.
По аналогии с параллельным программированием (многопроцессорным):
Два программиста решают одну и туже задачу не в два раза быстрее, а в полтора, три - в 1,7 раз, и т.д., а потом с ростом числа программистов наступает насыщение... а потом - увеличение времени на разработку. Т.е. наиболее эффективные проекты (с точки зрения КПД) - это минимальные по числу участников (если программисты - одинаковые с точки зрения квалификации).

А в простых задачах будет наблюдаться рост времени сразу же, при появлении уже второго программиста.

Что же касается ОС, то, разумеется, ОС может существенно сократить сроки, и предоставляет всякие полезные штуки в виде кучи драйверов, стеков протоколов, среды разработки, полезных утилит и т.д. и т.п.

Другое дело, что ОС типа QNX от версии к версии мигрирует в сторону ОС типа Виндоз. Но и при этом ОС типа Виндоз становится все более и более надежными.

Небольшая революция (ну или большая) грядет (и уже началась) в связи с переходом на многоядерные архитектуры... коренным образом меняются подходы... Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности, по сути же - это преимущество легко теряется. Тем более, что имеющиеся шедулеры-планировщики не особо и подходят для таких архитектур (алгоритмически), и их все равно надо переписывать.

мы тоже обычно пишем на С:
и логику работы проще отлаживать на РС, чем на целевом процессоре (можно организовать вывод в файл, на графики и т.п.) и все остальные преимущества ЯВУ.
а дальше случаи из практики:
1. Кривой компилятор (holtek) - генерит код просто огромных размеров, при этом не умеет использовать особенности процессора. пришлось писать на асме работу с флагами, прерываниями и т.п. (не входило приложение в 8 Кб)
2. В некоторых компиляторах не предусмотрена обработка вложенных прерываний (контекст сохраняется в оверлее).
3. Обработка быстрых прерываний в PIC.
4. Монитор событий с переключением банков РОН в F2MC

в общем, это разговор об одном и том же, к тому же не по теме ветки.

По теме.
Любопытно, что отмечается несколько подходов:
1. Использование автоматной логики.
2. Использование обработки событий.

которые в свою очередь делятся на:
1.1. Реализация автоматов, непосредственно в суперцикле.
1.2. Использование ОС и языка технологического программирования для описания тех же автоматов в суперцикле.

2.1. привязывание обработчиков к монитору или к прерываниям
2.2. привязывание обработчиков срествами ОС к тем же прерываниям.

при этом, споры идут между 1.1 и 1.2 и между 2.1 и 2.2, а это не так интересно, как противопоставление 1 и 2. Т.е. есть ОС, нет ОС - это ерунда. Важно как выбрать модель представления на этапе проектирования, чтобы она сама себя не погребла при развитии системы.

В частности, меня интересует, как, например, olej планировал свою систему управления при обработке событий.

С удовольствием, ... но я не совсем понял что именно вы имеете в виду?
Много о том (если я правильно предполагаю) обсуждалось (-ется) здесь:
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=268
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=279
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=276
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=277
Кроме того, предполагаю, это будет уже совсем другое обсуждение, слабо относящееся к этой теме .

Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры. Т.е. они не видят разницы между автоматной логикой и обработкой событий.



По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,
а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...

Ну, а вообще я присоединяюсь к вопросу, т.к. у меня до сих пор где-то внутри живет стойкое убеждение, что средствами ОС решаются немного не те задачи, что решаются в промавтоматизации.
Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

"Слухи сильно преувеличены"(с) ...
"Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности..." - это неверное утверждение, которое должно звучать так: "Архитектурно, ОС типа QNX имеют некое преимущество за счет микроядерности и обмена сообщениями..." - что далеко не то, что было раньше. Именно поэтому: а). микроядерные архитектуры (не только QNX) очень легко вписываются в SMP б). SMP именно в QNX давно и успешно реализовано, и очень эффективно, по оценкам выше, чем в любом другом коммерческом продукте.



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

И наоборот, кстати. :-)

Для разрешения этого конфликта неплохо было бы определится с понятиями, что такое автоматная логика, а что такое обработка событий.
Простейший пример: Оконная процедура win32 - классический автомат без памяти, в цикле обрабатывающий события окна.
Да любая GUI это автоматная логика обработки событий. Так что объясните пожалуйста что же все таки имелось в виду под этой класификацией.

Может быть речь идет о разнице между циклической обработкой и условно событийной обработкой?
В стиле
for (;;)
{
if(Condition) DoSomthing();
if(AnotherCondition) DoSomthingElse();
}
или
for (;;)
{
SleepUntil(Condition);
DoSomthing();
}
for (;;)
{
SleepUntil(AnotherCondition);
DoSomthingElse();
}
в паралельных потоках.

Я говорю условной, потому что в конечном счете где то for есть в обеих моделях :-)
Только в первой распределение ресурсов вычислительной системы ложится на плечи разработчика, и он должен распределять вычислительный ресурс между своими задачами, а также следить за тем, чтобы выполнение менее важных задач не прпятсвовало выполнению более важных, а во втором случае средсвами ОС (или своими силами если хотите) эта задача отдается подсистеме планирования ОС.

Сообщение отредактировал Goroshko Egor - May 30 2006, 13:15

А чего ж там совершенно непонятного?
Я мог бы назвать вам фирму (не стану я это делать только потому, что не хочу делать никому ни рекламу, ни антирекламу - кто как поймёт), которая уже лет 10 (более) очень успешно внедряет системы диспетчерской централизации на ж/д, но "лабает" это в голой ОС QNX, и делают это очень успешно, и это очень дорогие системы и отрасль, а соответственно - и сложные (существенно сложнее традиционной конвейерной автоматизации).
Это не значит, что так нужно делать, но, как видите, так можно делать.
И всё там будет делаться точно так, как в МЭК реализациях: цикличность опроса, периодичность обработки и т.д. Ведь МЭК со своим runtime - это ничего более чем надстройка, чем голая ОС вам не такая же надстройка, что так "совершенно непонятна": надстройте над этой надстройкой ещё одну - CoDeSys ... похоже?

логично... на мой взгляд - "автоматная логика" (событийный полиморфизм) - это идеальный подход для обработки событий, когда их много.



непонятно, в чем тут разница. Т.к. SleepUntilCondition в конечном случае вырождается в if(Condition), разве что где-то в недрах планировщика ОС...

Тут можно говорить об отличиях между многозадачным логическим параллелизмом (ОС) и многопоточным логическим параллелизмом ("лом", round-robin, Stand-alone, кооперативная многопоточность на уровне задачи)... но ни к автоматам, ни к обработке событий это особого отношения не имеет.



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




Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?
для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...

Хорошо, пусть вместо "модульности" будет "микроядерность"... нет возражений.



Он играет как умеет, да и пианино расстроено... Увы, но априорный анализ динамического поведения системы в средах с многозадачной организацией логического параллелизма весьма затруднен. Вот люди и прикидывают шансы...

Ну так вы тогда так и говорите: "стратегия реализации управляющих алгоритмов программирую на Си как придется - совершенно непонятна." И это уже совсем другой разговор, о том, какие средства проектирования подходят, а какие не подходят. Кому то, как я назвал - и С очень даже подходит, кто-то над С сделает технологическую надстройку, как например в системе ДЦ ЮГ, которая более 20 лет успешно шаг за шагом внедряется, кто-то сделает другую надстройку - CoDeSys или ISaGRAF и МЭК, кто-то - Рефлекс . Средства изображения целевой алгоритмики ну никакого касательства не имеют к вопросам параллелизмов, диспетчирования, управления ресурсами и всем другим вещам, которые относятся к функциональности ОС или отсутствия таковой.



Пусть и для наличия стека TCP/IP. Вы когда-нибудь реально писали что-либо в программировании сетевых обменов? Это на словах "слова.. слова... слова..." - а реально нет такого "стека TCP/IP", а есть только стек TCP/IP в конкретной его реализации: BSD, Windows, ... и каждый включает в себя только какое-то подмножество возможностей из описанных в 3000 RFCs.
И при чём здесь упоминание QNX к месту или не к месту? если мы говорим вообще о принципиальном использовании или не- ОС вообще, всякой.
Надёжность? да, пусть надёжность - этого тоже может быть достаточно: я под QNX совершенно спокойно предположу работу (программ) на одном процессоре: PLC, сервера тэгов, SCADA системы с её HMI компонентой + ... в качестве просто параллельных задач, не сомневаясь, что они не завалят друг-друга и за несколько лет невыключаемого режима... чего даже под Linux/FreeBSD/etc. не представлю, под ... "другими ОС" - так это "во сне приснится - не проснёшься"(с).
Вот 1 из "по-быстрому" (не самых свежих) попавшихся переводов, который хоть отчасти объясняет почему так происходит:
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html
Вот такая проза, хотя она, конечно, к высокой девственности теории касательства и не имеет... как и к предмету этого разговора , поскольку не о QNX мы говорим, а обо всём сразу - говорить не стоит.



Во-первых, для того, чтобы "прикидывать шансы" нужно хорошо понимать предмет того, что ты прикидываешь... с QNX, как частность, особая история, с ним достаточно многие "работали", но из всех работающих, может, только 10:1 дали труд себе разобраться что там происходит, и чем это отличается от ... "других ОС" ... некоторых, а для того, чтобы это понимать есть только единственнный путь, к сожалению: писать, писать и писать "ручками", и анализировать что из этого получается, и удивляться, что получается не совсем так, как предполагается...

Во-вторых, и с "априорным анализом динамического поведения системы в средах с многозадачной организацией логического параллелизма" не всё так запущено, давно и много сделано "в эту сторону", вот хотя бы только малые намёки:
http://qnxclub.net/files/articles/rta/rta.doc
http://qnxclub.net/files/articles/rms/rms.doc
- но и это не так обязательно, если хорошо представлять, что и как там происходит "на деле", а не на уровне хвалебных описаний производителей каждой из ОС как раз на уровне "слова.. слова... слова...".

Жалко, что Вы опять на success-story разговор переводите. А вопрос о стратегии. И о месте ОС в этой стратегии. Я вот на Рефлексе программирую, так вообще об ОС не думаю... мне легко и приятно, голова свободна для решения конкретных целевых задач, что под Виндовозом, что под любой другой ОС, или без оной...



Да не нужно все это. Это системный уровень. Когда я пишу на Рефлексе, мне что TCP/IP, что UDP/IP,
что USB, что RS-485... голова занята алгоритмом, а не протоколами обмена. А сетевые протоколы я реализовывал, и что такое сокет знаю.



Значит, Надежность. Спасибо. Понятно. Не понятно, правда, почему у QNX надежность выше, чем у Виндовза или Линукса, ну да ладно. Лично на мой взгляд, QNX становится все более громоздкой ОС и движется в сторону Виндовз, а Виндовз становится все более надежной ОС.


У меня лично нет времени на реинжиниринг ОС. Ну а вообще, вполне логично ожидать, что эту информацию должен предоставить производитель.


Не сомневаюсь, что люди над этим вопросом работают, пишут докторские и т.д. Кстати, судя по статьям,
вопросы рассматриваются малоинтересные, типа успеет-не успеет, т.е. вопросы функционирования в условиях ограниченных ресурсов. Честно признаться, на практике вообще об этом не задумывался... вернее, задумался один раз, посмотрел на вычислительные ресурсы - запасов >92%, т.е. порядок с лишним... на 300 МГц "Пне"... не будет хватать поставлю 3 гигагерца, не будет хватать, разобью задачу на 10 процессоров... и особых теорем для этого не нужно...

теоремы, они хороши, но не для массового пользователя. Там где теоремы, там квалификация высокая, учиться надо, извилину напрягать, а главное время тратить... Так что теорема, она, как правило, указывает на то, что с практикой связи нет.... с массовой практикой.

Ну и вообще, человеку надо создать алгоритм, а ему говорят: Нет! сначала стек протоколов изучи, покопайся в ОС, создай проблемно-ориентированную библиотеку классов и докажи десять теорем по алгоритмам планирования. ;-) Плохой какой-то подход.
Это несерьезно.

Сообщение отредактировал Владимир Е. Зюбин - May 31 2006, 10:44

Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.
В случае микроядра - упавший драйвер может быть перезапущен, по крону, например.

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

Я согласен, что теоретически устойчивость ПО при модульном (микроядерном) построении системы выше. Но как это измерить в числах, я не понимаю. Ну, хорошо, есть статистика. Но по статистике, последние версии ОС Виндоуз весьма устойчиво работают, на уровне архитектуры там тоже очень грамотные решения. Есть и специализированные модели ОС, типа CE.

Да похоже у вас довольно простые и не замысловатые задачи :-)
Мы вот в своем проекте вторую неделю байтики считаем и по третьему проходу вычищаем все лишнее. И каждую лишнюю милисекунду выжимаем из алгоритмов. А целевая платформа - 4 процессорный Intel с 4 Гб памяти. А все равно считаем, оптимизируем, переписываем так что бы в кеш вовремя попадало все что надо... Что бы памяти лишней не жрало. Насчет производительности аппаратуры - это миф. По тому что когда вы говорите заказчику - да тут надо проц посильнее поставить, памяти побольше, а он считает, считает... И говорит, знаете, дорогие мои, вы конечно умные ребята, но вон у них работате на более дешевой аппаратуре и куплю я систему наверно все таки у них.
Наше отношение к аппаратным ресурсам вызвано в первую очеред практически полным отсутсвием конкуренции. Там где конкуренция есть - за ресурсы борются изо всех сил.

Поэтому там где конкуренция есть и теоремы изучают (или не изучают и прогорают).

Сообщение отредактировал Goroshko Egor - May 31 2006, 12:16

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



Меня мало вдохновляет "фирменная" статистика: "посмотрите насколько мы круты"...
Я просто знаю (могу перечислить: в какой стране, где и как, в каком проекте):
- QNX системы в необслуживаемом режиме работают не выключаясь а). 14 лет б). 20 лет ... - выходят из строя потому, что вентиляторы за это время насосали в корпус пыли столько, что там стал сплошной "валенок", и все кулера стали;
- Linux в качестве роутера достаточно надёжно себя показывает 3-5-7 лет...
- Windows (из вот "весьма устойчиво работающих" суффиксов) - период полураспада 3-4 мес. - вот только вчера в моей фирме выяснилось, что в уже поставленных crytical mission отрасли SCADA станции умирают, в среднем, за 21 день ... это не мои проекты, но я их предупреждал ... но "нет пророка в своём отечестве"(с) - теперь они по объектам будут ездить на 20-й день ... "накануне"?