[Andrew2000 0]

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

Да, задал вопрос там - посмотрите...

http://qnxclub.net/modules.php?name=Forums...&t=165&start=45

[kolobok0 0]

По опыту разработок наиболее гибким и управляемым решением оказалась простейшая цикличная система, которую при наличии библиотек....

 

+1

 

подписываюсь под всем...

удивляет похожесть логики в решениях..

 

 

с уважением

(круглый)

[zltigo 1]

По опыту разработок наиболее гибким и управляемым решением оказалась простейшая цикличная система, которую при наличии библиотек....

 

подписываюсь под всем...

удивляет похожесть логики в решениях..

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

_ПОНЯТНЫМ_ инструментом оказался лом.

Ура товарищи!!! :-(

[Владимир Е. Зюбин 0]

По опыту разработок наиболее гибким и управляемым решением оказалась простейшая цикличная система, которую при наличии библиотек....

 

подписываюсь под всем...

удивляет похожесть логики в решениях..

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

_ПОНЯТНЫМ_ инструментом оказался лом.

Ура товарищи!!! :-(

 

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

 

цикличность - она "сидит" в задачах управления, и было бы глупо реализовывать ее через, пардон, зад... к слову "цикличность" я бы еще добавил слово "тактируемая" - т.е. "тактируемая цикличность",

она многие вещи ставит на свои места.

[zltigo 1]

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

Тут как-бы две разные темы развиваются - одна 'новая' - Ваша и одна вновь всплывшая

'старая'.

 

Так вот по отношению к 'старой'. НЕ ИМЕЮЩЕЙ ПРЯМОГО ОТНОШЕНИЯ К ВАШЕЙ.

 

Если говорить о нетребовательности к ресурсам, то все с точностью до наоборот на самом деле :-(

Для "простейшей циклической" все хорошо обстоит, если ресурсов немеряно (кем-то 'гарантированно' что их ВСЕГДА хватит) и не надо ИХ ДЕЛИТЬ. Как только ресурсов начинает не хватать - проблема.

Предсказуемость тоже на самом деле в 'паркетных' условиях когда кем-то 'гарантируется' достаточнрость ресурсов и поток воздействий не выходящий за зарарнее очерченные рамки. Как только возникает нештатная ситуация с точки зрения предварительных 'договоренностей' - и надо выживать и в этих условиях - проблема. Обвеска 'лома' разными рюшечками для более мягкого падения на ногу не эффективна и как минимум снижает его простоту и предсказуемость в штатных условиях. Особенно больно смотреть на людей создавших 'лом' и вдруг с детским изумлением обнаруживших, что он 'сломался' - ЭТОГО НЕ МОЖЕТ БЫТЬ это-же 'лом', он не может сломаться. Никаких конструктивных мыслей, к сожалению, часто более не присутствует :-(.

 

'Ломы' - нужный и полезный инструмент, просто их применимость в _реальной_ жизни примерно равна

соотношению реальных ломов и прочих инструментов придуманных человечеством за свою историю.

[_artem_ 0]

А что скажете об использовании SDL Z.100 в системах реального времени?

 

я им не пользовался но каждодневно пожинаю плоды этого творчества, так как поддержка кода компилированного с SDL на С очень трудна .

[Olej 0]

цикличность - она "сидит" в задачах управления, и было бы глупо реализовывать ее через, пардон, зад...

 

Абсолютно верное утверждение...

Такое же верное, как "лучше быть здоровым и богатым, чем бедным и больным"(с) ;)

Только беда в том, что все абсолютно верные утверждения - они всегда сродни тавтологии, и ничегошеньки нового не вносят :(...

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

- задачи ЦОС с блочным алгоритмом обработки: блок 1024 отсчётов с той же закономерностью, что и 1024 "локализованных переменных" PLC считывается по такту и так же точно после цикла обработки отдаётся в "выходные переменные"...

- да и задачи ЦОС с потоковой алгоритмикой ... частичное обновление так же создаёт новое пространство "входных переменных"...

- а любые задачи радио-/гидролокации?

- да любой планшетный измеритель координат, который циклически только считывает и "выводит" на матричный индикатор...

 

Т.е. правктически всё ... если мы только исключим из рассмотрения чисто "оффисную" группу программ, типа "Hello world!" или MS Office...

Хотя ... всяк, кто хоть однажды писал хоть одну оконную (важно не сколько "оконную", сколько "событийную") программку, хоть MS Windows, хоть Х UNIX, хоть Photon QNX ... - знает, что логика любой такой программы:

1. в цикле считать все зарегистрированные события...

2. и отработать на них реакцию...

3. и снова всё то же в цикле...

 

Так что разговоры о какой-то там особости PLC/АСУТП задач ... это всё та же старая песня "в пользу бедных"(с)...

 

к слову "цикличность" я бы еще добавил слово "тактируемая" - т.е. "тактируемая цикличность",

она многие вещи ставит на свои места.

 

Если вы с такой плотностью (ещё начиная с публикаций) даёте определения - то вы бы давали себе ещё труд потратить немного времени на то, чтобы объяснить вводимые определения ;) ... цены бы им не было ;).

 

Я не знаю, что такое "тактируемая цикличность" ...

Если это единовременность считывания входов / запись выходов ... то это удобно, и "достаточное" условие, но в принципе не "необходимое". Я знаю фирму (называть никого не буду, чтобы крику не было), которая многие (десятки?) внедрённых АСУТП систем реализовала на QNX штатных средствах, и, в принципе "не подозревая" о тактируемой цикличности, реализовала их асинхронно:

- цикл обработки продолжительности T...

- начинается со считанного значения переменной №1 ...

- но если к T/2 значение переменной №M измениось, то в операциях после T/2 будет использовано это значение...

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

 

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

Но важна здесь "единомоментность" (синхронность), а не сколько тактируемость...

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

Хорошо, примем синхронную схему, но будем при этом помнить, что это "перестраховка" и вопрос удобства.

 

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

 

Ещё один миф, связанный с терминами подобными "тактируемой цикличности" (мне просто приходилось его слышать в разных исполнениях ;)) состоит в том, что вот тот цикл: ... - ввод - обработка - вывод - ... и надлежит исполнять именно так: начали ввод (пассивно ожидая при том реакции медленных внешних устройств, многих и поочерёдно), когда он благополучно закончился - начнём обработку и т.д. Вот отсюда и циклы обработци многих брандовых PLC 200мс, 500мс ... , когда на соизмеримых процессорах soft PLC часто дают цифры 5-10мс.

Так этому мифу мы обязаны нескольким факторам:

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

- а ещё тем, что они свято убедили себя в том, что ничего кроме "однонитевой" MS DOS для использования здесь не нужно, и ещё ничего более "надёжного", чем a'la MS DOS и в природе придумать невозможно...

 

А в принципе, подсистемы ввода-вывода и обработки (циклической) могут быть параллельные и абсолютно независимыми:

- подсистема IO молотит себе непрерывно ввод-вывод... возможно по прерываниям или оповещениям работает с входными данными, а даже не быстрым циклическим опросом...

- а параллельная задача обработки, важно только, с периодом T (ввод) синхронизируется с подсистемой IO, монопольно захватывает (фиксирует) буфер данных, и копирует в свою область моментальный снимок текущего его состояния...

(это абсолютно известная схема в ЦОС, только автоматчикам в облом к ней было присмотреться в виду "специфики" ;)).

 

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

 

