DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 14:13

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 91 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 19 Май, 2011 13:05 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Уважаемый Драконограф!

Так и есть, в показанный визуал мы входим:
- первый раз - из инициирующего визуала;
- второй-четвертый раз - из диспетчера событий 2мин, 2мин45, 5мин45.
Как зайти на исполнение последовательности операторов?
- Оператор А завершен и просит диспетчер вызвать слебующий оператор Б.
- Диспетчер вызывает Б, ведь событие не только время, оно может быть командой от удаленного компьютера распределенной системы.
Визуально как? Я все-таки склоняюсь к специальным веткам, вызываемым диспетчером. Надо думать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 13:19 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий Дагаев писал(а):
...ведь событие не только время, оно может быть командой от удаленного компьютера распределенной системы.
Визуально как? Я все-таки склоняюсь к специальным веткам, вызываемым диспетчером. Надо думать...
Вот я тоже согласен - ведь это процедура, значит на "страдательной" стороне основной или дополнительный вход в неё. А вот вызов как передача команды - это м.б. комплексный (в смысле п/п 1.3.1.1 здесь) виоп "вызов на рандеву со вставкой"... т.е. передаётся сообщение "войти в процедуру под таким-то сетевым адресом". Главное - не забыть, что д.б. отработана только данная ветка, и надо как-то визуализировать возврат из неё в вызывающий процесс (в принципе там эта семантика обозначается вставкой... а вот в вызываемом надо конец обозначить). И ещё - а готов ли вызываемый процесс исполниться... м.б. по нему уже другая "рабочая точка" бежит?.. тогда новый экземпляр создаём или ждём... или и так и так сочинить можно? и всему этому тоже надо свои языковые средства...


Последний раз редактировалось Владислав Жаринов Четверг, 19 Май, 2011 13:29, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 13:28 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Цитата:
И ещё - а готов ли вызываемый процесс исполниться... м.б. по нему уже другая "рабочая точка" бежит?.. тогда новый экземпляр создаём или ждём... или и так и так сочинить можно? и всему этому тоже надо свои языковые средства...

Если вызывающий процесс и диспетчер - в одном потоке - то все ОК.
А если в разных: совершенно справедливо, нужно думать о синхронизации!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 13:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Конец фрагмента, м.б., можно обозначить по аналогии с исключением, но надо подумать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 13:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
Если вызывающий процесс и диспетчер - в одном потоке - то все ОК.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 14:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Прошу прощения, в сообщении viewtopic.php?p=63273#p63273
я допустил ошибку в терминологии.
Сейчас все исправлено.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 15:10 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Дмитрий Дагаев писал(а):
..ведь событие не только время
В этом случае полностью теряется смысл изображения на шампуре - отсутствует порядок следования. С декларативной записью таких проблем не будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 15:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Владимир Паронджанов писал(а):
...
6. Я старался дать материал в обобщенном виде. Но мои ракетные "уши", по-видимому,
все равно торчат.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 15:53 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Вот еще вариант с иконами "Асинхронное имя ветки", "Асинхронный адрес ветки". По событию будет выполняться вся ветка. При переходе к иконе "Асинхронный адрес ветки" управление возвратится диспетчеру.

Кстати, решена проблема (имевшаяся в предыдущей картинке)
Цитата:
теряется смысл изображения на шампуре - отсутствует порядок следования
.
В этой схеме выполнится вся ветка, а разрыв порядка следования будет при переходе между ветками - через диспетчер.


