Описание параллельной системы в интуитивно-понятном виде
От: Rrock  
Дата: 07.09.11 13:36
Оценка:
Какие известные методы/языки описания протоколов параллельных систем используются/по вашему мнению, можно было бы использовать для описания высокоуровневых протоколов/взаимодействия компонентов? Занимаюсь поиском интуитивно-понятных языков, которые бы могли быть удобными для описания взаимодействия компонентов параллельных систем. Существует ли, по вашему мнению, что-то лучшее для этой цели, чем параллельно работающие конечные автоматы (в виде графов состояний)? Т.е. если бы вам, скажем, необходимо было описать схему работы некоторой системы устройств, где устройства работают параллельно, выполняют несложные функции и передают между друг другом сообщения (например, АЦП считывает температуру, с нее данные собирает микроконтроллер, передает в ПО на ПК, где есть поток сбора данных и основной поток GUI), то как бы вы зарисовали такую схему, в т.ч. протокол взаимодействия устройств?
Re: Описание параллельной системы в интуитивно-понятном виде
От: Sinix  
Дата: 07.09.11 13:57
Оценка:
Здравствуйте, Rrock, Вы писали:

R>Существует ли, по вашему мнению, что-то лучшее для этой цели, чем параллельно работающие конечные автоматы (в виде графов состояний)?