Но и это ещё не последний источник асинхронизма... В АСУТП есть ещё одна широко эксплуатиремая спекуляция:

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

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

 

Конечно, и этот слой можно выполнить в "тактируемой цикличности", да ещё и разнести его в распределённой системе на километры (я реально знаю умельцев, которые это обсуждают!), как это делается:

1. кроме M=1000, скажем переменных "внешнего мира" существуют N переменных связи с уровнем вверх (их число часто не намного, но меньше M, но, в принципе, может быть и больше: 500-1300, скажем)...

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

3. которые "тактируемо циклично" будут считываться в качестве входных уровнем PLC...

 

Хорошая такая ... "тактируемая цикличность" ;)...

[Владимир Е. Зюбин 0]

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

Тут как-бы две разные темы развиваются - одна 'новая' - Ваша и одна вновь всплывшая

'старая'.

 

Так вот по отношению к 'старой'. НЕ ИМЕЮЩЕЙ ПРЯМОГО ОТНОШЕНИЯ К ВАШЕЙ.

 

Если говорить о нетребовательности к ресурсам, то все с точностью до наоборот на самом деле :-(

Для "простейшей циклической" все хорошо обстоит, если ресурсов немеряно (кем-то 'гарантированно' что их ВСЕГДА хватит) и не надо ИХ ДЕЛИТЬ. Как только ресурсов начинает не хватать - проблема.

 

Прошу прощения, что вклинился, но цикличность имеет прямое отношение к Рефлексу. Дело в том, что Рефлекс (как язык), сам строится на базе модели гиперавтомата (простенькая моделька, модифицирующая конечный автомат к задачам управления, имеющая удобопонятный для программиста вид).

Так вот. Там прямо-таки прописана тактируемая цикличность. Уже в модели.

 

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

 

Предсказуемость тоже на самом деле в 'паркетных' условиях когда кем-то 'гарантируется' достаточнрость ресурсов и поток воздействий не выходящий за зарарнее очерченные рамки. Как только возникает нештатная ситуация с точки зрения предварительных 'договоренностей' - и надо выживать и в этих условиях - проблема.

 

Разумеется, есть некие требования к вычислительной платформе в качестве редуцированной perfect synchrony hypothesis (прошу прощения, не знаю перевод на русский): смысл именно в том, что есть ограничение на максимальную ресурсоемкость цикла. Ну, а как иначе, если Вам нужно перевести груз в пять тон, то нужно и выбирать пятитонник, а не полуторку... ну или полуторку, но четыре штуки.

 

"Лом", кстати, чем хорош, что для него проводить АПРИОРНУЮ оценку ресурсоемкости гораздо проще, чем для случая ОС (тем более закрытых).

 

И "лом" действительно можно сломать, но сделать это сложнее, чем сложные ажурные паутинки, которые лопаются просто от дуновения ветерка.

 

Прошу понять меня правильно, я не против ОС, как таковых, просто ОС - это тоже не панацея, и у них свои тонкие места. Правильная стратегия тут - трезво оценить все плюсы и минусы, и принять правильное решение.

Изменено 15 мая, 2006 пользователем Владимир Е. Зюбин

[Владимир Е. Зюбин 0]

А что скажете об использовании SDL Z.100 в системах реального времени?

 

я им не пользовался но каждодневно пожинаю плоды этого творчества, так как поддержка кода компилированного с SDL на С очень трудна .

 

Это, скорее всего, вопрос к "чистым" Си-шникам... я так понял, что Вы SDL не видите, не используете, а поддерживаете сгенерированный им код на Си. А это (такой подход) может быть (и, действительно, есть) большая проблема. А вот на SDL поддержка алгоритма может быть очень легка и естественна.

 

У Вас плохая ситуация... то же самое, что поддерживать АСМ-код, сгенерированный Си-компилятором, или тот же Си-код, сгенерированный Си++ компилятором. Есть "метауровень", уровень концепции, стратегии, который "вшит" в язык, а есть уровень реализации. И это разные вещи.

 

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

[Andrew2000 0]

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

А я думал, что такое уже давно только в заповедниках :)

 

