DRAKON.SU

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

Спасибо за подсказку. Я посмотрел ваш запрос в гугл.
И продолжил его со всеми другими буквами.
Похоже, что все буквы уже заняты.

Уважаемый Владимир Даниелович!

В ГОСТ 19.701-90 дано определение и описание

Разрешите изложить свое мнение:

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

2. В стандарте нет разделения на различные символы разделения и слияния (треугольник).

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

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

5. Здесь логичней использовать понятие "параллельные действия" чем "параллельные процессы", вы ведь сами используете в схемах для параллельных действий икону "Действие", а не "Процесс".

6. В Рис._155б_png_Конец_стройки_Без треугольника.png нарушается принцип "шампура", линии связи имеют изломы.

Извините, дополню.
Здесь, мнение только в части данной темы "Параллельные процессы в языке Дракон (Глава 14)".

Уважаемый Геннадий Николаевич!

Благодарю за критические замечания.

С Вашего разрешения я изложу вое мнение
другим цветом.


Уважаемый Геннадий Николаевич!

Вы вполне можете оставить все, как у Вас сделано. И ничего не менять.
Я об этом уже говорил здесь.

viewtopic.php?p=61794#p61794

Утверждение "МОРАЛЬНО УСТАРЕЛ" не логично, стандарт проверен временем и нашел международное признание. Нет оснований отказываться от него.


По ГОСТ 19.701-90 отказ от различных символов разделения и слияния позволяет алгоритм 1-й схемы отобразить эквивалентной 2-й схемой. Последняя является более наглядной, что является целью языка Дракон.

Но, при этом теряется мнемоническая связь параллельных линий с понятием параллельных действий.
Замыкание окончания и начала параллельных действий на раздельные линии символа мнемонически подчеркивает наличие синхронизации их окончания и начала. В вашем варианте с толстой линией и в UML этой мнемоники нет.

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

Отказ от мнемоничности ставит под сомнение в когнитивном подходе в развитии языка Дракон.

Уважаемый Геннадий Николаевич!

Вы совершенно правы. Вы четко показали, что ГОСТ 19.701-90 и язык UML НЕСОВМЕСТИМЫ.
Вопрос стоит так или -- или. Или ГОСТ, или UML.

Эдуард Ильченко проголосовал за UML. Я с ним согласился.
Вы голосуете за ГОСТ. Это Ваше право.

Уважаемый Владимир Даниелович! Уважаемые господа!

Есть серьезная альтернатива параллельным процессам - асинхронное программирование. На рис.149,150 предлагается решение, которое требует 15 потоков. А если у Вас таких схем 1000, а максимальное число потоков в ОС - 1200? Автоматику рис.149 можно сделать в одном потоке.
Элемент задержки в предложенной схеме будет останавливать поток:
sleep(31); ЗащитныеОперации();
Элемент задержки в асинхронных программах будет проходить далее, пока не настанет время:
while(time>time0+31) ЗащитныеОперации();
На асинхронных принципах постоен язык FBD, о котором я писал в Алаверды Дракону.

А вот у Дракона специальных иконок для асинхронных программ нет. Хотя можно это все эмулировать.

Кое-что предлагалось здесь.
Пример схемы.
В среде OpenOffice Draw можно по-экспериментировать.

Странно. Почему сразу альтернатива? Есть параллельное выполнение, последовательное выполнение и параллельно-последовательное. А уж взаимодействие между процессами м.б. как синхронным, так и асинхронным.

Речь об альтернативе способа решения предложенной в примере задачи. Один процесс, вызываемый 1 раз в секунду. И никакого стало быть взаимодействия.

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

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

Интересное сравнение асинхронного программирования с параллельным с использованием потоков ОС приведено в статье Microsoft Research "The F# Asynchronous Programming Model" применительно к текстовому языку
http://research.microsoft.com/apps/pubs/default.aspx?id=147194

___________________ масштабируемость _________ время разработки
параллельное ........... <=1200 потоков .................. 20 мин на F#
асинхронное ............. >8000 (нет ограничений) ..... 20+10мин на F#

И утверждается прям что цель F# async - заменить использование потоков ОС.
Я не соглашусь, нужно и то, и другое.
Кстати, будь в примере Паронджанова времена не 31сек, а 3.1миллисек, то схема не вызвала бы у меня нареканий.

P.S. Тут технический форум и присылайте технические контраргументы. Много эмоциональных комментариев в стиле:
По газонам не гулять!
Вам же ясно сказано!
На драконов наступать
Противопоказано!

Тему об асинхронности я описывал уже в Алаверды Дракону. Если сделать иконку асинхронного вызова (я просто подрисовал async выше) для приложенной схемы, то схема может выполняться в неблокирующем режиме. И несколько схем могут выполняться в одном потоке одновременно.

Алгоритм работы схемы будет следующий:
1. А=0; Открыть.трубопровод; выйти из процедуры
2. А=2 мин; По данному событию зайти в процедуру, точка входа - 2 мин; Включить.насос; выйти из процедуры
3. А=2мин 45 сек; По данному событию зайти в процедуру, точка входа - 2 мин 45 сек; Подача.топлива; выйти из процедуры
4. А=5мин 45 сек; По данному событию зайти в процедуру, точка входа - 5 мин 45 сек; Пуск.агрегата; выйти из процедуры
Выполнение - асинхронное. Нужна поддержка нескольких точек входа и сохранения контекста выполнения схемы.

