私は unbounded_buffer の便利さが気に入っていますが、同時実行ランタイムが何も知らないスレッドでもこのクラスを使用したいと考えています。私のテストでは、うまくいくようです。このアプローチに潜在的な問題はありますか?
1 に答える
この問題に関してMSFTから受け取ったものは次のとおりです。
はい、CreateThread で手動で作成されたスレッドでメッセージ ブロック (unbounded_buffer など) を使用できます。
メッセージは、その割り当てと削除が同じ dll で行われる必要があるため、dll の境界を越えることはできません。トランスフォーマーなどの一部のメッセージ ブロックは、新しいメッセージを割り当てます。したがって、彼らも同じ問題に苦しんでいます。unbounded_buffer> は、上記の問題を解決しないことを除いて、まったく問題なく使用できます。type テンプレート引数は、メッセージ (つまりメッセージ) のペイロード タイプを参照します。封筒のタイプではありません。
定常状態では、データ フロー ネットワークのスループットは非常に良好です。パフォーマンス ペナルティの主な原因は、ネットワークのセットアップ中のメッセージ ブロックのリンクとリンク解除です。Visual Studio 2010 では、send や asend などのメッセージ開始コマンドがこのパフォーマンスの低下に悩まされていました。この問題は、Visual Studio の今後のリリースで解決されています。修正を VS2010 にバックポートする予定はありません。潜在的な回避策は、データフロー ネットワークに常に接続されている単純な ISource メッセージ ブロックを実装することです。このブロックを使用して、ネットワークへのメッセージを開始します (agents.h の _Originator は ISource ブロックの例です)。