...

- а параллельная задача обработки, важно только, с периодом T (ввод) синхронизируется с подсистемой IO, ...

(это абсолютно известная схема в ЦОС, только автоматчикам в облом к ней было присмотреться в виду "специфики" ;) ).

Ну, Вас послушать - все автоматчики дебилы. Я, все-таки, сильно удивлюсь, если мне покажут PLC, который работает не так.

Под циклом ввода и вывода везде (я так думал) понимается именно копирование _среза_ данных из/в системы ввода/вывода в основной (ПЛК) цикл.

 

Хорошая такая ... "тактируемая цикличность" ;) ...

А предложите альтернативу "циклу "долбежа" с периодом".

От передачи данных по-изменению проблем больше чем пользы (не буду утверждать, что всегда, но...).

[Владимир Е. Зюбин 0]

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

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

 

Так что разговоры о какой-то там особости PLC/АСУТП задач ... это всё та же старая песня "в пользу бедных"(с)...

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

 

Я не знаю, что такое "тактируемая цикличность" ...

Тактируемая цикличность - это привязка момента начала цикла к физическому времени.

Просто цикличность - это

for(;;) { 
  scan(); /* цикл обработки */
}

тактируемая цикличность - это

SetTimer(1сек); /* инициализация событий от таймера (раз в секунду) */
for(;;) {
  if (Timer() {             /* ожидание события от таймера */
    ResetTimer();        /* сброс события от таймера */
    scan(); /* цикл обработки */
  }
}

 

Примерно так. Вряд ли в какой ОС так забавно обрабатываются команды оператора.

 

Но важна здесь "единомоментность" (синхронность), а не сколько тактируемость...

Тоже важный момент. Хотя тут скорее не вопрос "единомоментности", а вопрос фиксации среза системы.

Чтобы всякие там побочные эффекты не вылазили, да и удобство организации обработки - немаловажный момент... на мой взгляд.

 

Ещё один миф, связанный с терминами подобными "тактируемой цикличности" (мне просто приходилось его слышать в разных исполнениях ;)) состоит в том, что вот тот цикл: ... - ввод - обработка - вывод - ... и надлежит исполнять именно так: начали ввод (пассивно ожидая при том реакции медленных внешних устройств, многих и поочерёдно), когда он благополучно закончился - начнём обработку и т.д. Вот отсюда и циклы обработци многих брандовых PLC 200мс, 500мс ... , когда на соизмеримых процессорах soft PLC часто дают цифры 5-10мс.

