Вопрос

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

  1. Вы использовали FBP для реального проекта?
  2. Что вы думаете о ФБП?
  3. Есть ли будущее у ФБП?

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

Это было полезно?

Решение

Интересная дискуссия!Вчера мне пришло в голову, что часть путаницы может быть связана с тем, что во многих различных обозначениях используются направленные дуги, но они обозначают разные вещи.В FBP линии представляют собой ограниченные буферы, через которые проходят потоки пакетов данных.Поскольку компоненты обычно представляют собой долговременные процессы, потоки могут включать огромное количество пакетов, а приложения FBP могут работать в течение очень длительных периодов времени — возможно, даже «постоянно» (см. статью 2007 года о проекте под названием Eon, написанную в основном людьми из Университета Массачусетса в Амхерсте). ).Поскольку отправка в ограниченный буфер приостанавливается, когда буфер (временно) полон (или временно пуст), неограниченные объемы данных могут обрабатываться с использованием ограниченных ресурсов.

Для сравнения, буква 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 .

Другие советы

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

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

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

2.Что вы думаете о ФБП?

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

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

2.2.Его можно использовать только для определенных архитектур.

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

2.3.Архитектура потока данных оптимальна для некоторых задач

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

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

2.4.Оптимальное разделение проблемы

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

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

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

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

2.5.Скорость

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

3.Есть ли будущее у ФБП?

Да, конечно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ФБП ФТВ!;-)

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

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

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

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

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

В мире Microsoft у вас есть Фонд рабочих процессов Windows («WWF»), который становится все более популярным, особенно в сочетании с Sharepoint.

FBP – это всего лишь средство реализации конечный автомат.В этом нет ничего нового.

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

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

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

Это краеугольный камень реализации веб-служб и корпоративной сервисной шины.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top