Многопоточность в ADAM 5510( или прерывания)

Первоначально опубликовано Максим Ананских 3. Многозадачность нынешних Windows берет свое начало в UNIX. В свое время был и другой подход. Я думаю, многие помнят висюче-падучую Win'95... И понимают, чем чревато взаимодействие задач в контроллере.

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

Первоначально опубликовано Максим Ананских 4. Я не вполне понял определение "одноцикловая многозадачность". В современных контроллерах можно реализовать как вытесняющую, так и невытесняющую многозадачность. Вопрос, стоит ли это делать? В случае вытесняющей многозадачности сразу возникает вопрос с синхронизацией. А затем еще и с отладкой полученной программы.

Опять же вопросы синхронизации не связаны с механизмом вытеснения, они возникают в любой многозадачной среде на самом деле. Это просто следствие разной длительности взаимодействующих процессов а не следствие вытеснения. Вообще вытеснение проявляеться в строго определенных случаях, когда менеджер ресурсов определяет процессу статус "голодающего" В сбалансированной системе (среднее время простоя 35% и выше) вытеснение никак себя особо не проявляет.
Собственно основная причина, по которой опреционные системы Windows не могут считаться системами реального времени вовсе не в механизме вытеснения а в архитектуре, при котрой время выполнения определяеться процессами протекающими по прерываниям, которые в конечном итоге лишь позволяют выполняться пользовательскому и системному коду в отсутствие программных и аппартных прерывании... Это и делает неопределенным время выполнения вашей задачи. Так как в каждый момент времени процент свободного процессрного времени для системного и пользовательского кода величина неизвестная.

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

Ну, Windows'9x до этого определения было явно далеко. Вот WinNT/2K/XP - другое дело.

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

Спасибо за умный и развернутый комментарий. Но здесь есть с чем поспорить. Во-первых, вопросы синхронизации между процессами возникают тогда, когда процессы выполняются асинхронно. При кооперативной многозадачности, мы явно отдаем процессорное время другим задачам, завершив какую-то часть процесса. Проблем с синхронизацией тут не возникает - мы твердо знаем, что все ресурсы, свободные на момент передачи управления процессу, остаются свободными. И такой подход гораздо ближе к понятию системы реального времени. Трудности начинаются, когда процесс может быть вытеснен другим процессом. Для этого вытесняющему процессу достаточно иметь более высокий приоритет. И что делать, если ресурс, нужный высокоприоритетному процессу, занят низкоприоритетным? Приходится как-то сигнализировать ему о том, что ресурс занят.
Процессы, протекающие по прерываниям, есть всегда. И сколько они занимают процессорного времени, вообще говоря, лежит на совести разработчика ОС (или, в нашем случае, ПЛК). Основную проблему Windows все знают - она ведет себя недетерминированно (мы не знаем, а вдруг ей понадобится свопиться в данный момент?). Ну а как поведет себя тот или иной ПЛК? Остается лишь надеяться, что лучше чем Windows, поскольку они гораздо проще и используют обычно другие ОС (или вообще не используют).

Первоначально опубликовано Dismay просто в некоторых вариантах он заложен саму модель исполнения.

Остается только согласиться с этим.

Первоначально опубликовано sanwork Тему многозадачности обсуждать можно долго, уж очень она бъемлющая. Но можно когда-то и остановиться. В конце-концов, вопрос стоит так - использовать её в промышленных контроллерах или нет ? Windows-овую - НЕТ !

А как же глюкавая но WinCE или же какой-нибудь Windows с RTX, в конце-концов embedded? Понятное дело все будет зависеть от задачи но так категорично я бы не заявлял.

Первоначально опубликовано sanwork Попадая в лапы Windows программа становится полностью ей подвластна.

Если программа будет полностью не подвластна ОС , то это уже будет анархия!

Первоначально опубликовано sanwork И еще ключевой момент - насчет динамической памяти. Если в контроллере есть средства коммуникации (а щас они везде), будь то OPC, MODBUS, или хоть RS485, то это прямо означает наличие функций динамической памяти !

Это смотря какой контроллер и какая среда разработки используется. Так что не факт.

Первоначально опубликовано sanwork Тему многозадачности обсуждать можно долго, уж очень она бъемлющая. Но можно когда-то и остановиться. В конце-концов, вопрос стоит так - использовать её в промышленных контроллерах или нет ?

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

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

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

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

Когда Вы говорите о применении в контроллерах многозадачности "от Windows", не вполне понятно, что Вы имеете в виду. Это ядро ПЛК, работающее под управлением ОС Windows (какое?), или это прикладная программа, использующая Windows API (какие средства разработки используются?)?

И тут же Вы сами себе противоречите - говорите, что не стоит применять в контроллерах Windows (в качестве чего?), и тут же отчитываетесь об успешном применении XP Embedded (применении для каких целей?).

В моем понимании, ПЛК (PLC) - это то, что описано в IEC 61131. То есть, это некая среда (контроллер), обладающая ресурсами, в которой выполняются задачи, вызывающие программы, написанные на языках МЭК. Как видите, такой подход вполне допускает реализацию многозадачности. Однако внутренняя реализация этой среды скрыта для прикладного программиста. Она может использовать, в том числе, и Windows (примеры: CoDeSys SP RTE, Siemens WinAC). Сейчас очень многие ПЛК строятся на базе ОС Linux.

Под контроллером я понимаю любое микропроцессорное устройство, служащее для непосредственного управления технологическим объектом. Это не обязательно может быть ПЛК, но и так называемый PAC (Programmable Automation Controller). Грубо говоря, это устройства, не соответствующие IEC 61131, и программируемые другими методами (например, на языке C).

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