TCPClientのポーリングスレッド（ディスクリートTCPデバイスの最良の計画ですか？）があり、メッセージを集約し、イベントを発生させることでそれらのメッセージに応答する場合があります。イベントプロデューサーは、スレッドが長期間ブロックされているかどうかはあまり気にしませんが、コンシューマーの設計では、状態を処理するために持っている単一のワーカースレッドでハンドラーを呼び出すようにしたいと思います。マシーン。
問題はこれです。タスクライブラリを使用して、これらのスレッドの作成、構成（スレッド名、バックグラウンドなど）の有効期間、および呼び出しのマーシャリングをどのように最適に管理する必要がありますか？私はThreadタイプを使用してこれを明示的に行うことにある程度慣れていますが、可能な限り、私の会社はTaskを使用するだけでできることを行うことを好みます。
編集：ここで必要なのは、タスクがそのコンテキストに関連付けられた単一のスレッドのスケジュールであることを保証するコンシューマーのタイプのSynchronizationContextに基づいていると思います。
そのときの質問はこれです。Task ライブラリを使用して、これらのスレッドの作成、構成 (スレッド名、バックグラウンドなど) の有効期間、およびマーシャリングをどのように管理するのが最適ですか?
これは の完璧な使用例のように思えますBlockingCollection<T>。このクラスは、プロデューサー/コンシューマーのシナリオ用に特別に設計されており、任意のスレッドをコレクション (スレッド セーフ キューのように機能) に追加し、1 つ (または複数) のスレッドまたはタスクを呼び出しblockingCollection.GetConsumingEnumerable()てアイテムを「消費」することができます。
TCP スレッドからメッセージをプッシュするTPL DataFlowを使用することを検討するActionBlock<T>と、TPL DataFlow は、ハードウェアが処理できる限りアクションの処理をスケールアウトして残りを処理します。ActionBlock<T>を で構成することにより、アクションの処理量を正確に制御することもできますMaxDegreeOfParallelism。
受信データの流れに処理が追いつかない場合があるためBufferBlock<T>、 の前に を「リンク」ActionBlock<T>して、TCP 処理スレッドが実際に処理できるものよりも先に進みすぎないようにすることを検討することをお勧めします。BlockingCollection<T>これは、制限された容量で使用するのと同じ効果があります。
最後に、最も簡単な .NET 4.5 のドキュメントにリンクしていますが、.NET 4.0 用の TPL DataFlow は別のダウンロードから入手できます。残念ながら、NuGet パッケージを作成することはありませんでした。