Не. Упомянутая тактируемая цикличность это не то.

 

А в принципе, подсистемы ввода-вывода и обработки (циклической) могут быть параллельные и абсолютно независимыми:

- подсистема IO молотит себе непрерывно ввод-вывод... возможно по прерываниям или оповещениям работает с входными данными, а даже не быстрым циклическим опросом...

- а параллельная задача обработки, важно только, с периодом T (ввод) синхронизируется с подсистемой IO, монопольно захватывает (фиксирует) буфер данных, и копирует в свою область моментальный снимок текущего его состояния...

(это абсолютно известная схема в ЦОС, только автоматчикам в облом к ней было присмотреться в виду "специфики" ;)).

Ну это вроде как бы стандартное решение. Хотя в ISaGRAFe, я слышал, есть такое дело: пока все сетевые устройства не опросит по RS-485 с места не сдвинется...

 

Но это не говорит о том, что об обработчиках прерываний в ДОСе не знают. Знают и повсеместно пользуют.

 

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

Ну, а что делать? Люди-то разные бывают.

 

Но и это ещё не последний источник асинхронизма... В АСУТП есть ещё одна широко эксплуатиремая спекуляция:

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

Но это действительно так!

 

Я имею в виду сознательное исключение из "надёжностных" аргументаций, в первую чередь, уровень взаимодействия с оператором, то что PLC-сты "через губу" называют SCADA уровнем. А это - ещё один источник серьёзной асинхронности.

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

 

Конечно, и этот слой можно выполнить в "тактируемой цикличности", да ещё и разнести его в распределённой системе на километры (я реально знаю умельцев, которые это обсуждают!), как это делается:

1. кроме M=1000, скажем переменных "внешнего мира" существуют N переменных связи с уровнем вверх (их число часто не намного, но меньше M, но, в принципе, может быть и больше: 500-1300, скажем)...

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

3. которые "тактируемо циклично" будут считываться в качестве входных уровнем PLC...

 

Хорошая такая ... "тактируемая цикличность" ;)...

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

Линий прерываний, как правило, не более десятка, ну, двух десятков. Это слабовато с точки зрения количества и сложно для работы в системах, где сигналы взаимосвязаны.

 

Обычно используется асинхронный сбор и синхронная обработка (если позволите так выразиться).

[Olej 0]

