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

Question

В течение последних нескольких дней я немного читал о Потоковом программировании . Существует wiki , которая предоставляет дополнительную информацию. И в Википедии тоже есть хороший обзор . Моей первой мыслью было: «Великий другой сторонник лего-ленд-ленд-программирования» - концепция, восходящая к концу 80-х. Но, читая больше, я должен признать, что заинтриговался.

1. Использовали ли вы FBP для реального проекта?
2. Как вы относитесь к FBP?
3. Есть ли у FBP будущее?

В некоторых смыслах это похоже на священный грааль повторного использования, которого наша индустрия преследовала с момента появления процедурных языков.

Answer 1

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

Мы разработали и внедрили сервер DF для нашего проекта автоматизации (диспетчер, интерфейс компонентов, набор компонентов, язык DF, компилятор DF, пользовательский интерфейс). Он написан на голом C ++ и работает на нескольких 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 (см. Человек, для чего используется -j). Если у вас многоядерный компьютер, скомпилируйте ваш проект с -j и без и сравните время.

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

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

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

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

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

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

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

3. Есть ли у FBP будущее?

Да, конечно.

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

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

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

Answer 2

Интересная дискуссия! Вчера мне пришло в голову, что часть путаницы может быть связана с тем фактом, что многие разные обозначения используют направленные дуги, но используют их для обозначения разных вещей. В 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.

Answer 3

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

1 : http://en.wikipedia.org/wiki/Pushdown_automaton Автомат с нажатием вниз

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

FBP FTW! ; -)

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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

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

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