DRAKON.SU https://forum.drakon.su/ |
|
Параллельные процессы в языке Дракон (Глава 14) https://forum.drakon.su/viewtopic.php?f=62&t=3331 |
Страница 2 из 5 |
Автор: | Рэйлвэй Каген [ Суббота, 02 Апрель, 2011 13:22 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Считаю, что как-то поименовать вновь вводимый формализм всё же стОит. Что касается возможных совпадений при выборе имени, то, на мой взгляд, они способны вызвать лишнее недопонимание при первом прочтении материала. Насчёт конкретной буквы - не подскажу, поскольку совсем не энциклопедист. Хотя есть гугл.. |
Автор: | Владимир Паронджанов [ Суббота, 02 Апрель, 2011 17:52 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Спасибо за подсказку. Я посмотрел ваш запрос в гугл. И продолжил его со всеми другими буквами. Похоже, что все буквы уже заняты. |
Автор: | ==== [ Воскресенье, 03 Апрель, 2011 08:37 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Уважаемый Владимир Даниелович! В ГОСТ 19.701-90 дано определение и описание Вложение: ПараллельныеДействия.PNG Разрешите изложить свое мнение: 1. Следование действующему стандарту является нормой в технике. Вы сами неоднократно упоминали о своих взаимоотношениях со службой нормоконтроля. Пользователи и учащиеся знакомы со стандартом и готовы следовать именно стандарту. 2. В стандарте нет разделения на различные символы разделения и слияния (треугольник). 3. В стандарте логика и смысл описана достаточно конкретно. Нет необходимости предлагать специализированный язык описания - Z, достаточно расширить язык Дракон символом из стандарта. 4. В стандарте использован символ - параллельные линии, этим обеспечивается мнемоническая связь с понятием параллельных действий. В моей программистской практике, использование жирных линий вызывало реакцию пользователей - "развесил траурные ленты". 5. Здесь логичней использовать понятие "параллельные действия" чем "параллельные процессы", вы ведь сами используете в схемах для параллельных действий икону "Действие", а не "Процесс". 6. В Рис._155б_png_Конец_стройки_Без треугольника.png нарушается принцип "шампура", линии связи имеют изломы. Извините, дополню. Здесь, мнение только в части данной темы "Параллельные процессы в языке Дракон (Глава 14)". |
Автор: | Владимир Паронджанов [ Воскресенье, 03 Апрель, 2011 10:49 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Уважаемый Геннадий Николаевич! Благодарю за критические замечания. С Вашего разрешения я изложу вое мнение другим цветом. Геннадий Тышов писал(а): 1. Следование действующему стандарту является нормой в технике... Пользователи и учащиеся знакомы со стандартом и готовы следовать именно стандарту. Ответ.Этот стандарт лежит у меня на столе (так же, как и у Вас). Я хорошо знаю этот стандарт. На обложке указано, что отечественный стандарт ГОСТ 19.701--90 сделан со стандарта ISO 5807-85. Таким образом, стандарт ISO выпущен в 1985 году. То есть 26 лет назад. Это ДЕЙСТВУЮЩИЙ стандарт. Тем не менее, я считаю, что этот стандарт МОРАЛЬНО УСТАРЕЛ. Я пользуюсь этим стандартом, но частично. Перечислю совпадения со стандартом. Пункт 3.2.1.1. Символ Процесс у меня называется не "Символ процесс", а И3 "икона действие". Графика совпадает. Пункт 3.2.2.1. Символ Предопределенный процесс у меня называется не "Символ Предопределенный процесс", а И9 "икона вставка". Графика совпадает. Пункт 3.2.2.2. Символ Ручная операция у меня называется не "Символ Ручная операция", а И16 "икона пауза". Графика совпадает. Смысл разный. Пункт 3.2.2.4. Символ Подготовка у меня называется не "Символ Подготовка", а И4 "икона вопрос". Графика совпадает. Смысл разный. Пункт 3.2.2.6. Символ Граница цикла у меня называется не "Граница цикла", а И12 "икона Начало цикла ДЛЯ" и И13 "икона Конец цикла ДЛЯ". Графика совпадает. Смысл отчасти разный. Пункт 3.4.1. Символ Соединитель у меня называется не "Символ Соединитель", а И26 "икона соединитель". Графика совпадает. Смысл разный. Пункт 3.4.2. Символ Терминатор у меня называется не "Символ Терминатор", а И1 "икона заголовок" и И2 "икона конец". Графика терминатора совпадает только с иконой заголовок. Икона конец имеет малый горизонтальный размер. Пункт 3.4.3. Символ Комментарий у меня называется не "Символ Комментарий", а И22 "икона правый комментарий". Графика совпадает. Вывод. ГОСТ 19.701 и стандарт языка ДРАКОН -- это существенно разные вещи. Из 26 икон языка ДРАКОН лишь в 10 случаях можно найти с ГОСТом некоторое соответствие, да и то приблизительное. 2. В стандарте нет разделения на различные символы разделения и слияния (треугольник). На рис. 155а и 155б для разделения и слияния используются одинаковые обозначения, как Вы и предлагаете. Так что этот случай учитывается. 4. В стандарте использован символ - параллельные линии, этим обеспечивается мнемоническая связь с понятием параллельных действий. В моей программистской практике, использование жирных линий вызывало реакцию пользователей - "развесил траурные ленты". Выражение "развесил траурные ленты" остроумно. Но оно не может запретить желающим (а их немало) использовать язык UML. Думаю, что UML будет жить и успешно развиваться. 5. Здесь логичней использовать понятие "параллельные действия" чем "параллельные процессы".... В моих книгах всюду используется понятие "параллельные процессы". А понятие "параллельные действия" нигде не используется. Вы ставите вопрос об ИЗМЕНЕНИИ ТЕРМИНОЛОГИИ. Это очень серьезно. А главное: ЗАЧЕМ? Для этого должны быть ВЕСКИЕ причины. Таких причин я не вижу. Я не смогу объяснить читателям, по какой причине параллельные процессы внезапно превратились в параллельные действия. Уважаемый Геннадий Николаевич! Вы вполне можете оставить все, как у Вас сделано. И ничего не менять. Я об этом уже говорил здесь. Цитата: 3. Таким образом, если забыть про треугольник, то предложенное мной решение на рис. 155а и 155б практически совпадает с тем решением, которое реализовал Геннадий Тышов. 4. Отличие моего решения от решения Тышова незначительно. Я (по совету Эдуарда Ильченко) использовал жирную линию (как в UML), а Тышов вместо жирной линии использовал две параллельные линии (как в ГОСТ 19.701--90). Все остальное одинаково. viewtopic.php?p=61794#p61794 |
Автор: | ==== [ Воскресенье, 03 Апрель, 2011 13:24 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Владимир Паронджанов писал(а): Ответ. ... ГОСТ 19.701--90 сделан со стандарта ISO 5807-85. Таким образом, стандарт ISO выпущен в 1985 году. То есть 26 лет назад. Утверждение "МОРАЛЬНО УСТАРЕЛ" не логично, стандарт проверен временем и нашел международное признание. Нет оснований отказываться от него. Это ДЕЙСТВУЮЩИЙ стандарт. Тем не менее, я считаю, что этот стандарт МОРАЛЬНО УСТАРЕЛ. Владимир Паронджанов писал(а): Геннадий Тышов писал(а): 2. В стандарте нет разделения на различные символы разделения и слияния (треугольник). На рис. 155а и 155б для разделения и слияния используются одинаковые обозначения, как Вы и предлагаете. Так что этот случай учитывается. Вложение: Новый_77.png По ГОСТ 19.701-90 отказ от различных символов разделения и слияния позволяет алгоритм 1-й схемы отобразить эквивалентной 2-й схемой. Последняя является более наглядной, что является целью языка Дракон. Владимир Паронджанов писал(а): Выражение "развесил траурные ленты" остроумно. Но оно не может запретить желающим (а их немало) использовать язык UML. Думаю, что UML будет жить и успешно развиваться. Но, при этом теряется мнемоническая связь параллельных линий с понятием параллельных действий.Замыкание окончания и начала параллельных действий на раздельные линии символа мнемонически подчеркивает наличие синхронизации их окончания и начала. В вашем варианте с толстой линией и в UML этой мнемоники нет. Цитата: Вы вполне можете оставить все, как у Вас сделано. И ничего не менять. Да могу, но возникает и углубляется расхождение между практикой и теорией.Отказ от мнемоничности ставит под сомнение в когнитивном подходе в развитии языка Дракон. |
Автор: | Владимир Паронджанов [ Понедельник, 04 Апрель, 2011 00:01 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Цитата: Но, при этом теряется мнемоническая связь параллельных линий с понятием параллельных действий. Замыкание окончания и начала параллельных действий на раздельные линии символа мнемонически подчеркивает наличие синхронизации их окончания и начала. В вашем варианте с толстой линией и в UML этой мнемоники нет. Уважаемый Геннадий Николаевич! Вы совершенно правы. Вы четко показали, что ГОСТ 19.701-90 и язык UML НЕСОВМЕСТИМЫ. Вопрос стоит так или -- или. Или ГОСТ, или UML. Эдуард Ильченко проголосовал за UML. Я с ним согласился. Вы голосуете за ГОСТ. Это Ваше право. |
Автор: | Дмитрий Дагаев [ Среда, 18 Май, 2011 11:38 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Уважаемый Владимир Даниелович! Уважаемые господа! Есть серьезная альтернатива параллельным процессам - асинхронное программирование. На рис.149,150 предлагается решение, которое требует 15 потоков. А если у Вас таких схем 1000, а максимальное число потоков в ОС - 1200? Автоматику рис.149 можно сделать в одном потоке. Элемент задержки в предложенной схеме будет останавливать поток: sleep(31); ЗащитныеОперации(); Элемент задержки в асинхронных программах будет проходить далее, пока не настанет время: while(time>time0+31) ЗащитныеОперации(); На асинхронных принципах постоен язык FBD, о котором я писал в Алаверды Дракону. А вот у Дракона специальных иконок для асинхронных программ нет. Хотя можно это все эмулировать. |
Автор: | Ильченко Эдуард [ Среда, 18 Май, 2011 12:12 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): А вот у Дракона специальных иконок для асинхронных программ нет. Кое-что предлагалось здесь. Пример схемы. В среде OpenOffice Draw можно по-экспериментировать. |
Автор: | Рэйлвэй Каген [ Среда, 18 Май, 2011 14:06 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): Есть серьезная альтернатива параллельным процессам - асинхронное программирование. Странно. Почему сразу альтернатива? Есть параллельное выполнение, последовательное выполнение и параллельно-последовательное. А уж взаимодействие между процессами м.б. как синхронным, так и асинхронным.
|
Автор: | Дмитрий Дагаев [ Среда, 18 Май, 2011 15:49 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Речь об альтернативе способа решения предложенной в примере задачи. Один процесс, вызываемый 1 раз в секунду. И никакого стало быть взаимодействия. Проблема в том, что пример в главе о параллельных процессах решается проще без параллельных процессов. |
Автор: | alexus [ Среда, 18 Май, 2011 19:34 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): Речь об альтернативе способа решения предложенной в примере задачи. Один процесс, вызываемый 1 раз в секунду. И никакого стало быть взаимодействия. Ну, Вам же объясняют, что красное не может быть альтернативой высокому. Синхронность/асинхронность - это способы взаимодействия, наряду с односторонним/многосторонним. То, о чем Вы, говорите вообще правильнее называть не асинхронностью, а сериализуемостью (это когда несколько конкурирующих процессов/транзакций выполняются последовательно).Проблема в том, что пример в главе о параллельных процессах решается проще без параллельных процессов. Псевдо-параллельность как-то была объяснима, когда было только одно исполняющее устройство (одно ядро процессора), но сейчас... |
Автор: | Дмитрий Дагаев [ Четверг, 19 Май, 2011 08:06 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Интересное сравнение асинхронного программирования с параллельным с использованием потоков ОС приведено в статье 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. Тут технический форум и присылайте технические контраргументы. Много эмоциональных комментариев в стиле: По газонам не гулять! Вам же ясно сказано! На драконов наступать Противопоказано! |
Автор: | Илья Ермаков [ Четверг, 19 Май, 2011 11:03 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
То есть, Ваш значок async ставит команду на отложенное исполнение, на будущий момент, так? |
Автор: | Владимир Паронджанов [ Четверг, 19 Май, 2011 11:19 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): Уважаемый Владимир Даниелович! Уважаемые господа! Уважаемый Дмитрий Викторович!Есть серьезная альтернатива параллельным процессам - асинхронное программирование. На рис.149,150 предлагается решение, которое требует 15 потоков. А если у Вас таких схем 1000, а максимальное число потоков в ОС - 1200? Автоматику рис.149 можно сделать в одном потоке. Элемент задержки в предложенной схеме будет останавливать поток: sleep(31); ЗащитныеОперации(); Элемент задержки в асинхронных программах будет проходить далее, пока не настанет время: while(time>time0+31) ЗащитныеОперации(); На асинхронных принципах постоен язык FBD, о котором я писал в Алаверды Дракону. А вот у Дракона специальных иконок для асинхронных программ нет. Хотя можно это все эмулировать. 1. Благодарю за критические замечания. 2. Ваше сообщение породило дискуссию, а это очень хорошо. 3. В данный момент я не могу высказать свое мнение, так как мне не хватает знаний. 4. Ваше предложение о необходимости ввести в язык Дракон дополнительную икону для указания асинхронности меня очень заинтересовало. Но мне нужно время, чтобы его глубоко осознать. 5. Язык Дракон опирается на конкретный опыт работы в НПЦ АП. Рисунки я брал из документации по разгонному блоку космческих аппаратов Фрегат почти "дословно". Изменил лишь идентификаторы на более понятный для книги текст. 6. Я старался дать материал в обобщенном виде. Но мои ракетные "уши", по-видимому, все равно торчат. 7. Параллельные процессы выполняются на БЦВМ Бисер в псевдопараллельном режиме. 8. Бисер работает с тактом 32, 8 миллисекунд. Через каждые 32,8 мс происходит аппаратное прерывание. 9. В начале такта работает операционная система БЦВМ Бисер (примерно 3 миллисекунды). Затем выполняются одна или несколько прикладных программ. В каждом такте Бисера эта циклограмма повторяется. 10. Параллельные процессы нам очень нужны. Они используются очень часто. 11. Наше применение параллельных процессов, по-видимому, заметно отличается от Вашего. |
Автор: | Дмитрий Дагаев [ Четверг, 19 Май, 2011 11:21 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Да, async ставит на отложенное исполнение. Возможна эмуляция асинхронности, о которой я выше говорил: вызывать 1 раз в секунду и проверять T>2мин. Так тоже делают. Предложенная икона - первое что пришло в голову. Тут нужно подумать. Может быть, сделать ветку для каждого входа по событию ... |
Автор: | Владимир Паронджанов [ Четверг, 19 Май, 2011 12:07 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): ...Возможна эмуляция асинхронности, о которой я выше говорил: вызывать 1 раз в секунду и проверять T>2мин. Так тоже делают... Это я хорошо понимаю. На Драконе этому описанию соответствует конструкция "Цикл ЖДАТЬ". В иконе Период пишем 1с (1 секунда). В иконе Вопрос (являющейся элементом Цикла ЖДАТЬ) пишем T>2мин. Но такая эмуляция, как я понял, Вас не устраивает... |
Автор: | Владислав Жаринов [ Четверг, 19 Май, 2011 12:12 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): Да, async ставит на отложенное исполнение. Во всяком случае, это не механизм обмена сообщениями (включая сообщения fork/join типов), для визуализации которого и был придуман виоп Параллельный процесс... а получается, вызов процедуры? Т.е. у Вас "зайти" означает вызвать визуал, поименованный на нижнем этаже оператора - а не передать значение команды в порт, соответствующий этому имени? Или именно зайти в показанный визуал - из "диспетчера" (управляющего процесса) - и туда же "выйти" после исполнения оператора (как передачи значения в порт)? Тады тоже не есть просто передача сообщения... и в исполняющем визуале это или действительно допвход (на ветку - свою под каждый акт такого взаимодействия), или делать особый оператор... только смысл за ним будет тот же. А в инициирующем визуале - Вставка с вызовом по этому допвходу... И ещё при таком понимании - как зайти на исполнение последовательности операторов - так ведь и выйти "диспетчер" надо по её прохождении (до основного конца исполняющего визуала)... и это тоже нужно в визуализации отразить (лучше явно).
... Предложенная икона - первое что пришло в голову. Тут нужно подумать. Может быть, сделать ветку для каждого входа по событию ... |
Автор: | Владимир Паронджанов [ Четверг, 19 Май, 2011 12:34 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Дмитрий Дагаев писал(а): Тему об асинхронности я описывал уже в Алаверды Дракону. Если сделать иконку асинхронного вызова (я просто подрисовал async выше) для приложенной схемы, то схема может выполняться в неблокирующем режиме. И несколько схем могут выполняться в одном потоке одновременно. Алгоритм работы схемы будет следующий: 1. А=0; Открыть.трубопровод; выйти из процедуры 2. А=2 мин; По данному событию зайти в процедуру, точка входа - 2 мин; Включить.насос; выйти из процедуры 3. А=2мин 45 сек; По данному событию зайти в процедуру, точка входа - 2 мин 45 сек; Подача.топлива; выйти из процедуры 4. А=5мин 45 сек; По данному событию зайти в процедуру, точка входа - 5 мин 45 сек; Пуск.агрегата; выйти из процедуры Выполнение - асинхронное. Нужна поддержка нескольких точек входа и сохранения контекста выполнения схемы. Уважаемый Дмитрий Викторович! В этом сообщении имеется неточность. На представленном рисунке (согласно терминологии, используемой в моей книге "Как улучшить работу ума...") отсутствуют параллельные процессы. А также отсутствуют процедуры. Объекты, представленные на рисунке, называются иначе. Это визуальные операторы вывода, а точнее визуальные операторы "Выдать команду". См. книгу " Как улучшить работу ума..." М, Дело, 2001. - Стр. 165, 166. Рис. 82 и 83. Оператор "Выдать команду" - это сложная совокупность процессорных и канальных программ, в результате совокупного действия которых из БЦВМ выдается Команда, которая по проволоке пересылается к абоненту. Цитата: Предположим, управляющий компьютер должен выдать серию элек-трических команд, которые по линиям связи передаются в исполни-тельные органы и вызывают срабатывание электромеханических реле. В результате происходит открытие трубопровода, включение насоса и другие операции, необходимые для функционирования управляемого объекта. См. Там же, стр. 166.
|
Автор: | Дмитрий Дагаев [ Четверг, 19 Май, 2011 12:51 ] |
Заголовок сообщения: | Re: Параллельные процессы в языке Дракон (Глава 14) |
Уважаемый Владимир Даниелович! 1. Думаю, понимание параллельных процессов у нас одинаковое. Описанный Вами механизм аппаратного прерывания мне нравится: он представляется более четким, чем переключение контекста у современных ОС РВ. И реализация примера ни у кого возражений не вызывает. И по материалу главы "Параллельные процессы" у меня никаких возражений нет. 2. Дело в другом. Есть альтернатива, и в каждом случае еще неясно что лучше: параллельно или асинхронно. И плохо, когда альтернативного подхода нет в Драконе. 3. Проблема даже не в параллельности, а в остановке алгоритма на время задержки. "Открыть.трубопровод; Ждать 2 мин; Включить насос" - блокирует выполнение программы. Поэтому и пускают параллельные процессы, чтобы что-то могло работать в это время. 4. Плохо то, что возможности вмешаться в заблокированную программу ограничены. Например, аварийное отключение алгоритма "Закрыть.трубопровод" Вы просто так туда не вставите. И люди, не видя альтернатив, строят на основе только блокирующего подхода распределенные системы, которые виснут как Windows. Ибо каждый раз нужно дождаться окончания очередного таймера, которых в программе сотни. 5. В части эмуляции. Если точность +-1сек устраивает, то нужно всю схему вызывать с периодом 1 сек без элементов задержки (Период 1с). Когда выполнится T>=2мин - Включить.насос. 6. Параллельные процессы на схеме появятся, когда, как я писал, несколько таких же схем будут выполняться одновременно. То есть алгоритм будет неблокирующим. 7. По части неточности термина "процедура". Давайте уточним. Разошлось, ибо я имел в виду процедуру в программном понимании. Например, процедура на Обероне, если из схемы сгенерить Оберон-код. Что в программном коде соответствует всей схеме, всему алгоритму? Визуал? (Команде Дракона, кажется, соответствует одна икона) |
Страница 2 из 5 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |