PSV100 писал(а):
нет конкретики насчёт что есть "команда на запуск" и как она появляется. По-видимому, в модели исполнителя, всё-таки, предполагается не истинная параллельность. В противном случае, скорее всего, не было бы прямого доступа к разделяемым объектам/переменным и явно (согласно императивным принципам да ещё с необходимостью визуальных "метафор") задавались бы средства синхронизации/защитные секции и т.п.
А вдруг там compare&swap?
Без проблем можно читать-обновлять глобальные переменные даже когда процессы выполняются параллельно.
Если вы говорите о модели памяти, это тоже хорошо, т.к. это вопрос решаемый.
Вон, например, Node.JS живёт со своим одним потоком и ничего.
Я, кстати, да, предлагаю, что одна Д-схема должна обрабатываться не более чем одним потоком.
Нужно ли нагружать Д-схемы синхронизационными примитивами -- вопрос. Мне, честно говоря, пока не интересно. Я не собираюсь писать существенно многопоточный код на Д-схемах, поэтому мне достаточно и семантики "исполнителя с одним потоком и кооперативной многозадачности".
PSV100 писал(а):
Пусть флаг "есть пуск" (или необходимые объекты, если это условие есть аля функция над чем-то)
Предполагалось, что флаг "есть пуск" устанавливается исходя из значений логических входов контроллера.
Иными словами, "ожидаемый" механизм работы контроллера следующий.
1) Читаем входы. (как раз тут значение физически замкнутой или разомкнутой кнопки "пуск" превращается во флаг "есть пуск")
2) Выполняем каждую (активную) Д-схему до следующего флажка (ХЗ в каком порядке, но, допустим, согласно приоритетам, которые поставил разработчик Д-схем)
3) Записываем значения выходов (тут флаг "нужен запуск насоса" превращается в реальное замыкание реле)
4) goto 1
PSV100 писал(а):
пусть в алгоритме "остановить все насосы" (икона 11) возможна коррекция этого флага
В "останове всех насосов" идёт управление другими флагами (там идёт управление флагами, которые в конечном итоге будут замыкать или размыкать реле). Но не суть.
PSV100 писал(а):
Насчёт второго цикла-ожидания (иконы 8-9). После "запустить запуск насоса" (икона 7, по-видимому, лишь устанавливающая атрибут активности для соответствующего процесса) в "вопросе" (икона 9) осуществляется доступ к ещё не изменённому значению флага, т.к. ещё не было исполнения смежных процессов. И тогда возникает очевидная лишняя проверка (перед уходом в икону "период").
Да, всё так. Лишняя проверка. И? Какие-то проблемы с этим?
После "7. запустить насос" можно было бы добавить паузу со словами "а всё равно делать на текущем такте нам больше нечего, можно вернуть управление". Но это больше религиозный вопрос, т.к. без этой "лишней" паузы видно, что мы уходим на ожидание.
PSV100 писал(а):
При сценарии выше даже в этом примерчике приглядность в виде применения лишь одной конструкции "цикл-ждать" для актов ожидания возникает за счёт лишних операций (которые в общем случае могут быть не простыми), которыми, по-видимому, якобы можно пренебречь,
Здесь можно пренебречь.
Но, если нужна пауза ДО проверки условия, то можно воткнуть эту паузу прямо перед условием (ну как сделали вы, чем породили бурю моих комментариев).
Да, где-то пауза "по ходу" может быть вполне обоснована. Но в обсуждаемой задаче пауза будет лишь мешать.
Вариации "с ведущим синхронизатором" это совсем другая песня. И этот ящик Пандоры я бы не хотел открывать. Сейчас.
Скажу так: у "паузы 0 сек" вполне понятная семантика. Она работает РОВНО так же, как и пауза 0 сек на обратной стрелке.
Поэтому особого вреда от такой конструкции нет.
"С ведущим синхронизатором" же море непонятностей. Можно ли прицепить "ведущий синхронизатор" к группе действий? А куда переходит управление, если "превышена длительность ожидания"? И так далее. В общем, в той ветке обсудили, и вариаций пока нет.
Да блин, мне, может, и интересно было бы придумать нотацию для "таймера с ожиданием и обработкой таймаута", но пока я склоняюсь к тому, что для таких случаев нужно создавать побочные Д-схемы, которые только и занимаются тем, что ждут таймаут, и полностью останавливают-перезапускают подконтрольные схемы. В таком случае особая нотация "с ведущим синхронизатором" не особо-то и нужна.
PSV100 писал(а):
Цикл "с синхронизатором", фактически, с теми же "трудозатратами"
Нет. "с синхронизатором", может, для каких-то задач и будет понятнее, но простая пауза в 146 раз понятнее. По крайней мере здесь.
Например: вы проанализировали алгоритм, и нашли, что там лишний раз проверяется условие. И это хорошо. Т.е. вы смогли это понять.
А как работает "с синхронизатором"? Синхронизатор выполняется ДО или после проверки условия?
С синхронизатором сложнее понять "у нас интервал запуска в 1 минуту" или это "паузы размером в 1 минуту, а интервал как получится". И так далее. В общем, простая пауза гораздо более топорный инструмент, который, тем не менее, позволяет строить адекватные алгоритмы, которые поймёт полный профан.
PSV100 писал(а):
Подобный анализ работы "коллег"-процессов неизбежен в общем случае (вне зависимости от этого примера).
Как у нас там тема называется? Зачем же вы тут корректно критикуете ДРАКОН? Разумеется, в ДРАКОНе нет средств для анализа состояния процессов. И нет средств для того, чтобы указать или понять сколько "копий запуска насоса" активно. Грубо говоря, непонятно работает ли схема в единственном экземпляре, или есть несколько схем, работающих по одному алгоритму.
PSV100 писал(а):
Остальные варианты разбрасывания "пауз" были на картинке ранее с вариантами схемы -- не слаще...
Скажем так: для конкретной задачи весьма сладко. С точностью до того, что непонятно "запуск насоса" это один экземпляр или несколько и т.п.
Но для конкретной задачи -- более чем норм, и никаких "синхронизаторов" не нужно.