Вложения:
async_ctrl2.png
async_ctrl2.png [ 18.65 КБ | Просмотров: 15798 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 15:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Дмитрий Дагаев писал(а):
..ведь событие не только время
В этом случае полностью теряется смысл изображения на шампуре - отсутствует порядок следования. С декларативной записью таких проблем не будет.
Как я понимаю, это просто неточная формулировка - Дмитрий имел в виду, что событие всегда имеет момент наступления - но может состоять не в обнаружении заданного момента времени, а в некоем акте взаимодействия (влияющем на алгообстановку процесса-восприемника), совершаемом "когда придётся". Порядок есть и в этом случае - просто в терминах теории параллелизма он определяется не единообразно на "стреле времени", одной для всех процессов, исходя из известных длительностей их шагов - а, отвлекаясь от времени, как прямое произведение всех возможных порядков атомизированных участков маршрутов всех рассматриваемых процессов (т.н. интерливинг, см. /Карпов, 2010, Гл. 2,5/) - а уже по спецификации мы должны определять, какие порядки корректны (исходя из целей взаимодействия), а какие нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 16:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий Дагаев писал(а):
Вот еще вариант с иконами "Асинхронное имя ветки", "Асинхронный адрес ветки". По событию будет выполняться вся ветка. При переходе к иконе "Асинхронный адрес ветки" управление возвратится диспетчеру.

Кстати, решена проблема (имевшаяся в предыдущей картинке)
Цитата:
теряется смысл изображения на шампуре - отсутствует порядок следования
.
В этой схеме выполнится вся ветка, а разрыв порядка следования будет при переходе между ветками - через диспетчер.
В общем, реализуется то же, что обсуждалось в этом посте и отчасти иллюстрируется этой схемой - что ветка (группа веток), поставленная под допвход, на самом деле м.б. уподоблена процедуре и произвольный (в терминах этой страницы) импер-силуэт становится формой изображения группы алгоритмов.
Упоминаю об этом также потому, чтобы показать, что выделение веток под асинхронно вызываемые участки - частный случай более общей структуризации системы маршрутов через силуэт. И визуальный синтаксис должен это учитывать...

В частности, раз уж считаем, что обращение к такой ветке - это как допвход в визуал - то можно поставить в качестве верхней границы ветки вершину ЛД5 (Имя вставки), а нижней - ЛД6 (Адрес вставки) - как показано на схеме в конце этого подпункта. А в вызывающем - как и предлагал, вершину, комплексирующую Вызов на рандеву и Вставку (по аналогии с Д14/25 здесь). Кстати, вызывающим совсем необязательно д.б. "диспетчер".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 16:39 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Драконограф писал(а):
В частности, раз уж считаем, что обращение к такой ветке - это как допвход в визуал - то можно поставить в качестве верхней границы ветки вершину ЛД5 (Имя вставки), а нижней - ЛД6 (Адрес вставки) - как показано на схеме в конце этого подпункта. А в вызывающем - как и предлагал, вершину, комплексирующую Вызов на рандеву и Вставку (по аналогии с Д14/25 здесь). Кстати, вызывающим совсем необязательно д.б. "диспетчер".


Я не понял до конца про ЛД5,ЛД6. Но Д14/25 как посылка сообщения взаимодействующему процессу - это то, что нужно. Не обязательно диспетчер. А ветка "имя вставки - адрес вставки" как реакция на это сообщение (насколько я Вас понял). И если уже такие дополнительные операторы есть, то их и надо использовать.
Хорошо бы на этих операторах нарисовать ясный пример асинхронной программы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 16:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий Дагаев писал(а):
...
Я не понял до конца про ЛД5,ЛД6. Но Д14/25 как посылка сообщения взаимодействующему процессу - это то, что нужно. Не обязательно диспетчер. А ветка "имя вставки - адрес вставки" как реакция на это сообщение (насколько я Вас понял). И если уже такие дополнительные операторы есть, то их и надо использовать.
Хорошо бы на этих операторах нарисовать ясный пример асинхронной программы.
Да, они д.б. в ЛД-алфавите здесь... но я не вставил их :) А на упомянутом рисунке в конце этого подпункта они выделены и названы - в нижней схеме (на правой вертикали)... Там единственное что - текстовый синтаксис исходит из Оберона-2.
Д14/25 приведён как пример построения комплексного виопа - в обсуждаемом здесь случае вместо графики ввода-вывода нужно подставить графику вставки. Попробуйте нарисовать то, что отражает Ваши задачи.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Май, 2011 17:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Однако такую установку задачи на определённое время не обязательно вводить в язык. Всё это обычно делается библиотечно. Какая-нибудь процедура "ВыполнитьПозднее(КакуюПроцедуру, когда)".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Май, 2011 08:40 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Драконограф писал(а):
Попробуйте нарисовать то, что отражает Ваши задачи.