То есть, Ваш значок async ставит команду на отложенное исполнение, на будущий момент, так?

Уважаемый Дмитрий Викторович!

1. Благодарю за критические замечания.

2. Ваше сообщение породило дискуссию, а это очень хорошо.

3. В данный момент я не могу высказать свое мнение, так как мне не хватает знаний.

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

5. Язык Дракон опирается на конкретный опыт работы в НПЦ АП. Рисунки я брал из документации по разгонному блоку космческих аппаратов Фрегат почти "дословно".
Изменил лишь идентификаторы на более понятный для книги текст.

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

7. Параллельные процессы выполняются на БЦВМ Бисер в псевдопараллельном режиме.

8. Бисер работает с тактом 32, 8 миллисекунд. Через каждые 32,8 мс происходит аппаратное прерывание.

9. В начале такта работает операционная система БЦВМ Бисер (примерно 3 миллисекунды). Затем выполняются одна или несколько прикладных программ. В каждом такте Бисера эта циклограмма повторяется.

10. Параллельные процессы нам очень нужны. Они используются очень часто.

11. Наше применение параллельных процессов, по-видимому, заметно отличается от Вашего.

Да, async ставит на отложенное исполнение.

Возможна эмуляция асинхронности, о которой я выше говорил: вызывать 1 раз в секунду и проверять T>2мин. Так тоже делают.

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

Это я хорошо понимаю. На Драконе этому описанию соответствует конструкция "Цикл ЖДАТЬ".
В иконе Период пишем 1с (1 секунда).
В иконе Вопрос (являющейся элементом Цикла ЖДАТЬ) пишем T>2мин.

Но такая эмуляция, как я понял, Вас не устраивает...

Во всяком случае, это не механизм обмена сообщениями (включая сообщения fork/join типов), для визуализации которого и был придуман виоп Параллельный процесс... а получается, вызов процедуры? Т.е. у Вас "зайти" означает вызвать визуал, поименованный на нижнем этаже оператора - а не передать значение команды в порт, соответствующий этому имени? Или именно зайти в показанный визуал - из "диспетчера" (управляющего процесса) - и туда же "выйти" после исполнения оператора (как передачи значения в порт)? Тады тоже не есть просто передача сообщения... и в исполняющем визуале это или действительно допвход (на ветку - свою под каждый акт такого взаимодействия), или делать особый оператор... только смысл за ним будет тот же. А в инициирующем визуале - Вставка с вызовом по этому допвходу... И ещё при таком понимании - как зайти на исполнение последовательности операторов - так ведь и выйти "диспетчер" надо по её прохождении (до основного конца исполняющего визуала)... и это тоже нужно в визуализации отразить (лучше явно).

Уважаемый Дмитрий Викторович!

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

Объекты, представленные на рисунке, называются иначе.
Это визуальные операторы вывода, а точнее визуальные операторы "Выдать команду".
См. книгу " Как улучшить работу ума..." М, Дело, 2001. - Стр. 165, 166. Рис. 82 и 83.

Оператор "Выдать команду" - это сложная совокупность процессорных и канальных программ, в результате совокупного действия которых из БЦВМ выдается Команда, которая по проволоке пересылается к абоненту.
См. Там же, стр. 166.

Уважаемый Владимир Даниелович!

1. Думаю, понимание параллельных процессов у нас одинаковое. Описанный Вами механизм аппаратного прерывания мне нравится: он представляется более четким, чем переключение контекста у современных ОС РВ. И реализация примера ни у кого возражений не вызывает.
И по материалу главы "Параллельные процессы" у меня никаких возражений нет.

2. Дело в другом. Есть альтернатива, и в каждом случае еще неясно что лучше: параллельно или асинхронно. И плохо, когда альтернативного подхода нет в Драконе.

3. Проблема даже не в параллельности, а в остановке алгоритма на время задержки. "Открыть.трубопровод; Ждать 2 мин; Включить насос" - блокирует выполнение программы. Поэтому и пускают параллельные процессы, чтобы что-то могло работать в это время.

4. Плохо то, что возможности вмешаться в заблокированную программу ограничены. Например, аварийное отключение алгоритма "Закрыть.трубопровод" Вы просто так туда не вставите. И люди, не видя альтернатив, строят на основе только блокирующего подхода распределенные системы, которые виснут как Windows. Ибо каждый раз нужно дождаться окончания очередного таймера, которых в программе сотни.

5. В части эмуляции. Если точность +-1сек устраивает, то нужно всю схему вызывать с периодом 1 сек без элементов задержки (Период 1с). Когда выполнится T>=2мин - Включить.насос.

6. Параллельные процессы на схеме появятся, когда, как я писал, несколько таких же схем будут выполняться одновременно. То есть алгоритм будет неблокирующим.

7. По части неточности термина "процедура". Давайте уточним. Разошлось, ибо я имел в виду процедуру в программном понимании. Например, процедура на Обероне, если из схемы сгенерить Оберон-код. Что в программном коде соответствует всей схеме, всему алгоритму? Визуал? (Команде Дракона, кажется, соответствует одна икона)