Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Никто так и не смог обойтись. S>>Теорема Бома-Якопини: можно без goto. S>>Пример: общий цикл с if-ами, в которых идет проверка переменной go_label.
V>Это и есть эмуляция goto. Мы в любом случае пропускаем код до нужной метки, только делаем это не за один такт, а за много.
V>Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается. V>Даже выражения под case так и названы — метки.
Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).
Здравствуйте, samius, Вы писали:
V>>Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается. V>>Даже выражения под case так и названы — метки.
S>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).
S>Так без чего надо было обойтись?
См. на что я отвечал. Обойтись надо без пересечения стрелок-переходов. ИМХО, такие пересечения возможны только на goto. Ну или его равнозначной эмуляции (то бишь за счет некоторой избыточности, касающейся механики эмуляции goto, но не касающейся алгоритма).
Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
=======================
И да, всякие парсеропостроители используют goto в генеренном коде аж бегом. Именно как самый локаничный способ выразить схемы, наподобие нарисованных.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).
S>>Так без чего надо было обойтись?
V>См. на что я отвечал. Обойтись надо без пересечения стрелок-переходов. ИМХО, такие пересечения возможны только на goto. Ну или его равнозначной эмуляции (то бишь за счет некоторой избыточности, касающейся механики эмуляции goto, но не касающейся алгоритма).
Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto. В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.
V>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
V>======================= V>И да, всякие парсеропостроители используют goto в генеренном коде аж бегом. Именно как самый локаничный способ выразить схемы, наподобие нарисованных.
дык мы же не об этом. Мы о том что на оберонкоре 5 страниц обсуждений как избавиться от пересечений. Конечно, я их не читал.
Здравствуйте, samius, Вы писали:
S>>>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).
S>>>Так без чего надо было обойтись?
V>>См. на что я отвечал. Обойтись надо без пересечения стрелок-переходов. ИМХО, такие пересечения возможны только на goto. Ну или его равнозначной эмуляции (то бишь за счет некоторой избыточности, касающейся механики эмуляции goto, но не касающейся алгоритма). S>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.
Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок. В исходном алгоритме этого цикла нет, ес-но, он искуственный, как искуственнен цикл работы центрального процессора с т.з. исполняемого им ПО. Просто мы все стрелки направили в одно место и из этого места сделали goto/диспетчеризацию на нужную ветку, согласно текущего состояния (аналога кода команды).
Это лишь один из способов эмуляции ДКА, когда мы состояние автомата переносим в данные. То бишь осуществляется преобразование кода в данные и затем по этим данным работает дополнительный софтовый уровень — интерпретатор этих данных. По отношению к варианту на железе это уже будет целых два уровня программного исполнения, а не один. Я уже молчу о том, что целевой алгоритм на этом уровне теряется полностью и привести в соответствие одно к другому можно только через дополнительные артефакты — графы переходов автомата и полученной из него таблицы переходов... Почему бы такой артефакт не "нарисовать" прямо в программе?
S>В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.
Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя.
Попробую объяснить суть всех твоих приемов. (Все предложенные тобой и мной приёмы абсолютно идентичны, даже если упоминались разные операторы языка для их воплощения.)
Как работает центральный процесор? Он выполняет некий код. Сам цикл работы центрального процессора не содержит никаких пересечений, ес-но, там идет диспетчеризация по коду команд, которую можно отобразить в блок-схемах без каких-либо пересечений. Однако же, этот процессор способен исполнять алгоритмы, в которых эти пересечения есть (см блок-сцему исходного алгоритма). Ты предлагаешь избавляться от пересечений точно по такому же принципу — превращая код этого агоритма (его поток исполнения) в данные, кодируя разные точки алгоритма через искуственно-вводимые состояния автомата. То бишь имеем дополнительный софтовый уровень: свою "систему команд", свой интерпретатор и на этом уровне получаем аналог центрального процессора, только эмулируемый. И на этом уровне пересечений уже нет, ес-но, как нет в алгоритме работы центрального процессора.
Мои поздравления, цель достигнута!
Но целевой автоматически алгоритм переползает на один уровень вверх, и на этом уровне все пересечения стрелок останутся. См. упомянутый артефакт — граф переходов. Он никуда не делся. Ты опять можешь "закинуть невод", т.е. опять попытаться избавиться от пересечений на этом новом уровне... и опять получишь тот же самый эффект, потому что сделаешь это через очередной слой интерпретации данных и т.д. до бесконечности.
В чистом виде описанный подход не факт что можно распознать, т.к. народ подвергает такому преобразованию довольно-таки "локальные" места (чаще всего интуитивно, не отдавая себе отчета, что при этом происходит). Но суть этих преобразований надо понимать, чтобы быстро "воткнуть" в целевой алгоритм, глядя на цепочку ветвлений по исскуственно-введенным флагам в чужом коде. Мне порой подобный код-ревью доставляет массу фана, надо признать. )))
V>>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
S>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
Суть этого преобразования я показал. И оно тривиально, это преобразование. (Для тех, кто имеет представление о принципах работы процессоров, т.е. фактически для всех коллег. )
V>>И да, всякие парсеропостроители используют goto в генеренном коде аж бегом. Именно как самый локаничный способ выразить схемы, наподобие нарисованных. S>дык мы же не об этом. Мы о том что на оберонкоре 5 страниц обсуждений как избавиться от пересечений. Конечно, я их не читал.
Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))
V>>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
S>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
Ключевой момент: не тривиально, и конечный результат может оказаться кашей по сравнению с вариантом с пересечениями.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.
V>Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок.
Не пересечения, а схождения. Иначе придется признать что в исходной схеме кроме явных пересечений стрелок есть еще T-образные пересечения на местах схождения стрелок на входе в блок (если считать что вход в блок лишь один). Любой цикл образует такое пересечение. Я думал что обсуждаются другие пересечения, именно X-образные а не T-образные.
V>В исходном алгоритме этого цикла нет, ес-но, он искуственный, как искуственнен цикл работы центрального процессора с т.з. исполняемого им ПО. Просто мы все стрелки направили в одно место и из этого места сделали goto/диспетчеризацию на нужную ветку, согласно текущего состояния (аналога кода команды).
Ага, вот так же стрелки направлены в одно место перед каждым блоком
V>Это лишь один из способов эмуляции ДКА, когда мы состояние автомата переносим в данные. То бишь осуществляется преобразование кода в данные и затем по этим данным работает дополнительный софтовый уровень — интерпретатор этих данных. По отношению к варианту на железе это уже будет целых два уровня программного исполнения, а не один. Я уже молчу о том, что целевой алгоритм на этом уровне теряется полностью и привести в соответствие одно к другому можно только через дополнительные артефакты — графы переходов автомата и полученной из него таблицы переходов... Почему бы такой артефакт не "нарисовать" прямо в программе?
Почему — это другой вопрос. Мы обсуждаем не его.
S>>В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.
V>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя.
Как ни крути, от T-образных не избавиться.
V>Попробую объяснить суть всех твоих приемов. (Все предложенные тобой и мной приёмы абсолютно идентичны, даже если упоминались разные операторы языка для их воплощения.)
V>Как работает центральный процесор? Он выполняет некий код. Сам цикл работы центрального процессора не содержит никаких пересечений, ес-но, там идет диспетчеризация по коду команд, которую можно отобразить в блок-схемах без каких-либо пересечений. Однако же, этот процессор способен исполнять алгоритмы, в которых эти пересечения есть (см блок-сцему исходного алгоритма). Ты предлагаешь избавляться от пересечений точно по такому же принципу — превращая код этого агоритма (его поток исполнения) в данные, кодируя разные точки алгоритма через искуственно-вводимые состояния автомата. То бишь имеем дополнительный софтовый уровень: свою "систему команд", свой интерпретатор и на этом уровне получаем аналог центрального процессора, только эмулируемый. И на этом уровне пересечений уже нет, ес-но, как нет в алгоритме работы центрального процессора.
Опять таки, причем тут уровень процессора?!?!? Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили. В структурном программировании мы оперируем в терминах языка, на котором пишем.
V>Мои поздравления, цель достигнута!
V>Но целевой автоматически алгоритм переползает на один уровень вверх, и на этом уровне все пересечения стрелок останутся. См. упомянутый артефакт — граф переходов. Он никуда не делся. Ты опять можешь "закинуть невод", т.е. опять попытаться избавиться от пересечений на этом новом уровне... и опять получишь тот же самый эффект, потому что сделаешь это через очередной слой интерпретации данных и т.д. до бесконечности.
От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.
V>В чистом виде описанный подход не факт что можно распознать, т.к. народ подвергает такому преобразованию довольно-таки "локальные" места (чаще всего интуитивно, не отдавая себе отчета, что при этом происходит). Но суть этих преобразований надо понимать, чтобы быстро "воткнуть" в целевой алгоритм, глядя на цепочку ветвлений по исскуственно-введенным флагам в чужом коде. Мне порой подобный код-ревью доставляет массу фана, надо признать. )))
Обычно не стремлюсь заменять флаги на goto.
S>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
V>Суть этого преобразования я показал. И оно тривиально, это преобразование. (Для тех, кто имеет представление о принципах работы процессоров, т.е. фактически для всех коллег. )
Только вот мы не можем сойтись по поводу исчезновения пересечений. Если ты считаешь что пересечения никуда не делись, то какой смысл в преобразовании?
S>>дык мы же не об этом. Мы о том что на оберонкоре 5 страниц обсуждений как избавиться от пересечений. Конечно, я их не читал.
V>Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))
А, ну тогда ничего удивительного в 5и страницах нет.
Здравствуйте, Mamut, Вы писали:
S>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
M>Ключевой момент: не тривиально, и конечный результат может оказаться кашей по сравнению с вариантом с пересечениями.
Я не настаиваю на таком преобразовании.
Здравствуйте, vdimas, Вы писали:
V>Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))
Концепция ДРАКОНа отличается от концепции Оберона.
Поясню:
Гибридные языки ДРАКОН-семейства и оператор GOTO
Чтобы глубже понять роль оператора GOTO, можно выделить два этапа в истории развития языков программирования.
На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня»[28] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.
На втором этапе появился язык ДРАКОН, в котором исключен не только GOTO, но и все остальные текстовые управляющие операторы. Начался постепенный переход к гибридным языкам с целью дальнейшего повышения производительности труда.
При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать.[29]
Подобная эмуляция оператора GOTO вносит мелкие неоправданные сложности. Эти сложности сразу исчезают, если в целевом языке есть оператор GOTO. Следовательно, с точки зрения языка ДРАКОН, было бы лучше, если бы в целевом языке был предусмотрен оператор GOTO.
Оператор GOTO нежелательно использовать именно в текстовых языках, так как контроль за соблюдением структурности программы остается за исполнителем (программистом). В языке ДРАКОН есть свои собственные правила, позволяющие сохранять структурность.[30]
Отсюда следует предположительный вывод. Если гибридные языки ДРАКОН-семейства (по сравнению с языками высокого уровня) ощутимо повысят производительность труда программистов и со временем получат широкое распространение, это может послужить достаточным основанием, чтобы судьба оператора GOTO снова круто изменилась. Это значит, что в языки высокого уровня, по-видимому, снова будет введен некогда изгнанный оттуда оператор GOTO.
При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.
В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования. Принципы двумерного структурного программирования подробно описаны в литературе.[31][32][4]
Здравствуйте, samius, Вы писали:
V>>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя. S>Как ни крути, от T-образных не избавиться.
Да нет никаких T-образных. Стрелка ведет в блок. Мы просто сугубо на графике пририсовываем, будто одна линия ведет к другой, а к блоку якобы подходит тоже одна линия, но на самом деле это несколько независимых линий подходят к блоку (узлу) алгоритма, а не одна. Нарисуй эквивалентный блок-схеме граф переходов, чтобы было более понятно.
V>>Попробую объяснить суть всех твоих приемов. (Все предложенные тобой и мной приёмы абсолютно идентичны, даже если упоминались разные операторы языка для их воплощения.)
V>>Как работает центральный процесор? Он выполняет некий код. Сам цикл работы центрального процессора не содержит никаких пересечений, ес-но, там идет диспетчеризация по коду команд, которую можно отобразить в блок-схемах без каких-либо пересечений. Однако же, этот процессор способен исполнять алгоритмы, в которых эти пересечения есть (см блок-сцему исходного алгоритма). Ты предлагаешь избавляться от пересечений точно по такому же принципу — превращая код этого агоритма (его поток исполнения) в данные, кодируя разные точки алгоритма через искуственно-вводимые состояния автомата. То бишь имеем дополнительный софтовый уровень: свою "систему команд", свой интерпретатор и на этом уровне получаем аналог центрального процессора, только эмулируемый. И на этом уровне пересечений уже нет, ес-но, как нет в алгоритме работы центрального процессора.
S>Опять таки, причем тут уровень процессора?!?!?
Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных.
S>Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили.
Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора.
Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))
S>В структурном программировании мы оперируем в терминах языка, на котором пишем.
Речь шла о задаче и тобой было предложено вместо решения целевой задачи построить эмулятор автомата и решить уже эту задачу на эмуляторе. Тут уже конкретный язык не важен, лишь бы позволял эмулировать работу автомата. А зачем вообще автомат? Ах да, он же позволяет скакать по состояниям произвольно, в отличие от "структурного программирования"... Вот он и скачет по исходных стрелкам с пересечениями.
V>>Но целевой автоматически алгоритм переползает на один уровень вверх, и на этом уровне все пересечения стрелок останутся. См. упомянутый артефакт — граф переходов. Он никуда не делся. Ты опять можешь "закинуть невод", т.е. опять попытаться избавиться от пересечений на этом новом уровне... и опять получишь тот же самый эффект, потому что сделаешь это через очередной слой интерпретации данных и т.д. до бесконечности. S>От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.
Не избавился, ты их все свел в одну точку и из нее раздал обратно. Вот этот искуственный новый блок как раз принимает все линии и продолжает их на все их конечные точки. Скажем так, ты все эти пересечения накрыл сверху черным ящиком... сделав алгоритм нечитабельным, ес-но...
V>>В чистом виде описанный подход не факт что можно распознать, т.к. народ подвергает такому преобразованию довольно-таки "локальные" места (чаще всего интуитивно, не отдавая себе отчета, что при этом происходит). Но суть этих преобразований надо понимать, чтобы быстро "воткнуть" в целевой алгоритм, глядя на цепочку ветвлений по исскуственно-введенным флагам в чужом коде. Мне порой подобный код-ревью доставляет массу фана, надо признать. ))) S>Обычно не стремлюсь заменять флаги на goto.
Дык, у тебя просто выработанная привычка к мышлению в стиле структурного программирования. То бишь вместо того, чтобы шаги алгоритма получались как естественное положение указателя команд, ты эти шаги кодируешь в данных в некое т.н. "состояние". Я не спорю, эта техника хороша... Особенно в событийном/асинхронном программировании — там и вариантов-то нет... Но не факт, что это так же хорошо в синхронном алгоритме, или где допустимо ожидать события по технике poll. Признаюсь, мне все эти вещи немного до фени, т.е. у меня особой любимой техники и стиля нет (и комлпексов по этому факту тоже), мне "структурность" или "функциональность" — как пустой звук, потому что это слишком уж грубые обобщения, которые не натягиваются задёшево на все случаи жизни. В реальности есть алгоритмы (иногда они даны сверху) и удобные модели для их решения. В технике получения событий poll и при наличии механизма исключений приведенный способ на блок-схеме был самый дешевый (это было описание шагов кое-какого протокола без именований и блоков м/у ветвлениями).
S>>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.
V>>Суть этого преобразования я показал. И оно тривиально, это преобразование. (Для тех, кто имеет представление о принципах работы процессоров, т.е. фактически для всех коллег. )
S>Только вот мы не можем сойтись по поводу исчезновения пересечений.
Почему не можем? Перенаправляем все линии в один блок — интерпретатор состояний, а тот уже каждую линию доведет до места. Конечный адрес каждого перехода теперь закодирован не в коде, а в данных. Согласно моему ИМХО такой интерпретатор состояний — это прозрачный механизм, т.е. на самом деле входящая в него линия уже заранее знает, в какую конечную точку она попадет (это верно для детерминированных автоматов), ведь перед возвратом на начало цикла предыдущий цикл должен изменить состояние, т.е. "заказать" себе услугу перехода в нужную ему точку... коль мы явно запретили ему переходить куда ему надо по goto... В общем, теперь вместо того, чтобы алгоритму переходить куда ему надо самостоятельно, мы используем посредника со всеми накладными расходами, ес-но.
S>Если ты считаешь что пересечения никуда не делись, то какой смысл в преобразовании?
Смысл может быть в пошаговости. Такой алгоритм легко приостановить в точке диспетчеризации и потом возобновить, выполнив что-то другое в том же потоке исполнения. Про событийную модель уже напоминал. Собственно, ООП-парадигма сидит на таком подходе, где вызов каждого метода объекта можно рассматривать как запуск цикла интерпретатора состояний автомата (объекта), а возврат из метода означает конец цикла интерпретатора и готовность к следущему "такту"... поэтому и был приведен в пример ЦП как аналогия происходящему.
Здравствуйте, vdimas, Вы писали:
V>это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
Ваши слова справедливы только как грубое приближение.
Суть в том, что НЕЛЬЗЯ отождествлять правила ДРАКОНа и правила (традиционного) структурного програмирования.
Между ними есть тонкое, но ОЧЕНЬ ВАЖНОЕ различие.
Графические правила ДРАКОНа являются не тождественным повторением правил традиционного (текстового) структурного программирования, а РАЗВИТИЕМ. Причем это развитие позволяет получить НОВОЕ КАЧЕСТВО, новые мощные выразительные средства.
Пояснения представлены ниже.
Мне кажется, сначала следует прочитать
Часть VII, а затем Часть VI .
Часть. Конструктор алгоритмов и формальное
описание языка .............................................393
Глава 32. Конструктор алгоритмов (помощник человека) ...................395
Здравствуйте, PSV100, Вы писали:
PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют.
Оберонкоре — это собрание неграмотных фриков, у половины из которых идеология: "да я 40 лет крутил этот болт ключом на 15!" Ещё там есть несколько невинных жертв этих фриков, которые пытаются что-то делать с использованием технологий, которые им навязали.
О современном состоянии в разработке ПО там и близко не знают.
Здравствуйте, Владимир Паронджанов, Вы писали:
V>>это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования. ВП>Графические правила ДРАКОНа являются не тождественным повторением правил традиционного (текстового) структурного программирования, а РАЗВИТИЕМ.
Коль структурное программирование — это система ограничений на конструкции программы, то развитие структурного программирования может быть только в сторону усиления ограничений. В общем, хотел сказать, что если некий кусок кода нарушает ограничения структурного программирования, то он нарушает ограничения ДРАКОНа и подавно.
Здравствуйте, vdimas, Вы писали:
V>Коль структурное программирование — это система ограничений на конструкции программы, то развитие структурного программирования может быть только в сторону усилениятрансляци ограничений. В общем, хотел сказать, что если некий кусок кода нарушает ограничения структурного программирования, то он нарушает ограничения ДРАКОНа и подавно.
Не согласен.
V>развитие структурного программирования может быть только в сторону усиления ограничений.
Это неверно. ДРАКОН снимает часть ограничений. То есть развитие идет не в сторону усиления ограничений,
а в сторону снятия части ограничений
Вы исходите из того, что кусок кода первичен, а дракон-схема вторична.
Дело обстоит как раз наоборот. Дракон схема первична, а код вторичен. Код образуется в результате трансляции дракон-схемы.
Здравствуйте, vdimas, Вы писали:
V>Коль структурное программирование — это система ограничений на конструкции программы, то развитие структурного программирования может быть только в сторону усиления ограничений.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя. S>>Как ни крути, от T-образных не избавиться.
V>Да нет никаких T-образных. Стрелка ведет в блок. Мы просто сугубо на графике пририсовываем, будто одна линия ведет к другой, а к блоку якобы подходит тоже одна линия, но на самом деле это несколько независимых линий подходят к блоку (узлу) алгоритма, а не одна. Нарисуй эквивалентный блок-схеме граф переходов, чтобы было более понятно.
Тогда непонятно, почему таки стрелки пересекутся при наличии цикла
S>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.
Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок. В исходном алгоритме этого цикла нет, ес-но, он искуственный, как искуственнен цикл работы центрального процессора с т.з. исполняемого им ПО. Просто мы все стрелки направили в одно место и из этого места сделали goto/диспетчеризацию на нужную ветку, согласно текущего состояния (аналога кода команды).
Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.
S>>Опять таки, причем тут уровень процессора?!?!?
V>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных.
Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.
S>>Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили.
V>Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора.
Суть вопроса была в том, можно или нет избавиться от пересечений (пока мы не можем определиться, что является пересечением, а что — нет). А причем тут вручную или нет? И почему ПРИДЕТСЯ, это что, принципиально нельзя автоматизировать? Не очевидно.
V>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))
Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.
S>>В структурном программировании мы оперируем в терминах языка, на котором пишем.
V>Речь шла о задаче и тобой было предложено вместо решения целевой задачи построить эмулятор автомата и решить уже эту задачу на эмуляторе. Тут уже конкретный язык не важен, лишь бы позволял эмулировать работу автомата. А зачем вообще автомат? Ах да, он же позволяет скакать по состояниям произвольно, в отличие от "структурного программирования"... Вот он и скачет по исходных стрелкам с пересечениями.
Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?
Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.
S>>От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.
V>Не избавился, ты их все свел в одну точку и из нее раздал обратно. Вот этот искуственный новый блок как раз принимает все линии и продолжает их на все их конечные точки. Скажем так, ты все эти пересечения накрыл сверху черным ящиком... сделав алгоритм нечитабельным, ес-но...
Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.
А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.
S>>Обычно не стремлюсь заменять флаги на goto.
V>Дык, у тебя просто выработанная привычка к мышлению в стиле структурного программирования. То бишь вместо того, чтобы шаги алгоритма получались как естественное положение указателя команд, ты эти шаги кодируешь в данных в некое т.н. "состояние". Я не спорю, эта техника хороша... Особенно в событийном/асинхронном программировании — там и вариантов-то нет... Но не факт, что это так же хорошо в синхронном алгоритме, или где допустимо ожидать события по технике poll. Признаюсь, мне все эти вещи немного до фени, т.е. у меня особой любимой техники и стиля нет (и комлпексов по этому факту тоже), мне "структурность" или "функциональность" — как пустой звук, потому что это слишком уж грубые обобщения, которые не натягиваются задёшево на все случаи жизни. В реальности есть алгоритмы (иногда они даны сверху) и удобные модели для их решения. В технике получения событий poll и при наличии механизма исключений приведенный способ на блок-схеме был самый дешевый (это было описание шагов кое-какого протокола без именований и блоков м/у ветвлениями).
Не-не-не. Ты покалаз условие задачи и сказал что никто не избавился от пересечений. Я считаю что мой пример (на авторство методики не претендую) позволяет убрать пересечения. Все остальное — читабельность, дешевость, отсутствие эмуляции автомата и т.п. — их в условии не было. Обсуждать недостатки этого решения я не собираюсь, т.к. я показывал саму возможность в недоумении что никто якобы смог.
S>>Только вот мы не можем сойтись по поводу исчезновения пересечений.
V>Почему не можем? Перенаправляем все линии в один блок — интерпретатор состояний, а тот уже каждую линию доведет до места. Конечный адрес каждого перехода теперь закодирован не в коде, а в данных. Согласно моему ИМХО такой интерпретатор состояний — это прозрачный механизм, т.е. на самом деле входящая в него линия уже заранее знает, в какую конечную точку она попадет (это верно для детерминированных автоматов), ведь перед возвратом на начало цикла предыдущий цикл должен изменить состояние, т.е. "заказать" себе услугу перехода в нужную ему точку... коль мы явно запретили ему переходить куда ему надо по goto... В общем, теперь вместо того, чтобы алгоритму переходить куда ему надо самостоятельно, мы используем посредника со всеми накладными расходами, ес-но.
Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.
S>>Если ты считаешь что пересечения никуда не делись, то какой смысл в преобразовании?
V>Смысл может быть в пошаговости. Такой алгоритм легко приостановить в точке диспетчеризации и потом возобновить, выполнив что-то другое в том же потоке исполнения. Про событийную модель уже напоминал. Собственно, ООП-парадигма сидит на таком подходе, где вызов каждого метода объекта можно рассматривать как запуск цикла интерпретатора состояний автомата (объекта), а возврат из метода означает конец цикла интерпретатора и готовность к следущему "такту"... поэтому и был приведен в пример ЦП как аналогия происходящему.
ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?
S>Здравствуйте, vdimas, Вы писали: S>[...]
V>Здравствуйте, samius, Вы писали: V>[...]
Сорри, что вмешиваюсь, но здесь я соглашусь с Паронджановым в том, что иногда лучше нарисовать, чем долго объяснять на пальцах. Рискну предположить, что здесь на форуме VladZharinov уже давал ссылку на один из вариантов решения подобной "проблемы".
Здравствуйте, PSV100, Вы писали:
PSV>Сорри, что вмешиваюсь, но здесь я соглашусь с Паронджановым в том, что иногда лучше нарисовать, чем долго объяснять на пальцах. Рискну предположить, что здесь на форуме VladZharinov уже давал ссылку на один из вариантов решения подобной "проблемы".
+1
С поправкой: это не один из вариантов, это точно такой же вариант, как мы обсуждаем. Он же единственный, других нет. Я эту схему называю интерпретатором, потому что по ней работают интерпретаторы. Для работы этой сехемы необходимо часть кода перенести в данные (закодировать шаги алгоритма через состояния) и добавить логику по интерпретации этих данных.
Здравствуйте, samius, Вы писали:
V>>Да нет никаких T-образных. Стрелка ведет в блок. Мы просто сугубо на графике пририсовываем, будто одна линия ведет к другой, а к блоку якобы подходит тоже одна линия, но на самом деле это несколько независимых линий подходят к блоку (узлу) алгоритма, а не одна. Нарисуй эквивалентный блок-схеме граф переходов, чтобы было более понятно.
S>Тогда непонятно, почему таки стрелки пересекутся при наличии цикла S>
S>Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок.
Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
S>Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.
Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.
V>>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных. S>Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.
Отсылка была конкретно к циклу работы ЦП, т.е. к тому факту, что хотя цикл ЦП можно выразить без пересечений, этот ЦП способен выполнять алгоритмы наподобие тех, блок схему одного из которых я привел. До сих пор не понятна аналогия работы ЦП? Или мне надо раскрыть сам цикл работы ЦП?
V>>Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора. S>Суть вопроса была в том, можно или нет избавиться от пересечений (пока мы не можем определиться, что является пересечением, а что — нет). А причем тут вручную или нет? И почему ПРИДЕТСЯ, это что, принципиально нельзя автоматизировать? Не очевидно.
Как раз-таки в случае автоматизации ничего делать не надо, пусть себе пересекаются. См. код, генерируемвй всякими генераторами лексеров/парсеров.
Ограничения структурного программирования предназначены для человека, а не машины.
V>>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. ))) S>Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.
А как вообще работает ЦП?
S>Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?
Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
Ты смотришь теперь не на целевой алгоритм, а на интерпретатор искуственно введеных состояний, логика работы которого (интерпретатора) недалеко ушла от логики работы ЦП по низкоуровневым кодам. В целевом алгоритме ты не избавился ни от каких пересечений. Нарисовать граф переходов по состояниям этого нового интерпретатора я уже предлагал абзацем выше.
S>Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.
Вот именно. уровнем ниже. Автоматный подход в разработке — это обратный подход, это использование высокоуровневого языка для моделирования низкоуровневых процессов. А избавиться от трудноизбавимых goto в рамках СП порой никак! Поэтому всю систему опускают на один уровень ниже — на автоматный подход, и решают задачу в рамках низкоуровневого автоматного подхода. Подробная ссылка на нечто подобное рядом уже была.
Именно из-за того, что избавление от goto порой требует усилий, которые в итоге замыливают исходный алгоритм, я отношусь к goto-ненавистникам с некоторой иронией. И время от времи себе позволяю этот оператор. Не факт, чтов каждом году, но бывает регулярно. Просто нужно убедиться, что это именно тот самый goto, который порожден показанными на блок-схеме пересечениями исходного алгоритма, а не неудачной структуризацией его воплощения.
S>Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.
Они сходятся по исходому алгоитму, а не ради мифического убегания от goto.
S>А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.
Дело твое. А тебе что-то дадут блоки и текст в них?
S>>>Только вот мы не можем сойтись по поводу исчезновения пересечений. S>Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.
Дык, с этим фактом я не спорю. Я рассуждаю о сути предложенного трюка. Если тебе суть трюка неинтересна... ну значит зря распинался. ОК, вопрос исчерпан.
S>ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?
Она не более близкая, это одно и то же. Именно оно. Только здесь исходный алгоритм шлет сообщения сам себе в каждой своей ветке.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, PSV100, Вы писали:
PSV>>Сорри, что вмешиваюсь, но здесь я соглашусь с Паронджановым в том, что иногда лучше нарисовать, чем долго объяснять на пальцах. Рискну предположить, что здесь на форуме VladZharinov уже давал ссылку на один из вариантов решения подобной "проблемы".
V>+1 V>С поправкой: это не один из вариантов, это точно такой же вариант, как мы обсуждаем. Он же единственный, других нет. Я эту схему называю интерпретатором, потому что по ней работают интерпретаторы. Для работы этой сехемы необходимо часть кода перенести в данные (закодировать шаги алгоритма через состояния) и добавить логику по интерпретации этих данных.
В общем, да — либо мы вводим метки (для переходов), либо работаем от состояний как функций над выбранными совокупностями величин процесса. В то же время смысл многоветочного цикла как раз в том, что логика интерпретации м.б. естественно включена в алгоритм. Когда мы сразу задумываемся, какую роль в решении задачи будет играть та или иная ветка этого цикла. Аналогичным образом и ВП предлагает выделить в процессе решения единицы, к которым исполнитель, возможно, будет возвращаться (в силуэте с ВЦ). Только там выбор новой единицы идёт изнутри предыдущей по ходу исполнения...
Для материального техпроцесса, как уже говорил, пример здесь.
И всё, что в схеме — д.б. представимо текстом, конечно. Неважно, скольки-мерное (как я понимаю, здесь в основном обсуждается логическая мерность в смысле введённого здесь разграничения).
Тут, кстати, ещё одно. Не сразу м.б. понятно — что это за "фиктивные вершины" такие?.. На самом деле их условия (описанные здесь), конечно, не реализуются. Используется то, что иконы веток интерпретируются как метка и команда БП — и тогда достаточно разадресовать эти переходы в машкоде (промежуточном тексте на ЯВУ — где тогда нужен goto). Как — показано здесь (на второй схеме).
Не думаю, что это абсолютно — годится именно для получения маршрутов, которые "... сходятся по исходому алгоитму, а не ради мифического убегания от goto." (С vdimas
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.
S>>Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.
V>Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.
Ты говоришь "нужно избавиться от перекрестков"
Я — "давай поставим развязку с мостом"
Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
Конечно се ля ви. Так чего ради избавлялись от перекрестков?
V>>>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных. S>>Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.
V>Отсылка была конкретно к циклу работы ЦП, т.е. к тому факту, что хотя цикл ЦП можно выразить без пересечений, этот ЦП способен выполнять алгоритмы наподобие тех, блок схему одного из которых я привел. До сих пор не понятна аналогия работы ЦП? Или мне надо раскрыть сам цикл работы ЦП?
Да какой там цикл? Весь цикл, который необходим на данном уровне абстракции — взять команду и выполнить. Но в общем случае ЦП довольно нетривиальная вещь и я не понимаю, о каком цикле работы ты говоришь.
V>Как раз-таки в случае автоматизации ничего делать не надо, пусть себе пересекаются. См. код, генерируемвй всякими генераторами лексеров/парсеров.
Он для этого не предназначен.
V>Ограничения структурного программирования предназначены для человека, а не машины.
Вот поэтому и избавляются от goto
V>>>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. ))) S>>Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.
V>А как вообще работает ЦП?
Я не спец по ЦП. Мне достаточно того что он выполняет команды. Даже о том что он их интерпретирует мне знать не надо.
S>>Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?
V>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
Тебе не удалось мне это показать.
V>Ты смотришь теперь не на целевой алгоритм, а на интерпретатор искуственно введеных состояний, логика работы которого (интерпретатора) недалеко ушла от логики работы ЦП по низкоуровневым кодам. В целевом алгоритме ты не избавился ни от каких пересечений. Нарисовать граф переходов по состояниям этого нового интерпретатора я уже предлагал абзацем выше.
Не недалеко ушла, а даже не дошла. В цикле сообщений вообще не вижу никакого интерпретатора. Диспетчеризация есть, интерпретации нет.
S>>Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.
V>Вот именно. уровнем ниже. Автоматный подход в разработке — это обратный подход, это использование высокоуровневого языка для моделирования низкоуровневых процессов. А избавиться от трудноизбавимых goto в рамках СП порой никак! Поэтому всю систему опускают на один уровень ниже — на автоматный подход, и решают задачу в рамках низкоуровневого автоматного подхода. Подробная ссылка на нечто подобное рядом уже была.
Уровнем ниже чем GOTO? Куда ниже? Если что, то if в СП строится именно на GOTO, поэтому можно смело считать что уровень повышается.
V>Именно из-за того, что избавление от goto порой требует усилий, которые в итоге замыливают исходный алгоритм, я отношусь к goto-ненавистникам с некоторой иронией. И время от времи себе позволяю этот оператор. Не факт, чтов каждом году, но бывает регулярно. Просто нужно убедиться, что это именно тот самый goto, который порожден показанными на блок-схеме пересечениями исходного алгоритма, а не неудачной структуризацией его воплощения.
Мне не приходится от него избавляться, потому как он у меня не появляется. Я не спорю с тем что с goto можно решить эффективнее, или с меньшим количеством операторов.
S>>Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.
V>Они сходятся по исходому алгоитму, а не ради мифического убегания от goto.
Только убегание вовсе не мифическое.
S>>А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.
V>Дело твое. А тебе что-то дадут блоки и текст в них?
Возможность поговорить о читабельности конкретного алгоритма.
S>>Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.
V>Дык, с этим фактом я не спорю. Я рассуждаю о сути предложенного трюка. Если тебе суть трюка неинтересна... ну значит зря распинался. ОК, вопрос исчерпан.
Суть трюка тривиальна, если не оперировать графами автоматов интерпретаторов переходов.
S>>ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?
V>Она не более близкая, это одно и то же. Именно оно. Только здесь исходный алгоритм шлет сообщения сам себе в каждой своей ветке.
Дык! А ЦП обычно не занимается тем что шлет себе сообщения на верхнем уровне абстракции. А на других уровнях все гораздо сложнее, чем в очереди сообщений. Потому, думать об очереди сообщений с вырожденной очередью (до одного места) в качестве аналогии для решения задачи — гораздо проще, чем думать о циклах работы ЦП.