Я не знаю, что такое "тактируемая цикличность" ...

Тактируемая цикличность - это привязка момента начала цикла к физическому времени.

Просто цикличность - это

for(;;) { 
  scan(); /* цикл обработки */
}

тактируемая цикличность - это

SetTimer(1сек); /* инициализация событий от таймера (раз в секунду) */
for(;;) {
  if (Timer() {             /* ожидание события от таймера */
    ResetTimer();        /* сброс события от таймера */
    scan(); /* цикл обработки */
  }
}

 

Примерно так. Вряд ли в какой ОС так забавно обрабатываются команды оператора.

 

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

 

Только замечу, что:

- что точно по той же нарисованной вами схеме, даже перерисовывать не захотелось ;), обрабатываются потоки событий (информации) - во многих и многих областях, рядом не лежавших с АСУТП, те же задачи ЦОС с блочными алгоритмами ... да и многие другие;

- а кроме: if (Timer()){ ... - с таким же успехом может быть if(<некоторое внешнее условие>) (например в той же радиолокации: достижение диаграммой ФАР конца диаппазона и начало нового скана), часто такое управляюее событие бывает почти точно привязано к временным интервалам (хотя это и не обязательно)...

- и тогда ещё целые классы задач включаются в область рассматриваемых...

 

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

 

"Когда вас уличат в неграмотном написании, говорите: "В моём написании это всегда выглядит так""(с) Д.Хармс ;).

 

Но это не говорит о том, что об обработчиках прерываний в ДОСе не знают. Знают и повсеместно пользуют.

 

Да, но только "обрабатыватель прерываний в DOS" - это профессия сродственная сапёру ;).

 

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

Линий прерываний, как правило, не более десятка, ну, двух десятков. Это слабовато с точки зрения количества и сложно для работы в системах, где сигналы взаимосвязаны.

 

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

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

 

Но разночтения здесь наши в осоновном связаны с тем, что мы говорим о 2-х разных слоях АСУТП одновременно:

- взаимодействия "вниз" от PLC, где программный опрос + Modbus и еже с ними - вполне допустимое решение, может ничего более и не надо... но только этот слой в единственности своей присутствует только в системах "чёрный ящик", автономных + локальных, как я их разделил: класса 1...

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

 

Но об этов - в другой раз, и так много получилось ;).

[Владимир Е. Зюбин 0]

 

Я не знаю, что такое "тактируемая цикличность" ...

Тактируемая цикличность - это привязка момента начала цикла к физическому времени.

...

 

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

Я отвечал на вопрос, что такое тактируемая цикличность. Могу чуть по другому:

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

 

Можно еще уточнять и вылизывать определение, но надеюсь, что и это вполне внятно.

 

Ну, и это не вся специфика алгоритмов управления. Хотя бы даже и не во всех событийных системах такое можно встретить. А вот в цифровых управляющих - повсеместно. Начиная с уровня ПИД-регуляторов.

 

Но это не говорит о том, что об обработчиках прерываний в ДОСе не знают. Знают и повсеместно пользуют.

Да, но только "обрабатыватель прерываний в DOS" - это профессия сродственная сапёру ;).

Ну, не знаю... пока все живы... :-)))

 

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

Линий прерываний, как правило, не более десятка, ну, двух десятков. Это слабовато с точки зрения количества и сложно для работы в системах, где сигналы взаимосвязаны.

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

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

Про распределенные системы... я чего-то не очень понял, что там такого страшного. Сетевые драйверы сидят на прерываниях, да и сидят.

 

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

 

Но разночтения здесь наши в осоновном связаны с тем, что мы говорим о 2-х разных слоях АСУТП одновременно:

- взаимодействия "вниз" от PLC, где программный опрос + Modbus и еже с ними - вполне допустимое решение, может ничего более и не надо... но только этот слой в единственности своей присутствует только в системах "чёрный ящик", автономных + локальных, как я их разделил: класса 1...

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