1. Я говорил только о задачах: рис.149 форума и рис.83 из "Как улучшить работу ума", которую я и перерисовал.
2. Я высказал свое понимание и предложил иконы, которых нет в языке. Вы сообщили, что был до меня диалект Дракона, в котором аналогичные задачи уже решались. Пожалуйста, я готов поддержать Ваши, чтобы не "изобретать сущностей сверх необходимого". Выскажетесь, обсудим.
3. Если Вы заинтересованы, то нарисуйте схему в виде:
"Однопоточная альтернатива рисунку 149 на основе асинхронного взаимодействия с использованием ЛД-алфавита"
4. Когда увидим схему, то станет ясно, какие операторы из диалекта можно предложить для расширения языка.
Илья Ермаков писал(а):
Однако такую установку задачи на определённое время не обязательно вводить в язык. Всё это обычно делается библиотечно.

5. К расширению языка надо подходить осторожно и консервативно, особенно с учетом разработанного уже ПО. Если можно не расширять, не расширяйте. Пусть будут диалекты для прикладных задач.
Но: посылка сообщения и ветка реакции на сообщение - слишком широко используются в ПО, да и на Драконе эти иконки выглядят очень выигрышно по сравнении с текстовыми языками.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Май, 2011 07:28 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
Слишком часто, наши представления сформированы извне, без понимания сути... Захотелось понять, откуда взялось понятие "асинхронного программирования". Материалов в И-нете оказалось подозрительно много, а когда я добрался до ссылок на материалы от Майкрософта... картина прояснилась. Сразу вспомнилось... Младшая дочь лет 10 назад сертифицировалась (модно это тогда было) по MSSQL. Попался ей вопрос о наличии вложенных транзакций в MSSQL. Она ответа не знала и спросила меня. Я ей, конечно, сказал, что никаких вложенных транзакций в MSSQL сервере нет и быть не может. Оказалось, что я "ошибся", оценку снизили... Пришлось поднять для дочери работы Эллиота Мосса, который собственно, ввел это понятие "вложенные транзакции", наложить их на архитектуру MSSQL... В Майкрософте свою ошибку "со скрипом" признали, но, конечно... менять не стали ни оценку, ни учебные материалы.
Примерно тоже самое творится вокруг "асинхронного программирования"... только непонятно, кто этот термин ввел в оборот... и зачем... В свое время пришлось довольно долго объяснять, что даже термин "асинхронный вызов" не является корректным. Асинхронность касается только возврата, но не может относится к вызову. Следовательно, и понятия "параллельные нити, потоки, процессы" тоже не являются корректными. Конечно, можно пользоваться этими понятиями, если удобно, но не следует забывать, что это всего лишь... "упрощения".
Рассмотрим простой пример:
Код:
A := fun1;
B := fun2;
C := A * B;

Данной задаче совершенно безразлично, в каком порядке вызываются функции fun1 и fun2, главное, чтобы к моменту вычисления значения переменной C, переменные A и B были вычислены. Поэтому нет никакой разницы, какой из первых двух операторов выполняется первым, мало того, они оба вполне могут выполняться параллельно. Результат вычисления C не изменится от порядка вычисления A и B. Поэтому точка вычисления C является точкой синхронизации процессов вычисления A и B.
Ситуация становится не такой однозначной в том случае, если появляется понятие контекста исполнения. Например, пусть в контексте исполнения есть переменная D:
Код:
function fun1: Integer;
begin
        ...
        D := D + 256;
        ...
