O que são pro / contras de dados push / pull fluir modelos?

Question

Eu tenho vindo a desenvolver uma aplicação DSP in-house (Java w / ganchos para Groovy / Jython / JRuby, plugins via OSGi, abundância de JNI para ir ao redor) em fluxo de dados / style diagrama, semelhante aos dados puros e Simulink . Meu projeto atual é um modelo de envio. Os usuário interage com algum componente da fonte fazendo com que ele enviar dados para o componente seguinte e assim por diante até que um bloco de extremidade (tipicamente um visor escritor ou arquivo). Há alguns desafios únicos com este projeto especificamente quando um morre de fome de componentes para entrada. Não há nenhuma maneira fácil de solicitar mais entrada. Tenho mitiated alguns dos isso com fluxo de controle feedback, ex um bloco FFT pode transmitir que ele precisa de mais dados para o bloco fonte dele de cadeia. Eu já contemplou a adição de suporte para componentes a ser push / pull / ambos.

Eu estou procurando respostas sobre os méritos de impulso vs puxar vs tanto híbrido /. Você já fez isso antes? Quais são algumas das "pegadinhas"? Como você lidou com eles? Existe uma solução melhor para este problema?

Answer 1

alguma experiência com uma abordagem "quase-pull" em um produto de grande escala:

Modelo: Nós construir um 1: Árvore de N, ou seja, cada componente (exceto o root) tem 1 pai e 1..N crianças. Fluxos de dados quase que exclusivamente de pais para filhos. Alterar notificações podem se originar a partir de qualquer nó na árvore.

Implementação: Todas as folhas são notificados com o id do nó de envio e um contador de "geração". Leafs saber qual caminho do nó que dependem, para que eles saibam se eles precisam de atualização. (Qualquer outro algoritmo atualização nó filho faria, também, e poderia ter sido melhor em retrospectiva).

Leafs consulta seus pais para os dados atuais, consulta borbulha de forma recursiva. O contador geração está incluído, assim que a bolha-up pára no nó de origem.

Vantagens:

• nós pais não precisam de muito / qualquer informação sobre seus filhos. Os dados podem ser consumidos por qualquer pessoa - o que permitiu uma abordagem genérica para implementar algumas funcionalidades não-UI (inicialmente não previsto) em cima dos dados destinados a serem expostos
• nós filho pode agregar e atualizações de atraso (evitando repaints bate certo pintura rápido)
• folhas inativos causam nenhum tráfego de dados em tudo

Desvantagens :

• atualizações incrementais são caros, como dados completo é publicado. A implementação realmente permite diferentes pacotes de dados a serem solicitados (e o contador de geração poderia impedir o tráfego de dados desnecessário), mas os pacotes de dados inicialmente concebidos são muito grandes. Cortando-los foi uma reflexão tardia, mas funciona ok.
• Você precisa de um verdadeiro mecanismo boa geração. A única implementado inicialmente colidiu com atualizações iniciais (que precisam de um tratamento especial - ver "atualizações incrementais") e agregação de atualizações
• a necessidade de dados viajando se a árvore foi muito subestimado.
• publicar é barato somente quando as ofertas do nó de acesso somente leitura aos dados atuais. Isso pode exigir a sincronização de atualização adicional, embora
• às vezes você quer nós intermediários para atualizar, mesmo quando todas as folhas estão inativos
• algumas folhas acabou implementação de votação, alguns nós de base acabou contando com isso. feio.

---

Geralmente:

Data-Pull "sente" mais nativa para mim quando os dados e camada de processamento deve saber nada sobre a interface do usuário. No entanto, isso requer uma mudança complexa notificatin mecanismo para evitar "Atualizando o universo".

atualizações incrementais Data-push simplifica, mas apenas se o remetente intimamente conhece o receptor.

Não tenho experiência de escala similar utilizando outros modelos, então eu realmente não posso fazer uma recomendação. Olhando para trás, vejo que eu usei na maior parte puxar, que foi menos de um aborrecimento. Seria interessante ver experiências de outras pessoas.

Answer 2

Eu trabalho em uma biblioteca de processamento de imagem pura-pull. É mais orientada para operações de estilo lote onde não têm de lidar com entradas dinâmicas e por isso parece funcionar muito bem. Pull funciona especialmente bem para grandes conjuntos de dados e para rosqueamento:. Nós dimensionar linearmente para pelo menos 32 CPUs (dependendo do gráfico que está sendo avaliado, é claro, heh)

Temos uma interface gráfica que permite que as folhas a ser fontes de dados dinâmicos (por exemplo, uma câmera de vídeo entregando quadros) e eles são manipulados por jogar fora e reconstruir as partes relevantes do gráfico em uma mudança. Este é barato no nosso caso, de modo que a sobrecarga não é tão alto.