В принципе, всё скатывается или к НДКА, или к реактивному (событийному) управлению, либо к описанию портов/каналов (аля singularity io ports|c# axum). Имхо (но это чисто моё личное субъективное мнение), самый интересный вариант для мейнстрима — последний.


R>Т.е. если бы вам, скажем, необходимо было описать схему работы некоторой системы устройств, где устройства работают параллельно, выполняют несложные функции и передают между друг другом сообщения (например, АЦП считывает температуру, с нее данные собирает микроконтроллер, передает в ПО на ПК, где есть поток сбора данных и основной поток GUI), то как бы вы зарисовали такую схему, в т.ч. протокол взаимодействия устройств?

На низком уровне — как очередь (несколько очередей) сообщений с гибким диспатчингом. В какое API это дело обернуть — уже вопрос типовых сценариев использования.
Re: Описание параллельной системы в интуитивно-понятном виде
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.09.11 14:40
Оценка: +1
Здравствуйте, Rrock, Вы писали:

R>Какие известные методы/языки описания протоколов параллельных систем используются/по вашему мнению, можно было бы использовать для описания высокоуровневых протоколов/взаимодействия компонентов? Занимаюсь поиском интуитивно-понятных языков, которые бы могли быть удобными для описания взаимодействия компонентов параллельных систем. Существует ли, по вашему мнению, что-то лучшее для этой цели, чем параллельно работающие конечные автоматы (в виде графов состояний)?


Параллельные системы — это не единый класс задач. Там много подходов. Параллелизм бывает разных. Бывает параллелизм данных, бывает массовый параллелизм и т.д., и т.п.

Так что одной концепции или одного языка придумать невозможно.

R>Т.е. если бы вам, скажем, необходимо было описать схему работы некоторой системы устройств, где устройства работают параллельно, выполняют несложные функции и передают между друг другом сообщения (например, АЦП считывает температуру, с нее данные собирает микроконтроллер, передает в ПО на ПК, где есть поток сбора данных и основной поток GUI), то как бы вы зарисовали такую схему, в т.ч. протокол взаимодействия устройств?


Для этого класса задач, описание КА будет хорошим решением.

Если нужно писать софт для дотнета, то могу порекомендовать нашу новую беблиотеку Nemerle.Statechart
Автор: CodingUnit
Дата: 20.07.11
. Как раз DSL для описания КА (в том числе и для параллельных).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[2]: Описание параллельной системы в интуитивно-понятном в
От: Rrock  
Дата: 07.09.11 14:45
Оценка:
Здравствуйте, Sinix, Вы писали:

S>В принципе, всё скатывается или к НДКА, или к реактивному (событийному) управлению,


Не понял, почему недетерминированных?

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

S>либо к описанию портов/каналов (аля singularity io ports|c# axum). Имхо (но это чисто моё личное субъективное мнение), самый интересный вариант для мейнстрима — последний.

Спасибо, не сталкивался. Стоит посмотреть.

S>На низком уровне — как очередь (несколько очередей) сообщений с гибким диспатчингом. В какое API это дело обернуть — уже вопрос типовых сценариев использования.


А как вы представляете описание диспатчинга? Была идея использовать событийную ориентированность следующим образом. Для каждого параллельно работающего компонента выделить вертикальную линию. На каждой вертикальной линии будут изображены блоки действий (прямоугольники с названием или даже каким-то простым кодом внутри). Слева к блоку сверху подходит горизонтальная стрелка с надписью события, который инициирует этот блок. Справа сверху вниз в необходимой последовательности идут генерируемые этим блоком события, тоже изображаемые стрелками, но уже идущими вправо от блока. Слева еще могут быть события, которые нужно ждать. При этом понятно, что блоки кода для одного компонента не могут исполняться параллельно, а срабатывают по событиям так, как производится порядок обработки сообщений (например, очередь). Для большой системы, описанной в подобном событийно-ориентированном подходе, совершенно пропадает какая-то целостность системы. Понимание системы как бы распадается на эти блоки. Не ощущается, например, никаких последовательностей, которые можно ощутить при той же последовательности смены состояний для варианта представления в виде КА. Т.е. даже графы состояний выглядят более структурировано, чем получившаяся событийно-ориентированная система.
Re[2]: Описание параллельной системы в интуитивно-понятном в
От: Rrock  
Дата: 07.09.11 14:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Параллельные системы — это не единый класс задач. Там много подходов. Параллелизм бывает разных. Бывает параллелизм данных, бывает массовый параллелизм и т.д., и т.п. Так что одной концепции или одного языка придумать невозможно.


Задача ставится прежде всего для описания микроконтроллерной системы. Поэтому, насколько я понимаю, речь идет о параллелизме задач. Каждый компонент (контроллер) исполняет свою задачу, но им необходимо периодически обмениваться информацией, чтобы работала вся система. И вопрос стоит в том, как наиболее наглядно было бы описать взаимодействие подобных систем. Здесь, мне например кажется, точно нужно как-то повышать уровень, чтобы можно было абстрагироваться от каких-то лишних деталей реализации о сконцентрироваться более на высокоуровневом взаимодействии компонентов.
Re[3]: Описание параллельной системы в интуитивно-понятном в
От: Sinix  
Дата: 07.09.11 15:06
Оценка:
Здравствуйте, Rrock, Вы писали:

S>>В принципе, всё скатывается или к НДКА, или к реактивному (событийному) управлению,


R>Не понял, почему недетерминированных?

Потому что может находиться одновременно в нескольких состояниях

R>Что не нравится в графах состояний. Приходится ведь рисовать несколько конечных автоматов для каждого компонента системы (которые, как было уже сказано, работают параллельно).

Как раз здесь и пригодятся НДКА.

S>>либо к описанию портов/каналов (аля singularity io ports|c# axum). Имхо (но это чисто моё личное субъективное мнение), самый интересный вариант для мейнстрима — последний.

R>Спасибо, не сталкивался. Стоит посмотреть.
Не, идея интересная, но без инфраструктуры (т.е. верифицирующего компилятора) неподъёмная. Проще тогда уж на событиях сделать.

S>>На низком уровне — как очередь (несколько очередей) сообщений с гибким диспатчингом. В какое API это дело обернуть — уже вопрос типовых сценариев использования.


R>А как вы представляете описание диспатчинга?

Как обычно — несколько очередей/петель сообщений, в каждой зарегестрировано несколько обработчиков, которые забирают "свои" сообщения и добавляют новые сообщения в другие очереди. Такой подход рулит для высоколатентных операций с произвольным порядком собщений. Для всего остального может оказаться проще подсмотреть идею у workflow-движков (хотя у Workflow Foundation, к примеру, под капотом всё тот же диспатчер и очередь сообщений).
Re[2]: Описание параллельной системы в интуитивно-понятном в
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.09.11 14:23
Оценка: +1
Здравствуйте, Sinix, Вы писали:

R>>Существует ли, по вашему мнению, что-то лучшее для этой цели, чем параллельно работающие конечные автоматы (в виде графов состояний)?

S>В принципе, всё скатывается или к НДКА, или к реактивному (событийному) управлению, либо к описанию портов/каналов (аля singularity io ports|c# axum). Имхо (но это чисто моё личное субъективное мнение), самый интересный вариант для мейнстрима — последний.

концептуально, это всё одно и то же
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Описание параллельной системы в интуитивно-понятном в
От: Sinix  
Дата: 08.09.11 14:43
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>концептуально, это всё одно и то же

Концептуально — да, но мы вроде как про реализацию говорим?
Re[4]: Описание параллельной системы в интуитивно-понятном в
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.09.11 14:55
Оценка:
Здравствуйте, Sinix, Вы писали:

ANS>>концептуально, это всё одно и то же

S>Концептуально — да, но мы вроде как про реализацию говорим?

я так понял вопрос был именно концептуальный.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Описание параллельной системы в интуитивно-понятном в
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.09.11 15:31
Оценка:
Здравствуйте, Rrock, Вы писали:


R>А как вы представляете описание диспатчинга? Была идея использовать событийную ориентированность следующим образом. Для каждого параллельно работающего компонента выделить вертикальную линию. На каждой вертикальной линии будут изображены блоки действий (прямоугольники с названием или даже каким-то простым кодом внутри). Слева к блоку сверху подходит горизонтальная стрелка с надписью события, который инициирует этот блок. Справа сверху вниз в необходимой последовательности идут генерируемые этим блоком события, тоже изображаемые стрелками, но уже идущими вправо от блока. Слева еще могут быть события, которые нужно ждать.


Оффтопик, но именно такими блоками предлагали программировать в Tweak.

R>При этом понятно, что блоки кода для одного компонента не могут исполняться параллельно, а срабатывают по событиям так, как производится порядок обработки сообщений (например, очередь). Для большой системы, описанной в подобном событийно-ориентированном подходе, совершенно пропадает какая-то целостность системы. Понимание системы как бы распадается на эти блоки. Не ощущается, например, никаких последовательностей, которые можно ощутить при той же последовательности смены состояний для варианта представления в виде КА. Т.е. даже графы состояний выглядят более структурировано, чем получившаяся событийно-ориентированная система.


Диаграмма последовательности?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: Описание параллельной системы в интуитивно-понятном виде
От: rfq  
Дата: 08.09.11 16:34
Оценка:
Здравствуйте, Rrock, Вы писали:

R> как бы вы зарисовали такую схему, в т.ч. протокол взаимодействия устройств?


В виде сети Петри. Токенам приписал бы значения (температура и т.п.)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.