2009-07-30 7 views
9

Quelqu'un a-t-il des idées sur le concept Blackboard à la p.165 de 'The Pragmatic Programmer'?Quelqu'un at-il des idées sur l'utilisation du Blackboard Pattern de cette façon?

Je veux avoir plusieurs petits sous-systèmes (DLL et EXE) pour la plupart indépendants l'un de l'autre. Certains assemblys seront utilisés par tous les fichiers EXE. Ces assemblages utiliseront presque tous la même base de données. Plutôt que d'utiliser des interfaces pour la communication entre ces assemblages, un modèle de type Blackboard ne fournirait-il pas plus d'indépendance?

Je pense à une construction de type médiateur notifiant via des événements et toutes les communications du sous-système le traversent. Cela maintient les syb-systèmes très indépendants. Le médiateur conservera le nom de toutes les notifications qu'il devrait diffuser. Les abonnés écouteront alors un événement particulier par leur nom, mais s'abonnent toujours au même événement médiateur (ou peut-être passer le nom en paramètre).

est ici un peu plus de discussion à ce sujet: http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_22829492.html

+0

Je suis également intéressé de savoir comment c'est mieux que "workflow". – Mank

Répondre

13

Le concept d'un tableau noir, est que plusieurs processus indépendants fonctionnent et mettre à jour le tableau noir comme ils travaillent des morceaux de celui-ci. Un exemple classique est la reconnaissance de la parole. Les données d'entrée sont les données audio à reconnaître. L'audio peut être segmenté et plusieurs threads commencent à correspondre aux extraits de mots. Comme chaque thread trouve des mots correspondants, ils mettent à jour le tableau avec la traduction jusqu'à ce point. Au fur et à mesure que les phrases commencent à être assemblées, un autre thread peut effectuer une vérification grammaticale pour vérifier les choix effectués par les différents threads de reconnaissance. Si un mot a une confiance faible et viole la grammaire, le morceau peut être réexécuté à la recherche d'alternatives. Cela peut même entraîner le repartitionnement des données audio lorsque les bégaiements et les pauses sont résolus. Au fur et à mesure que les phrases deviennent phrases, des vues encore plus grandes peuvent être prises et les différentes options pour les homophones (paire, pare) peuvent être résolues. Tout ceci est fait en ayant le tableau ouvert à tous les processus et les «verrous» seulement appliqués au fur et à mesure des résultats.

Utiliser une base de données comme tableau noir est logique parce que vous obtenez des transactions «gratuitement» , mais cela dépend de la façon dont les données sont mises à jour et relues de manière agressive. Si cela se produit très rapidement, les allers-retours se rajouteraient et rendraient une structure en mémoire plus raisonnable. Votre idée de médiateur a du sens car elle crée un point de verrouillage unique ... et les algorithmes de tableau noir rencontrent rarement les blocages de style A-> B, B-> A car ils demandent tous les éléments de données à l'avant. Au-delà de cela, l'abandon d'un verrou n'est pas une pénalité importante, car les différentes sous-tâches redémarreront tout le temps que les données entrent en jeu. Les abonnés du forum devront être notifiés lorsque les données qu'ils ont deviennent obsolètes, ce qui pourrait être fait avec des rappels qui relanceraient la tâche avec les données les plus récentes. En ce qui concerne le commentaire sur un workflow, la différence majeure est que la plupart des workflows sont coordonnés par un processus maître qui prend l'état que vous venez de saisir et décide des états dans lesquels les données peuvent être déplacées. Bien qu'il puisse y avoir des acteurs indépendants, ils s'impliquent rarement en se surpassant les uns les autres en créant de meilleurs résultats (que d'autres tâches utiliseront ensuite). En d'autres termes, un flux de travail est généralement un ensemble très contraint d'états dans lesquels les données défilent, tandis qu'un tableau noir est presque gratuit - pour toute activité indépendante. (Cela dit, un tableau peut être derrière votre flux de travail: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-247/FORUM_15.pdf)

Je ne peux pas penser à des exemples C# du modèle que j'ai vu, et le type de travail que je fais n'a pas beaucoup d'appel pour cela (les calculs étant déterministes). Faire des recherches trouve des références dans d'autres langues, mais aucune qui semble de grande qualité.

+0

Merci. Cela ne fonctionnerait-il pas bien comme une communication centrale entre des applications distribuées sur un intranet? – 4thSpace

+2

Il semblerait un modèle raisonnable pour les applications distribuées avec quelques mises en garde. Le premier est qu'il est normalement utilisé dans des scénarios en temps réel ou quasi-réel où la surcharge d'un modèle plus complexe (qui pourrait éviter les calculs redondants plus facilement) est compensée par des mises à jour rapides alimentant les autres processus de meilleures données de base. Le deuxième avertissement est qu'un tableau noir négocie la vitesse de convergence pour la bande passante: il peut y avoir beaucoup de relectures redondantes provoquées par le cycle de mise à jour/notification. – Godeke

+1

En raison de ces deux problèmes potentiels, je ferais en sorte qu'un modèle de distribution réseau plus traditionnel (comme l'utilisation d'une conception où un processus concentrateur distribue la charge de travail aux processus de travail dans la batterie) n'a pas plus de sens. Un peu plus de calcul initial au niveau du concentrateur peut signifier que vous pouvez éviter la plus grande partie du travail en envoyant simplement des commandes aux travailleurs jusqu'à ce que le scénario entier soit disponible pour cette unité de travail. Difficile à dire sans connaître la nature du travail: itératif (Blackboard) ou répartition de la charge de travail (hub/worker). – Godeke

Questions connexes