Потоковое программирование

Ответ 1

Интересное обсуждение! Вчера мне пришло в голову, что часть замешательства может быть связана с тем, что многие разные обозначения используют направленные дуги, но используют их для обозначения разных вещей. В FBP строки представляют собой ограниченные буферы, через которые перемещаются потоки пакетов данных. Поскольку компоненты обычно являются длительными процессами, потоки могут содержать огромное количество пакетов, а приложения FBP могут работать в течение очень длительных периодов - возможно, даже "постоянно" (см. Документ 2007 года о проекте Eon, в основном, людьми в UMass Amherst). Поскольку отправка в ограниченный буфер приостанавливается, когда буфер (временно) заполнен (или временно пуст), неопределенные объемы данных могут обрабатываться с использованием конечных ресурсов.

Для сравнения, E в Grafcet происходит от Etapes, что означает "шаги", что является совсем другой концепцией. В этом виде модели (и есть несколько из них), данные, проходящие между этапами, либо ограничены тем, что может храниться в высокоскоростной памяти за один раз, либо должны храниться на диске. FBP также поддерживает петли в сети, что трудно сделать в шаговых системах - см., Например, http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication - обратите внимание, что это приложение использовалось как MQSeries, так и CORBA естественным образом. Кроме того, FBP является изначально параллельной, поэтому он поддается программированию сетевых сетей, многоядерных машин и ряду направлений современных вычислений. Один последний комментарий: в литературе я нашел много связанных проектов, но немногие из них имеют все характеристики FBP. Список, который я накопил за эти годы (несколько из них ближе, чем Grafcet), можно найти в http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects.

Ответ 2

1. Вы использовали FBP для реального проекта?

Мы разработали и внедрили DF-сервер для нашего проекта автоматизации (диспетчер, компонентный интерфейс, куча компонентов, язык DF, компилятор DF, пользовательский интерфейс). Он написан на голом С++ и работает на нескольких Unix-подобных системах (Linux x86, MIPS, avr32 и т.д., Mac OSX). Он не имеет нескольких функций, например. сложный контроль потока, комплексное управление потоком (для него есть только не слишком продвинутый компонент), поэтому он просто прототип, даже если он работает. Сейчас мы работаем над полнофункциональным сервером. Мы многому научились во время внедрения и использования прототипа.

Кроме того, мы сделаем визуальный редактор когда-нибудь.

2. Как вы относитесь к FBP?

2,1. Прежде всего, программирование потока данных предельное удовольствие

Когда я познакомился с программированием потока данных, мне было 20 лет назад, когда я впервые встретил программирование. Напротив, программирование DF отличается от программирования процедур/ООП, это просто своего рода программирование. Есть много вещей, чтобы обнаружить, даже ооочень простые! Это очень забавно, когда, будучи опытным программистом, вы столкнулись с проблемой DF, что очень-очень просто, но для вас это было совершенно неизвестно. Итак, если вы перейдете на программирование DF, вы почувствуете себя новичком-программистом, который впервые встретил "цикл" или "условие".

2,2. Он может использоваться только для конкретных архитектур

Это просто молот, предназначенный для забивания ногтей. DF не подходит для пользовательских интерфейсов, веб-сервера и т.д.

2,3. Архитектура потока данных оптимальна для некоторых проблем.

Структура потока данных может создавать магические вещи. Он может парализовать процедуры, которые изначально не предназначены для паралеллизации. Компоненты однопоточные, но когда они организованы в граф DF, они становятся многопоточными.

Пример: знаете ли вы, что make - это DF-система? Попробуйте make -j (см. Man, для чего используется -j). Если у вас многоядерная машина, скомпилируйте свой проект с и без -j и сравните время.

2,4. Оптимальное разбиение задачи

Если вы пишете программу, вы часто разделяете проблему на небольшие проблемы. Существуют обычные точки разделения для хорошо известных подзадач, которые вам не нужно реализовывать, просто используйте существующие решения, такие как SQL for DB или OpenGL для графики/анимации и т.д.

Архитектура DF разбивает вашу проблему очень интересным способом:

• структура потока данных, которая предоставляет архитектуру (просто используйте существующую),
• компоненты: программист создает компоненты; компоненты - простые, хорошо разделенные блоки - легко создавать компоненты;
• конфигурация: программирование потока данных a.k.a.: конфигуратор помещает граф потока данных (программу) вместе, используя компоненты, предоставленные программистом.

Если ваш набор компонентов хорошо разработан, конфигуратор может создать такую ​​систему, о которой программист даже не мечтал. Конфигуратор может реализовывать новые функции, не нарушая работу программиста. Клиенты счастливы, потому что у них есть персонализированное решение. Производитель программного обеспечения также счастлив, потому что ему/ей не нужно поддерживать несколько специфических для конкретного клиента ветвей программного обеспечения, а также специфические для клиента конфигурации.

2,5. Скорость

Если система построена на собственных компонентах, программа DF работает быстро. Единственная потеря времени - отправка сообщений между компонентами по сравнению с простой программой ООП, также минимальная.

3. У FBP есть будущее?

Да, конечно.

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

Кроме того, это очень экономично. Если у вас есть хороший набор компонентов, вам нужно всего лишь собрать кирпичи lego. Программа DF проста в обслуживании. Для построения DF-конфигурации не требуется опытный программист, просто системный интегратор.