Ну, в общем-то Вы правы, я действительно не вижу принципиальной разницы в связи по Модбасу (думаю, Вы имели ввиду все-таки RS-485 на UART а ля IBM PC) и связью по системной магистрали, или CAN (если говорить о Модбас), или Ethernet (если говорить о RS-485)... протоколы, да и протоколы. Одни чуть проще, другие чуть сложнее. В последнее время унификация идет по линии Ethernet... Для того же Modbus - это Modbus(UDP), Modbus(TCP/IP).

[zetvictory 0]

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

_ПОНЯТНЫМ_ инструментом оказался лом.

Ура товарищи!!! :-(

 

Совершенно не согласен! Вы сами для себя делаете инструмент, нравится лом? Пожалуйста! Но для резьбы по дереву я предпочитаю набор фигурных резцов.. :) если хотите аналогий. И почему-то не хочется покупать циркурярную пилу BOSH, хотя она очень производительная и пилит отличные доски кубометрами за смену.. Решается задача резать из дерева статуэтки, по одной в день...

 

Если говорить о нетребовательности к ресурсам, то все с точностью до наоборот на самом деле :-(

Для "простейшей циклической" все хорошо обстоит, если ресурсов немеряно (кем-то 'гарантированно' что их ВСЕГДА хватит) и не надо ИХ ДЕЛИТЬ. Как только ресурсов начинает не хватать - проблема.

 

С каких это пор ручное распределние ресурсов (в ассемблере, например) более затратный процесс чем любая операционная среда? Знаете сколько движений нужно сделать для организации очереди сообщений, самой примитивной? Мне кажется так могут рассуждать люди, которые ОСРВ представляют в виде черного ящика, чудесным образом "распределяющего" эти непонятные "ресурсы". Готовая ОС иногда отлично распредляет головную боль разработчиков на весь период жизни изделия.

 

Предсказуемость тоже на самом деле в 'паркетных' условиях когда кем-то 'гарантируется' достаточнрость ресурсов и поток воздействий не выходящий за зарарнее очерченные рамки. Как только возникает нештатная ситуация с точки зрения предварительных 'договоренностей' - и надо выживать и в этих условиях - проблема.

 

Зато когда с задачей не справляется готовая закрытая система всегда есть возможность развести руками и свалить всю вину за _свои_ ошибки на разработчиков ОС.. ;) Собственно говоря, любая программа на 90% это обработчик "нештатных" ситуаций. Обработаете ли вы их сами или свалите на ОС с непредсказуемым результатом -- решайте сами.

 

Еще можно смотреть на этот вопрос по-другому. Любой код содержит ошибки и чем больше кода, тем выше вероятность ошибок. ПОлучается очень простая зависимость: чем больше "абстракций" и "уровней" не относящихся к решаемой задаче вы используете, тем больше рискуете сделать ошибок. Конечно, если в проекте 15 пар глаз и вагон времени на отладку, имеете право рисовать облака и кирпичи, но чаще всего ограничены не ресурсы вычислительные, а ресурсы людские.

 

Надеюсь, понятно излагаю? Предложение простое: примените процессор на 10 долл дороже, решите предметную задачус НУЛЯ и обойдетесь двумя программистами вместо 15 + покупка чужого кода, который решает разные задачи в общем виде.

 

Приведу пример из практики, когда пришлось написать дизассемблер для Intel 196NP и декомпилировать готовую библиотеку плавающей точки, чтобы исправить ошибки в вычислении функции квадратного корня и обработчике перполнений. Компилятор был куплен официально, но обращение в BSO Tasking так и осталось без внятного ответа, а сроки проекта поджимали... "вот тебе бабушка и Юрьев день!" :)

Изменено 19 мая, 2006 пользователем Vlad-12

[Andrew2000 0]

...пришлось написать дизассемблер для Intel 196NP и декомпилировать готовую библиотеку плавающей точки, ..., но обращение в BSO Tasking так и осталось без внятного ответа, а сроки проекта поджимали...

:) )) А я думал я один такой извращенец - занимался тем же, тока Tasking для Infineon Tricore - исправлял CPU_BUG в кишках float библиотеки. Но, слава богу, остальные библиотеки с исходниками.

 

Так что в тему можно добавить - когда не нужна ОС - когда ее исходники не доступны :)