2009-07-30 5 views
9

誰にも「The Pragmatic Programmer」のp.165のBlackboardのコンセプトに関する考えはありますか?誰もがこの方法で黒板パターンを使用することを考えていますか?

ほとんどの場合、互いに独立した複数の小さなサブシステム(DLLとEXE)が必要です。すべてのEXEで使用されるアセンブリがいくつかあります。これらのアセンブリはほぼすべて同じデータベースを使用します。これらのアセンブリ間の通信にインターフェイスを使用するのではなく、Blackboardタイプのパターンはより独立性を提供しませんか?

私は、イベントを介して通知するいくつかのメディエータタイプの構成を考えており、すべてのサブシステム間の通信がそれを通過します。これにより、sybシステムは非常に独立した状態に保たれます。メディエータは、ブロードキャストすべきすべての通知の名前を保持します。次に、サブスクライバは特定のイベントを名前で聴いていますが、常に同じ(またはおそらくはパラメータと同じ名前の)メディエータイベントにサブスクライブします。

ここではそれにいくつかのより多くの議論があります:黒板のhttp://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_22829492.html

+0

「ワークフロー」よりも優れていることを知ることにも興味があります。 – Mank

答えて

13

コンセプトは、彼らはそれの部分を仕事として、複数の独立したプロセスは、黒板を実行し、更新することです。古典的な例は音声認識です。入力データは、認識されるべき音声である。オーディオをセグメント化することができ、複数のスレッドがスニペットを単語に一致させ始める。各スレッドは一致する単語を見つけると、この点まで黒板を翻訳で更新します。フレーズの組み立てが始まると、別のスレッドが文法チェックを行い、さまざまなレコグナイザスレッドが行っている選択を検証できます。単語の信頼性が低く、文法に違反している場合、その部分は再実行して代替案を探し出すことができます。これにより、スタッターやポーズが解決されたときにオーディオデータを再分割することさえあります。

フレーズがセンテンスになると、さらに大きなビューを撮ることができ、ホモフォン(ペア、ペア)のさまざまなオプションを解決できます。これはすべてのプロセスに対して黒板を開き、さまざまな結果がロールインされるときにのみ適用される「ロック」によって実現されます。データベースを黒板として使用することは、しかし、データがどれくらい積極的に更新され、再読み込みされているかによって異なります。非常に迅速に起こっている場合は、ラウンドトリップが追加され、メモリ構造がより合理的になります。

メディエータのアイデアは、単一のロックポイントを作成するので意味があります。黒板アルゴリズムは、すべてのデータ要素を前面に表示するため、A-> B、B-> Aスタイルのデッドロックになることはめったにありません。それを超えると、ロックをあきらめることは、データがロールインする際に、さまざまなサブタスクが常に再開されるため、大きなペナルティではありません。ボードの購読者は、所有しているデータが古くなったとき、最新のデータでタスクを再起動するコールバックを使用して行うことができます。

ワークフローに関するコメント:ここでの主な違いは、ほとんどのワークフローは、入力されたばかりの状態をとり、データが移動できる状態がどのようになっているかを判断するマスタプロセスによって調整されることです。独立した俳優がいるかもしれませんが、より良い成果(他の仕事が使用する)を創出することによって、互いを「凌駕」することはめったにありません。言い換えれば、ワークフローは通常、データが通過する非常に制限された状態のセットですが、黒板は独立したすべての活動のためにほぼ自由です。 (つまり、黒板があなたのワークフローの背後にある可能性があります:http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-247/FORUM_15.pdf

私が見たパターンのC#の例は考えられません。私がする仕事の種類はそれほど必要ありません(計算は決定論的である)。いくつかの検索を行うと、他の言語での参照が見つかりますが、それは素晴らしい品質のものではありません。

+0

ありがとうございます。イントラネット上の分散アプリケーション間の中央通信としてはうまく機能しませんか? – 4thSpace

+2

いくつかの注意点がある分散アプリケーションの場合は、妥当なパターンに見えます。第1の理由は、複雑なモデルのオーバーヘッド(冗長な計算をより簡単に回避する可能性がある)が、他のプロセスにより良いベースラインデータを供給する迅速な更新よりも重要であるリアルタイムまたはほぼリアルタイムのシナリオで通常使用されることです。 2番目の注意点は、黒板が帯域幅の収束速度を交換するということです。更新/通知サイクルによって冗長な再読み取りが多数発生する可能性があります。 – Godeke

+1

これらの2つの潜在的な問題のため、ハブプロセスがワークロードをファーム内のワーカープロセスに配布する設計を使用するなど、より伝統的なネットワーク分散モデルは確実ではありません。ハブで少し前の計算を行うと、シナリオ全体がその作業単位で利用できるようになるまで、作業者にコマンドを送信しないだけで、ほとんどの再作業を回避できます。作業の性質を知らなくても、反復(黒板)または作業負荷分布(ハブ/作業者)を言うことは難しいです。 – Godeke

関連する問題