Я был бы рад, если бы родные системы распространялись, а двери открывались для создания пользовательских компонентов. Также должен быть стандартный язык DF, что означает, что его можно использовать с независимыми от платформы визуальными редакторами и несколькими DF-серверами.

Ответ 3

Мне нужно не согласиться с комментарием о том, что FBP является всего лишь средством реализации FSM: я думаю, что FSM - это аккуратно, и я считаю, что они играют определенную роль в создании приложений, но основная концепция FBP - это многокомпонентные процессы работающий асинхронно, обмениваясь потоками данных, которые проходят через так называемые ограниченные буферы. Да, определенно, FSM - это один из способов построения компонентных процессов, и на самом деле в моей книге о FBP, посвященной этой идее, есть целая глава, а также связанная с КПК (1) - http://www.jpaulmorrison.com/fbp/compil.htm - но, на мой взгляд, FSM, реализующий нетривиальную сеть FBP, был бы невероятно сложный. В качестве примера показана диаграмма, показанная в составляет около 1/3 одного пакетного задания, выполняемого на мэйнфрейме. Каждый из этих блоков работает асинхронно со всеми остальными. Кстати, мне было бы очень интересно услышать больше ответов на вопросы в первом посте!

1: http://en.wikipedia.org/wiki/Pushdown_automaton Push- down automata​​p >

Ответ 4

Всякий раз, когда я слышу термин "потоковое программирование", я думаю о LabView, концептуально. Т.е. процессы компонентов, планирование которых обусловлено прежде всего изменением его входных данных. Это действительно программирование на Lego в том смысле, что платформа labview использовалась для последнего урока продуктов mindstorm. Однако я не согласен с тем, что это делает его менее полезной моделью программирования.

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

Один вопрос, который мне никогда не приходилось задавать при просмотре приложения, написанного в лаборатории, - "Какой код кода задал это значение?", поскольку он был неотъемлемым и легким для отслеживания назад от данных, а также ошибки, такие как несколько ненастроенных авторов было невозможно создать по ошибке.

Если бы это было верно для кода, написанного более типично процедурно!

Ответ 5

1) Я создаю небольшую структуру FBP для аномального проекта обнаружения, и, оказывается, это отличная идея.

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

Тем не менее лучшим примером потокового программирования является UNIX-каналы, который является одной из старейших, наиболее упущенных фреймворков. Я не думаю, что мне нужно подробно рассказать о силе nix-труб...

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

3) Абсолютно! Трубы здесь, чтобы остаться, и являются одной из самых мощных функций unix. Сила, присущая структуре FBP по сравнению со статической программой, - это много, и тривиальное изменение - до такой степени, что некоторые структуры могут быть переконфигурированы при работе без особых мер.

FBP FTW!; -)

Ответ 6

В автомобильной разработке у них есть протокол агностической передачи сообщений, который является частью спецификации MOST (Media Oriented Systems Transport), которая была разработана для связи между компонентами по сети или внутри одного и того же устройства. Системы обычно имеют как реальную, так и визуализированную шину сообщений, поэтому вы фактически имеете форму потокового программирования.

Вот что заставило лампочку пойти на меня несколько лет назад и привел меня сюда. Это действительно фантастический способ работать и гораздо веселее обычного программирования. Каталог сообщений формирует центральную спецификацию и точку отсчета. Он хорошо работает как для разработчиков, так и для руководства. Управление может просматривать каталог сообщений, а не смотреть на источник.

С интегрированным протоколированием, также ссылающимся на каталог для создания понятного анализа, все может стать действительно продуктивным. Таким образом, у меня есть реальный опыт разработки коммерческих продуктов. Я заинтересован в том, чтобы принимать меры дальше, особенно в отношении инструментов и IDE. К сожалению, я думаю, что многие люди в автомобильном секторе упустили точку зрения о том, как это здорово, и не смогли его построить. Теперь они отвлекаются на другие причуды и не понимают, что развитие гораздо шире, чем физическая.

Ответ 7

Я использовал Spring Web Flow в Java Web-приложениях для моделирования (обычно) процессов приложений, которые, как правило, сложны волшебные дела с большим количеством условной логики о том, какие страницы отображать. Его невероятно мощный. Был добавлен новый продукт, и через час или два я смог полностью восстановить существующие фрагменты в совершенно новый процесс приложения (с добавлением нескольких новых представлений/состояний).

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

В мире Microsoft у вас есть Windows Workflow Foundation ( "WWF" ), который становится все более популярным, особенно в сочетании с Sharepoint.

FBP - это всего лишь средство реализации конечного автомата . Это ничего нового.

Ответ 8

Я понимаю, что это не совсем то же самое, но эта модель много лет использовалась в программировании ПЛК. ISO называет его последовательной блок-схемой, но многие люди называют ее Grafcet после популярной реализации. Он предлагает параллельную обработку и определяет переходы между состояниями.

Ответ 9

В настоящее время он используется в мире бизнес-аналитики для компиляции и обработки данных. Конечные пользователи могут выполнять этапы обработки данных, такие как ETL, запросы, объединения и создания отчетов. Я разработчик в открытой системе - ComposableAnalytics.com В CA приложения с потоком могут совместно использоваться и выполняться через браузер.

Ответ 10

Это то, для чего предназначены серии MQ, MSMQ и JMS.

Это краеугольный камень реализации Web-сервисов и Enterprise Service Bus.

Такие продукты, как TIBCO и Sun JCAPS, в основном основаны на потоках без использования этого конкретного слова.

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