1

私は現在Proを読んでいます。C＃でのNET 4.0並列プログラミング。ただし、各章の終わりに演習はありません。私はその概念を理解していますが、それでも実際の実践が不足していると感じています。私が学んだことを補強するために、いくつかの本当の問題が必要です。インターネットで検索しましたが、ほとんどがチュートリアルです...
TPLのみを対象とした問題セットはありますか？私はこのライブラリが多くの点で魅力的であることに気づきました、そして私はただそれをエースしたいと思います。ですから、私が知識を実践できるように、誰かがTPLの領域で私にいくつかの問題を共有してくれるのではないかと思います。あなたが遭遇したどんな問題または参照も大いにありがたいです。問題が必要なだけです。自分で解決策を見つけます。前もって感謝します。

4

3 に答える 3

2

私の意見では、TPLはスケーラビリティがすべてです。このように考えると、コードでそれを利用する方法が見つかります。並行して実行されない場合は、順次実行されます。アクションがほとんどない小さなアプリケーションでは、順次処理が最適です。しかし、特定のプロセスに対して何千ものリクエストがある場合、これがTPLの出番です。

リクエストのリストを処理するとします。リクエストには、ウェブサイトへのURLが含まれています。このプロセスでは、HTMLコンテンツをダウンロードし、ページから特定のデータを取得してデータベースに保存します。通常、これは順番に実行する必要があります。ここで、10人がこのリクエストを同時に実行するとします。最後に送信ボタンを押した人は、他のすべての人が処理を完了するまで待つ必要があります。これには非常に長い時間がかかり、無期限に増加する可能性があります。

視覚的表現：

[Request01] - Finished 
[Request02] - Started
[Request03] - Waiting
[Request04] - Waiting
[Request05] - Waiting
[Request06] - Waiting
[Request07] - Waiting
[Request08] - Waiting
[Request09] - Waiting
[Request10] - Waiting

TPLを使用する場合-これらのリクエストをコンカレントコレクション（TPLコレクション）に保存し、コレクションを並列で反復処理できます。TPLは、これらの要求をスレッドに分割して同時に実行するだけでなく、プロセッサの各コアで実行します。

2つのデュアルコアプロセッサを搭載したサーバーがあるとします。プロセスは次のようになります。

CPU1 Core1
  [Request01] - Finished 
  [Request02] - Started
  [Request03] - Started

CPU1 Core2
  [Request04] - Finished 
  [Request05] - Started
  [Request06] - Started

CPU2 Core1
  [Request07] - Finished 
  [Request08] - Started
  [Request09] - Started

CPU2 Core2
  [Request10] - Finished

ご覧のとおり、これにより、生産量を増やし、待ち時間を短縮できます。TPLの良いところは、健全なアプリケーションを開発できれば、スケーラビリティがソフトウェアからハードウェアに戻ってしまうことです。これは素晴らしいことです。このサービスの対象者が増えるほど、より多くのサーバーを組み合わせて使用​​できます。ITの世界では、これはより受け入れられます。誰もが自分のハードウェアをスケールアップする用意があります。誰も自分のソフトウェアを更新したくない。

これがあなたを正しい方向に向けるのに役立つことを願っています！

于 2012-05-27T13:46:28.917 に答える
1

TPLでしか解決できない特別な問題セットはないと思います。

TPLの目的は、アプリケーションに並列処理と並行性を追加するプロセスを簡素化することにより、開発者の生産性を高めることです。TPLは、並行性の程度を動的にスケーリングして、使用可能なすべてのプロセッサーを最も効率的に使用します。TPLを使用することにより、プログラムが実行するように設計されている作業に集中しながら、コードのパフォーマンスを最大化できます。

これはmsdnからのTPLの説明/目的であり、うまくまとめられていると思います。
私はあなたがtplについて尋ねていることは一般的にマルチスレッドについて尋ねられると思います、そしてマルチスレッドがパフォーマンスに関して最良のソリューションであるかどうかを常に簡単に見分けることができるかどうかはわかりません（あなたのコードが必要とする非常に明白な場合を除いて独立したデータソースにアクセスするため、またはそのようなもの）。マルチスレッドが問題の最善の解決策であると判断した場合、使用するスレッドの数とスレッド間で作業を分割する方法を自動的に判断する方法はありません。
Webサービスを介してX通の電子メールを送信する必要があるアプリケーションがあるとします。すべてのXを1つの大きなループで送信しますか？それらを別々のNスレッドに分割し、各スレッドでX / Nを送信しますか？これらの質問は、トライアルとパフォーマンスプロフリングモニタリングでのみ回答できる場合があります。私が知る限り、TPLライブラリは、これを解決することを目的としています。これらの計算をすべて実行することを期待するのではなく、各実行で同じ結果）、tplは、必要な並列処理のレベルを動的にカウントすることを目的としているため、少なくとも理論的には、それぞれの場合に最高のパフォーマンスを提供します。

于 2012-05-26T09:26:37.300 に答える
1

私は何度か TPL を使ってきましたが、とても役に立ちました。これまでの経験から、次のような課題がありました。

  1. 私はオンライン決済システムに取り組んでいました。理論的には、毎秒数百から数千の支払いが行われる可能性があります。支払いごとに、Web サービスを呼び出して、誰かが n 金額を支払ったことをサービス プロバイダーに通知する必要がありました。サービスの呼び出しは IO 操作であるため、サイト自体からサービスを呼び出すことは論外でした。プールのスレッドがすぐに不足してしまうからです。そこで、ジョブ スケジューラを使用することにしました。ジョブは定期的に実行され、保留中の支払い (トランザクション) をデータベースからフェッチします。TPL が優れているのはそこです。数百または数千のコールを 1 つずつサービスに送信するのは非常に非効率的です。そのため、TPL を使用しました。最適な量のスレッドを自動的に割り当て、適切なサービスを並行して呼び出します。先ほど言ったように、Web サービスの呼び出しは IO 操作なので、
  2. もう 1 つの問題は、IO 操作が発生しない大量のデータ (たとえば、コレクションの配列として表すことができる) を処理する必要がある場合、すべてが CPU バウンドになることです。TPL を使用して、複数の CPU/コアに負荷を分散できます。この状況では、CPU コアごとに 1 つのスレッドを使用するのが最適です。
于 2012-05-26T11:18:23.253 に答える