end;
function fun2: Integer;
begin
        ...
        Result := D * 2;
        ...
end;

Теперь порядок исполнения имеет значение. Если исходное состояние D = 1, то при выполнении в порядке: fun1, fun2 - результат fun2 будет равен 514, при порядке: fun2, fun1 - результат fun2, будет равен 2. Соответственно, изменится и результат вычисления переменной C. В таких случаях (изменения контекста), должен строго соблюдаться порядок исполнения. (Примечание: контекст не всегда можно выделить явно, в виде набора переменных, он может быть неявным, то есть, определяться внутренними функциональными зависимостями между элементами... системы/программы).
Из сказанного следует довольно банальный вывод. Необходимо хорошо продумывать структуру программы (здравствуйте Н. Вирт) и/или архитектуру системы, не допуская ненужных/избыточных зависимостей, а необходимые зависимости должны быть оформлены, как состояния. Изменение состояния программы/системы или их частей должны быть локализованы в коде и (тщательно) обоснованы/документированы. В случае одновременного использования одной сущности (shared entity) необходимо рассматривать способы определения и разрешения конфликтных ситуаций. Эти способы общеизвестны.
А "асинхронное программирование" - это в значительной части... затуманивание мозгов, IMHO.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Май, 2011 12:12 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
alexus писал(а):
Захотелось понять, откуда взялось понятие "асинхронного программирования".

1. Мне предыстория неизвестна. Думаю, давно: ноги растут от понятия callback. Когда начали вызывать процедуру по ссылке как реакцию на событие.

alexus писал(а):
Захотелось понять, откуда взялось понятие "асинхронного программирования".
А "асинхронное программирование" - это в значительной части... затуманивание мозгов, IMHO.

2. Я беру схему на рис.149 на Драконе, реализованную на 15 потоках, и предлагаю однопоточную реализацию: более простую и ясную. И кто тут затуманивает?

3. В части структуры программы и конфликтных ситуаций - согласен.

4. Говорить дальше про асинхронное программирование можно - но это нужно в отдельной теме. Хотя, боюсь, будет шире: "блокирующее" vs. "неблокирующее".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Май, 2011 15:36 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
Дмитрий Дагаев писал(а):
alexus писал(а):
Захотелось понять, откуда взялось понятие "асинхронного программирования".
1. Мне предыстория неизвестна. Думаю, давно: ноги растут от понятия callback. Когда начали вызывать процедуру по ссылке как реакцию на событие.
Нет, это совсем другая история... Разбираться с ней здесь не имеет смысла. Мне было интересно, откуда к Вам могло попасть выражение "асинхронное программирование". Вы написали
Дмитрий Дагаев писал(а):
Есть серьезная альтернатива параллельным процессам - асинхронное программирование

Дмитрий Дагаев писал(а):
2. Я беру схему на рис.149 на Драконе, реализованную на 15 потоках, и предлагаю однопоточную реализацию: более простую и ясную. И кто тут затуманивает?
Терминология.
Дмитрий Дагаев писал(а):
3. В части структуры программы и конфликтных ситуаций - согласен.
4. Говорить дальше про асинхронное программирование можно - но это нужно в отдельной теме. Хотя, боюсь, будет шире: "блокирующее" vs. "неблокирующее".
Блокирующее/неблокирующее - это небольшие, но важные, частности. Сама тема "параллельное программирование" гораздо шире... Про "асинхронное программирование" говорить не хочу, поскольку все, что о нем думал, уже сказал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 24 Май, 2011 15:53 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
alexus писал(а):
Мне было интересно, откуда к Вам могло попасть выражение "асинхронное программирование".

Я уже давал ссылки на MS Research. Было много чего раньше, особенно в части коммуникационного ПО. Терминология устоялась, даже если это Вам не нравится.

Далее муссировать эту тему считаю бессмысленным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Июнь, 2011 20:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В общем из сказанного вырисовывается, что проверка моделей и Карпов в частности рулят :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 91 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB